Contexts and the in product conceptual architecture

The concept

Contexts are a fundamental part of the architecture. Internally, user-generated content created within the product exists as part of a hierarchy. Items within this hierarchy by default inherit from their parent, but can in many cases by customised and controlled individually via settings, configuration and further content creation. In turn sub-items inherit the environment of their parent. That inheritance is a quintessential to the functionality provided by the product and cornerstone in the extensible and configurable nature of the platform.

Each of the items within the hierarchy has a context within Totara.
This context is stored as a record in the database and tracks the items type, id, place within the hierarchy, depth and parent contexts.
The context is then used by a variety of features and functionality to provide everything from access control to content structure.

Each context has one parent (other than the system context as discussed below) and 0..n children.

The different context levels

The following is a list of the available context levels within Totara.

System

The root context, all other contexts are children of the system context.
The system context does not, and can not have a parent; it is the only context that does not have a parent.
There is only ever one system context.

Categories

This is an organisational context.
Originally its purpose was both navigation and organisation however as the product has evolved its place within the product has shifted more towards organisation.
Categories can be added to either the system context, and to another category.
Those added to the system are referred to as top level categories.
There is no limit on the depth of categories.
Categories are a core component, they are not pluggable.

Programs and certifications

These both allow the creation of learning flows for users. Directing users through sets of courses, with a goal of completion.
In the case of certifications there is also recertification, taking the user through either the same learning path or a path specifically for recertification.
Programs and certifications are created within categories and they can be created within a category at any level.
The courses referenced within programs and certifications are not added as children of these items. This is because courses can be used in multiple programs and certifications, however the context can only have a single parent.
Programs and certifications are a core component, they are not pluggable.
They are also learning items.

Courses

The fundamental building block of the LMS.

Courses are used for all manner of learning, they facilitate enrolment, track completion, join learners and so much more.
Courses, like programs and certifications are created within categories, and can be created within a category at any level.
There is no limit to the number of courses that can be added to a category.
Courses are a core component, they are not pluggable.
They are also learning items.

Activities

Activities are added to courses and provide the content within the course.
The course provides the structure and flow, the activity provides the engagement and content.
Activities are created within a course. There is no limit on the number of activities that can be added to a course, other than artificial limits imposed by the format.
Activities are plugins.
They are also learning items.

Blocks

Blocks can be added to every other context. They provide encapsulated functionality, often view only. Often their content adapts to the relate to, support and enhance the functionality of the context.
Each page within with product relates to a context, and can define 0..n block regions in which blocks can be positioned.
Blocks are plugins.

Tenants

A new context level introduced in Totara 13.
Tenants are created within the system context and lead to the creation of associated structure.
More information on this new context type will be added closer to release.

Users

Each user within the application exists either at the system context or at a tenant context and has their own context.
They are a special instance, and facilitates 0..n users having rights and control over a specific users, or collection of users.

Prominent uses of contexts

The following are some of the more prominent uses of the context system within Totara.

Permissions

Capabilities define what a user can do within the product.
Capabilities are granted to roles; there are several roles provided out of the box, the site administrator can define additional roles, and customise or remove the pre-defined roles.
Roles are assigned to users at a context level.

This facilitates an exceptionally configuration permission system in which users can be given control, or have control prohibited in specific contexts.

Imagine you have a university with two schools, science and law.
Each school has their own dedicated faculty.
If a category is created for each school the faculty can be assigned management roles such as course creator and site manager within their respective schools category.
This enables them to manage the content and learning within their school, but not that of the other school.