Performance activity permissions and capabilities
There are a number of capabilities that can be used to grant access to difference aspects of performance activities in a fine grained way.
Summary of relevant capabilities
Capability | Name | Description | Applicable context type |
---|---|---|---|
mod/perform:manage_all_participation | Manage all participation | Allow the user to manage participation on all instances they have access to. | Own user |
mod/perform:manage_subject_user_participation | Manage participation | Allow the user to manage participation on all instances belonging to the subject user(s) who they hold this capability in the user context of. | Subject user |
mod/perform:report_on_all_subjects_responses | Report on all performance activity subjects' responses | Allow the user to report on responses for all instances they have access to. | Own user |
mod/perform:report_on_subject_responses | Report on a performance activity subject's responses | Allow the user to report on responses for all instances belonging to the subject user(s) who they hold this capability in the user context of. | Subject user |
mod/perform:create_activity | Create performance activities | Allow the user to create new performance activities. | Tenant category |
container/perform:create | Create performance activity container | Second capability needed to create the container for performance activities. | Tenant category |
container/perform:backup | Backup a perform container | Required for cloning activities | Course |
container/perform:restore | Restore a perform container | Required for cloning activities | Course |
mod/perform:view_manage_activities | Access the performance activities management interface | Allow the user to access the performance activities management interface. | Tenant category |
mod/perform:manage_activity | Manage performance activities | Allow the user to manage the specific performance activity which they hold this capability in the course context of. | Course |
mod/perform:view_participation_reporting | Access the participation reporting interface | Allow the user to access the participation reporting interface. | Course |
Performance activity category context setup
Performance activities exist as a 'mod_perform' activity inside a course container. The courses must sit within a category, but at present we don't offer an interface for managing performance activity categories. Instead we auto-create a category called 'performance-activities' whenever we need it to store performance activities, which is hidden from the normal category tree.
In order to support multi-tenancy we need to create multiple 'performance-activities' categories because not all users have access to the full category tree. We check the user's tenant and apply the following rule for where to create the 'performance-activities' category:
- If the user is in 'No tenant' ($USER->tenantid = 0) then we create a new top level category (parent = 0) to store system-level performance activities
- If the user is in a tenant ($USER->tenantid != 0) then we locate the tenant category for that tenant and create a sub-category inside the tenant category to store performance activities for that tenant
The consequence of this is when applying capabilities that occur against the performance activity course itself, you can assign at the course level (affects one specific performance activity), category level (affects all performance activities within that tenant) or system level (affects all performance activities in all tenants).
Performance activity user context setup
'Manage participation' and 'Performance activity reporting' capabilities are used to control who can perform those actions for specific users. Therefore the course or tenant category capabilities don't apply as you are not controlling access to an activity, but instead to a user, so checks are done in a user context.
If you want one user to be able to manage participation for subject instances belonging to another user you would grant the 'mod/perform:manage_subject_user_participation' capability to a role, then assign that role to the manager in the context of the subject user. For example, this could be added to the staff manager role to allow all staff managers the ability to manage participation for their staff.
While in theory you could assign the role at a higher context (tenant context, or system context) this would be inefficient as you would be checking access to each user individually in their own context. To avoid this we have a second capability which grants access to all users you are allowed to see 'mod/perform:manage_user_participation'. This capability is checked in the user's own context.
Performance activity creator role
Performance activities have similar behaviour to courses in that there is a 'creator role' which is given default permissions to create activities, and a separate Performance Activity Manager role for managing activities. As with courses when a new activity is created the person created it is granted the 'manage' role in the context of the new activity's course (if they would otherwise be unable to manage it). This ensures the person creating the activity has permission to manage it.
View interface capabilities
In addition to the capabilities that provide the ability to manage, there are a couple of additional capabilities that are used to control access to view the management interfaces: 'mod/perform:view_manage_activities' and 'mod/perform:view_participation_reporting'. These exist so that a simple check can be done for settings navigation, without having to apply complex per-item checks against multiple capabilities, which would have a performance impact.
Example configurations
Note these configurations show how to setup access to a particular piece of functionality - you may need to complete the steps in multiple sections to get the overall configuration you want - e.g. configure access to create and manage activities AND manage participation if that is what you want.
Activity creation and management
Scenario | Configuration |
---|---|
Give an individual permission to create and manage their own performance activities (no multi-tenancy). | Assign the Performance Activity Creator role in the system context, or grant the 'mod/perform:create_activity' capability to another role and assign that. Note the user will automatically gain 'mod/perform:manage_activity' in the context of any activity they create. Other users with the same ability will be able to create their own activities, but only the owner will be able to manage the activity. |
Give an individual permission to create performance activities and manage all performance activities on the site (no multi-tenancy). | As above, but in addition assign the Performance Activity Manager role to the user in the system context. This will give them the ability to manage all activities, not just the ones they create themselves. |
Give tenant managers the ability to create and manage performance activities within their own tenants. | Add a user as a Tenant Domain Manager. That automatically assigns the Tenant Domain Manager role in the tenant category's context, which includes the 'create activity' and 'manage activities' capabilities. Alternatively create a dedicated role with 'create activity' and 'manage activity' and assign in the tenant category context. The same role can be assigned to a different user in a different tenant and separation will be maintained. |
Manage participation
Scenario | Configuration |
---|---|
Give an individual user permission to manage participation in one subject's instances. | Create a role which grants the 'mod/perform:manage_subject_user_participation' capability. Assign it to the user doing the managing in the user context of the individual who you want them to be able to manage (Go to Profile > Preferences > Assign role relative to this user). The manager will now be able to manage participation of any subject instances belonging to that subject. Access to manage participation is via a button on the Develop > Activities page. |
Give staff managers the right to manage participation for their staff. | Modify the Staff Manager role and grant the 'mod/perform:manage_subject_user_participation' capability. Since this role is automatically assigned in the staff member's context to a staff manager, this will allow staff managers to manage participation for all their staff. |
Give one user the ability to manage participation for all users on the platform (no multi-tenancy). | Create a role that is granted the 'mod/perform:manage_all_participation' capability. The role only needs to be assigned in the target user's own context, but could be assigned at the tenant context or even system context too. As long as they are granted the capability in their own context they will be able to manage participation in all subjects instances they have access to. |
Give a tenant manager the ability to manage participation for all users in their tenant. | Same as above, the capability can be granted in the tenant context or user's own context and that will ensure they can manage participation of all subject instances within their tenant. |
Performance response reporting
Granting these capabilities gives access to performance activity responses, which are potentially very sensitive. Therefore by default these capabilities tend to be more restricted, so in some cases it is necessary to allow capabilities on roles that might otherwise have them by default.
Scenario | Configuration |
---|---|
Give an individual user permission to report on responses in one subject's instances. | Create a role which grants the 'mod/perform:report_on_subject_responses' capability. Assign it to the user doing the reporting in the user context of the individual who you want them to be able to report on (Go to Profile > preferences > assign role relative to this user). The manager will now be able to report on responses for any subject instances belonging to that subject. Access to reporting is via the Performance activity response data (export) link in the Development section of the user's own profile. |
Give staff managers the right to report on responses for their staff. | Modify the Staff Manager role and grant the 'mod/perform:report_on_subject_responses' capability. Since this role is automatically assigned in the staff member's context to a staff manager, this will allow staff managers to report on responses for all their staff. |
Give one user the ability to report on responses for all users on the platform (no multi-tenancy). | Create a role that is granted the 'mod/perform:report_on_all_subjects_responses' capability. The role only needs to be assigned in the target user's own context, but could be assigned at the tenant context or even system context too. As long as they are granted the capability in their own context they will be able to report on responses for all subjects instances they have access to. Access can be via the Performance activity response data link either under Development on their own profile or via the same link in the Site Administration > Performance menu section. |
Give a tenant manager the ability to report on responses for all users in their tenant. | Same as above, the capability can be granted in the tenant context or user's own context and that will ensure they can report on responses for all subject instances within their tenant. |