User profile field visibility logic

There are complex rules determining access to user information in Totara, with the result for a specific user depending on a number of settings, permissions, and the relationship with the user being viewed. When accessing data via the API, private data will typically return null instead of the value, which doesn’t provide enough context on why the data wasn’t accessible and what needs to be changed to make it visible.

This page explains the logic behind user profile access generally. To see the code that drives this behaviour, look at the access controller class found in the code here: server/user/classes/access_controller.php#332

Determining factors

Below we list and explain the various factors that can impact user profile field visibility.

Relevant settings

Global settings

Show user identity (showuseridentity)

This setting specifies one or more fields that are displayed along with the user’s name to help identify the specific user on large sites where their name alone might not be enough. Multiple fields can be selected Any user with the moodle/site:viewuseridentity capability in the target user’s context will be able to see the value of these fields for that user.

Hide user fields (hiddenuserfields)

Specifies fields that you want to explicitly hide from other users, except for users with the moodle/user:viewhiddendetails capability in the target user’s context, or for users with the moodle/course:viewhiddenuserfields capability within at least one course where they are a member of the same group as the target user.

Force users to log in for profiles (forceloginforprofiles)

This setting forces people to log in as a real (non-guest) account before viewing any user's profile.

Profiles for enrolled users only (profilesforenrolledusersonly)

To prevent misuse by spammers (by adding spam links to their profile), if this setting is enabled, profile descriptions of users who are not yet enrolled in any course are hidden. New users must enrol in at least one course before they can add a profile description.

Course contacts (coursecontact)

Users with a role marked as a ‘course contact role’ by this setting in a course get granted the ability to view the profiles of course participants.

User profile access (totara_engage_allow_view_profiles)

This Totara Engage setting, when enabled, allows users to view other users' profile pages globally across the system.

User preferences

Email display user profile setting (maildisplay)

User profile field with options of:

• Hide my email address by default

• Show my email address by default

• Show my email address only to participants in my courses

There is also a global setting that controls the default value for this setting for new users (defaultpreference_maildisplay).

Relevant permissions

Viewing user is a site administrator

Some checks explicitly identify if the viewing user is a site administrator (generally this is not considered best practice).

Course email capability

The moodle/course:useremail capability controls whether a user can see a user’s email address in a course they are both members of.

View fullnames capability

The moodle/site:viewfullnames capability controls whether a user can view another user’s full name. Checked in both the user context and the context of any shared courses.

Can view hidden fields

The moodle/user:viewhiddendetails capability is checked in the target user’s context, along with moodle/course:viewhiddenuserfields which is checked in the context of any shared courses.

View all details capability

The moodle/user:viewdetails and moodle/user:viewalldetails capabilities are checked in the target user’s context. moodle/user:viewdetails is also checked in the context of any shared courses.

View last IP capability

The moodle/user:viewlastip capability is required in the target user’s context to be able to view the IP address the user last accessed the site with.

Can update user

The moodle/user:update capability granted in the target user's context gives the ability to update another user’s profile, which requires the ability to see the user’s profile fields.

Other relevant context

User is viewing their own data

If the viewing user and the target user are the same.

Can view profile

This is a higher-level check to confirm the viewing user is allowed to see the target user’s profile at all. It consists of a range of validations such as if the user is deleted, multitenancy access controls, viewing user’s login status, if the viewing user is a course contact, whether any plugins grant profile access (see below) and view details capability checks.

Plugin granting access

Due to the extensible nature of Totara, our system supports allowing any component/plugin to interact with visibility controls and optionally grant access to specific fields. This is designed to be used by third-party plugins but is also used by certain core components to ensure looser coupling between areas of the product.

There are two hooks that can be interacted with:

• allow_view_profile

• allow_view_profile_field

To see which components make use of these hooks and what they do, search for them in component db/hooks.php files as follows:

Then view the hook watchers to see what they do.

At a high level there are currently watchers for the following:

• Granting access to view user data for users where you are working with them on competencies - for example assigning competencies or rating a user’s abilities

• Granting access to user names and profile images when Totara Engage is enabled to view comments from users

• Granting access to user information within workspaces if the Totara Engage view profile setting is enabled

• Granting access to user information when there is a job assignment relationship between users (such as manager or appraiser)

• Granting API client creators the ability to view user names so they can assign a user to an API client

• Granting access to specific fields for users in a shared workspace

• Granting access to profile fields when working in performance activities to ensure the participants can see the names of the users they are interacting with

• Granting access to profile fields when working in approval workflow applications to ensure the participants can see the names of the users they are interacting with

Multitenancy rules

Various multitenancy-specific settings can impact access, such as tenant isolation mode, if the viewing and target users are in the same tenant, or if users are tenant participants.

Shared courses

Various checks will consider if the viewing user and target user are participants in at least one course together. If they are it will also check if the course is using groups, and if it is, only consider the course shared if they are in the same group or if the group configuration allows them access to see each other in at least one course.

Overall profile visibility logic

• Blocked if user is deleted

• Blocked if multitenancy is enabled and checks show viewing user and target user don’t share a tenant

• Blocked if viewing user is not logged in or is a guest and forceloginforprofiles is enabled

• Blocked if a course profile is being requested but the target user is not enrolled in the course

• Allowed if the viewing user and the target user are the same (you can view your own profile)

• Allowed if the viewing user holds a course contact role in a relevant context

• Allowed if any plugin explicitly allows access via the can_view_profile hook

• Allowed if the viewing user holds a ‘view details’ capability, either in the user context or a relevant course context

• Otherwise block

Individual profile field visibility logic

The check depends on which field is being requested, each field is resolved separately, with caching to improve performance.