-

Note: You are currently viewing documentation for Moodle 3.10. Up-to-date documentation for the latest stable version of Moodle may be available here: Multi-tenancy.

Multi-tenancy

From MoodleDocs

workplacelogo.png This feature is part of Moodle Workplace, which is available through Moodle Partners.


Overview

Moodle Workplace allows the main administrator to create multiple "tenants" and allocate users to each of them. Tenant users will all be using the same site but will not see each other. Each tenant can have their own site name, logo and colour scheme.

Moodle Workplace

When Moodle Workplace is installed, the site is prepared to be multi-tenant. The capability 'moodle/category:viewcourselist' is removed from the roles "Authenticated user" and "Guest". If you don't want to use Multitenancy functionality, you may consider allowing these capabilities.

Managing tenants

The main administrator or a user with the capability 'tool/tenant:manage' is able to create tenants, change their settings, associate tenants with course categories and assign tenant administrators. Three additional roles are automatically created when Moodle Workplace is installed, automatically assigned to the following users:

  • "Tenant administrator" role is assigned to the tenant administrator in the system context
  • "Tenant administrator in course category" role is assigned to the tenant administrator in the context of this tenant's course category
  • "Tenant user" role is assigned to any user allocated to the tenant in the context of this tenant's course category. By default this role only has the capability 'moodle/category:viewcourselist'

These roles and role assignments can not be manually deleted, nor can a site administrator manually assign these roles to users. However the main administrator can modify the roles if necessary. For example, the "Tenant administrator" role by default contains the capability 'tool/tenant:managetheme' that allows the tenant administrator to change the look of their tenant (logo and colours). The main administrator may decide that theme customisation should only be done centrally and prohibit this capability in the "Tenant administrator" role. The same can be done for the 'tool/tenant:manageusers' capability.

The main administrator or a user with the capability 'tool/tenant:allocate' is able to move users between tenants.

Limiting number of tenants

A site administrator can restrict the number of tenants that can be created on the site from "Site administration > Advanced features > Enable tenant limit". Enabling this setting and configuring "Tenant limit" to a specific value will prevent more than this number of tenants from being created. Note that archived tenants are also counted towards this limit. It's also possible to add the following lines to your site configuration to hardcode this configuration:

$CFG->tool_tenant_tenantlimitenabled = true; $CFG->tool_tenant_tenantlimit = <VALUE>;

Limiting number of users

A site administrator can restrict the number of users per tenant and/or site-wide:

  • Site-wide: the maximum number of users that can exist on the site
  • Per-tenant: the maximum number of users that can exist in any tenant

These settings are available from "Site administration > Advanced features". Suspended users count towards the limit (this can be improved later). When the site limit is lower than the number of current users in the site, no new users can be created. For tenants, when the number of users reaches the tenant limit, no new users can be created in or moved to the tenant. It's also possible to add the following lines to your site configuration to hardcode this configuration:

// Site limit. $CFG->userlimitenabled = true; $CFG->userlimit = <VALUE>;

// Tenant limit. $CFG->tool_tenant_userlimitenabled = true; $CFG->tool_tenant_userlimit = <VALUE>;

Tenant administration

The Tenant administrator role by default has the capability 'tool/tenant:manageusers'. Unless this capability is removed from the role by the main administrator, the tenant administrator can create and edit users inside their tenant.

The tenant administrator can assign other roles to their users, for example "Program manager" or "Organisation structure manager" in the system context.

If the tenant has its own course category, the tenant administrator also has a role "Tenant administrator in course category" in this course category and is able to assign roles in the context of this course category, for example "Course creator". For easier management there is a single page that lists all the roles that the tenant administrator can assign in both system and category context. It can be accessed through Workplace launcher -> Users -> Roles.

Managing roles for tenant administrator

The tenant administrator is also able to manage their course category and all courses in it. Access to the course management is done through Workplace launcher -> Courses. Hint: check out the "Edit" menu for the course category.

Category management

Authentication

