How it works
Multitenancy is an advanced feature which must be enabled at the system level. Once enabled you can optionally enable the tenant isolation setting.
Once multitenancy has been enabled, a Tenants option will appear in the quick-access menu, through which tenants can be added.
For more information see the What is multitenancy? help documentation.
The structures that make up a tenant
Each tenant within system has the following:
- A tenant record
- A tenant context
- A tenant category
- A tenant audience
- A tenant dashboard
The tenant record
A description of each individual tenant.
The tenant context
Added in Totara 13.0 the tenant context has a context level of 15. It can only have one parent, the system context.
It can only have one type of child context, user contexts.
Prior to Totara 13 the user context could only use the system context as a parent. Now, user contexts can use either the system context or a tenant context as the parent. A user whose context uses the system context is considered a "system user". A user whose context uses a tenant context as a parent is considered a "tenant member".
The purpose of the tenant context is to enable delegation of user management responsibilities over a tenants members.
The tenant category
The context structure for categories, courses and activities was not changed. In order to allow for delegation of tenant content responsibilities support was added for system managed categories, and when a new tenant is created a brand new top level category is created at the same time. The new category is marked as a system category belonging to the tenant and cannot be edited or moved in the same way that normal categories can.
The tenant category is always a top level category, and its context uses the system context as a parent. The existing category context is used.
When looking at a tenant category the administration block shows tenant management options as well.
Users (typically tenant members) can then be given roles against the tenant category allowing delegation of tenant content responsibilities.
The tenant audience
When a tenant is first created a new audience is also created. We have introduced the ability to have system managed audiences that cannot be edited in the same way that regular audiences can be. The tenant audience is a system managed audience, that is owned by the tenant.
All tenant members (users whose context uses the tenant context as a parent) are automatically added to this audience.
When adding tenant participant (non-member) through the product interfaces you are in fact adding a user to this audience.
The purpose of the audience is to allow easy selection and use of users associated with a tenant.
Multitenancy was principally an extension of the context hierarchy structure within Totara.
When enabled, capability checks now take into account the tenant a user is a member of, and include a check against the tenant of the context the capability check is being made against. The explanation of behaviour below outlines how this additional check behaves.
By wiring it directly into the context and capability systems much of the Totara code automatically and inherently follows the behaviour rules brought in by multitenancy. This is then supplemented by the addition of the tenant category and audience, which make should make it easy for developers to update their code in places where permissions are not being used to control visibility or access by providing a path to restrict both users and content to a tenant. Primarily the tenant that the current user belongs to
Tenant members vs tenant participants
A user who belongs to a tenant is referred to as a tenant member. A user can only be a member of a single tenant. Tenant members cannot participate in any other tenant. In the context tree the users context will have the tenant context as its parent. Capabilities are therefore inherited from the tenant, and changes at the tenant level will have an effect on the user context if there are not overrides at the user context.
A user who is not a member of a tenant can be associated with a tenant as a participant. A user can be a tenant participant in multiple tenants. When a user is added as a tenant participant they will be added to the tenants audience. The user context uses the system context as its parent and therefore does not inherit from the tenant capability as tenant members do.
When undertaking actions for a tenant or its content through which you see or select users the list of users that you see will be restricted to just tenant members and tenant participants.
This includes actions such as delegating responsibility within the tenant, associating managers and appraisers with a tenant members job, or enrolling in a course within the tenant.