Workplace plugins

From MoodleDocs
Revision as of 10:30, 19 March 2024 by Marina Glancy (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Moodle Workplace has been built on top of Moodle LMS. Moodle Workplace contains all Moodle LMS features of the same version, that is, Moodle Workplace is always kept in sync with Moodle LMS.

Like Moodle LMS, Moodle Workplace can be extended via plugins. While there is a high degree of compatibility between the Moodle LMS and Moodle Workplace, special consideration has to be given to some contributed plugins from Moodle LMS.

Moodle Workplace comprises of a set of plugins, some of which are open-source and available in the plugins directory, for example


One of the plugins included in Moodle Workplace is the Workplace theme. Moodle Workplace sites must either use the Workplace theme or a custom theme that is a child theme thereof. An example of a child theme can be found at https://github.com/moodleworkplace/moodle-theme_wpchild.

Additionally, Moodle Workplace adds some core modifications that only change the LMS behaviour when Workplace plugins are present, and are mostly required for applying extra restrictions related to multi-tenancy. These modifications generally should not affect how other plugins work.

Moodle LMS plugins that do not touch any Workplace-specific functionality are expected to work with Moodle Workplace!

Plugins can, but don't have to, implement additional functionality that will only be activated when when they are installed on top of Moodle Workplace, for example:

  • Multi-tenancy restrictions and features once certain capabilities are allowed for the Tenant administrator role
  • Dynamic rules conditions and actions
  • Audience types for custom pages
  • Other features that use APIs from workplace plugins, for instance, listening to events triggered in workplace plugins, using report builder entities such as jobs and programs, etc


As a rule of thumb, Moodle LMS plugins work in Moodle Workplace if they don't collide with multi-tenancy. For example, activity modules are not affected by multi-tenancy and should work as-is. Authentication plugins should also work, but won't support multi-tenancy.

Below are some examples of core or standard plugins that had to be patched since they were breaking under multi-tenancy. Similar problems can occasionally be found in add-on plugins:

  • The capability to use the manual enrolment plugin is given in the course context, however a user with such capability can effectively see the list of all users in the system through the user picker, even if they do not have a system-level capability to browse the list of users. For multi-tenancy to work correctly, this must be a system-level capability, but since it is not (for legacy reasons), the user picker behaviour had to be changed in Moodle Workplace.
  • The capability to see "other users" in the course is affected by the same problem, as a result a user who can see "other users" could also see people who would not be visible to them anywhere else. This had also to be changed in Moodle Workplace to account for multi-tenancy restrictions.
  • The capability to view people who have been awarded a badge is a system-level capability. This also means that, by default, the capability could not be added to the "Tenant administrator" role. However, this capability is specifically allowed in Moodle Workplace, and a core patch is applied to filter the user list to only those visible to the current user.

Note: Moodle Workplace relies on a separate group mode for separate users from different tenants in the shared courses. When installing add-on Activity module plugins the admins need to ensure that they either support separate group mode or do not expose the participant list.