The Tenant administrator role by default has the capability 'tool/tenant:authconfig'. Unless this capability is removed from the role by the main administrator, the tenant administrator can manage authentication settings in their tenant. (See also Upgrade notes for 3.10)

Now it’s possible to set different authentication configurations for each tenant in a Workplace site, including the availability of plugins or changing the settings for the same plugin in different tenants.

  • Per-tenant authentication plugins - 01.png

    Per-tenant authentication plugins

    Selected authentication settings such as authentication instructions and allowed domains can be overridden for individual tenants. Site administrators are also able to force some settings for all tenants. Tenant admin can override common settings or settings for multi-tenant auth plugins in their tenant using the new Authentication tab in the Users page.

  • Per-tenant authentication plugins - 03.png

    Multi-tenant auth plugins

    Email-based self-registration and OAuth2 are now multi-tenant. Global administrator or tenant administrator can enable/disable these plugins on a tenant level and override their settings. When a new user signs up from a tenant-specific login page their account is automatically registered inside this tenant.

Login and sign-up pages

Tenant selector

The site selector on the login and signup pages will help the user to select the correct tenant on the authentication page. If enabled, the site selector on the login and signup pages.

The selector can be enabled at a site level, and each tenant’s visibility in the selector can be configured in tenant settings.

tenant-selector-setting.png

When enabled, it's shown in the bottom-right corner of the login and signup pages some seconds after the page loads.

tenant-selector-login.png

When clicking in "Change site", this modal will appear.

tenant-selector.png

Sharing entities

Shared courses

Normally each tenant has its own course category and its own courses. The manual enrolment method has been modified so the user picker only displays users from the current tenant.

However there are some situations when an organisation wants to have courses that are shared between tenants. Please note that multitenancy will not apply to the course content. This means that if a user (either a learner or a trainer) is enrolled in a course, they will see users from other tenants while browsing the course. This could be forum posts, list of course participants, gradebook, reports or any other module that displays course participants.

There are various reasons for this behaviour:

  1. If the organisation wants to have shared courses they may actually expect this behaviour since they want the learners to study together and/or the trainer from one tenant to be a teacher for all learners regardless of their tenant
  2. It is simply impossible to modify all activity modules and reports to add multitenancy restrictions, especially considering that there can be third party plugins
  3. The same functionality can be achieved by using separate group mode if needed

If you share courses between different tenants and you want users from each tenants to learn independently they must belong to different groups and the course has to be in separate group mode (preferably forced). Please review the "Trainer" and "Non-editing trainer" roles in the course and make sure that they do not have the accessallgroups capability, and the trainers are also allocated to the relevant groups.

Allocation to separate groups is done automatically when a shared course is part of a program. See also Shared courses in programs

Shared Space

Shared Space enables easy sharing of entities across all tenants. It works like a special tenant where users can create supported entities to be available in other tenants.

Note the Shared Space is considered a tenant, so it counts towards the tenants limit if any. See also Limiting number of tenants.

Enabling Shared space

Shared space can be activated either by clicking the "Shared space" item in the Tenant switch dropdown or the Tenants main page (found in the Workplace launcher).

wp-enable-shared-space-dropdown.png

A dialogue box will require confirmation and the Shared space will only be created after the user agrees with it. Th user also has the option to hit the "Not now" button which will remove it from the Tenant Menu and henceforth will only be visible in the Manage Tenants page .

Privacy considerations

All user information from each tenant is stored in the same database and in the same table. However, by default, no personal data is shared from one tenant to the other and they can remain unaware of any other tenants. This is to comply with Moodle’s commitment to the GDPR requirement to implement data protection by default and by design. It is still open to the administrator to enable sharing between, for eg learner or trainers from different tenants, so that they can see users from other tenancies (including forum posts, list of course participants, gradebook, reports or any other module that displays course participants.)

There are certain professional or institutional bodies which may require that data is not stored together with other entities (for e.g. some legal professions, medical or individual government bodies). If you are required by your particular tenants to separate them, unfortunately you may not benefit from multi-tenancy and may need to set up separate sites.

See also