Roles, Capabilities and Archetypes
Introduction
What are they? In this post I’ll give a brief overview as an entry point for you to discover more with your system and the online documentation.
Disclaimers
I am independent from organisations mentioned and am in no way writing for or endorsed by them.
Names / logos can be trademarks of their respective owners. Please review their websites for details.
The information presented in this article is written according to my own understanding, there could be technical inaccuracies, so please do undertake your own research.
Additional references
- Moodle – moodle.org
- Role archetypes – docs.moodle.org/400/en/Creating_custom_roles#Role_archetypes
- Roles documentation category – docs.moodle.org/400/en/Category:Roles
- Roles and permissions – docs.moodle.org/400/en/Roles_and_permissions
Overview
The ability do undertake any form of action within Moodle is governed by a given user having the ‘capability’, the ‘permission’ to perform that action. Here a ‘user’ can be in one of three states: not logged in but as ‘Guest’ role by default, logged in as a ‘guest’ and an ‘authenticated user’. Each of the states is assigned a role, and for the latter, that can change depending on where that user is on the site, the ‘Context’. Typically everyone is an ‘authenticated user’ when they log into the system, and then that can change if they are assigned a role at site level or enrol on a course, but that is not an exhaustive list of situations.
Context
A ‘Context’ is the ‘area’ where you are within the system as you navigate around it – docs.moodle.org/400/en/Context.
Capability
A capability is a permission, or not, to perform a discrete action, such as view a course or grade an assignment. Moodle comes with lots, docs.moodle.org/400/en/Category:Capabilities, and contributed plug-ins can add more to compliment their functionality.
Role
A ‘role’ is simply a named collection of capabilities and is applied at a given ‘Context’, docs.moodle.org/400/en/Assign_roles. There is a hierarchy of ‘Context’s whereby the permission to do something can be inherited in a module from the course if it was permitted to do so by the role the user was assigned on the course.
Archetypes
These are the standard ‘templates’ that used to define the core roles, docs.moodle.org/400/en/Standard_roles. The key thing is to think of them as a starting point, and then adjust your system to suit your situation.
Not constrained
Even though you are by default supplied by roles you can assign to a user that will feel familiar, you’re not constrained in any way. You can adjust the capabilities of a role and create your own roles. Moodle takes the view that you’re assigned the ‘permission’ to do something at a given point, the ‘context’. This makes it very flexible, for example, a teacher on one course can be a student on another, for example, a staff training course. You can find more examples on docs.moodle.org/400/en/Using_roles.
Overriding
This allows you to adjust a role in a specific context to suit your needs, docs.moodle.org/400/en/Override_permissions, if you want to make a small change to a role without creating and assigning a new one. For example, you may wish for a ‘student’ to be able to peer review and grade another student’s work on a course. This would normally be done by a teacher, but there is nothing to stop you making that happen.
Additionally, the site administrator is not overloaded with all of the administration work, as certain roles can undertake the administrative process and adjust the permissions of a given role within a context. The capability to do this is also dynamic and can be changed, as the ability to ‘override’ is a capability, in fact, two: docs.moodle.org/400/en/Capabilities/moodle/role:override and docs.moodle.org/400/en/Capabilities/moodle/role:safeoverride.
Summary
Moodle is not constrained by fixed ‘stereotypes’ by implementing a dynamic permissions system. It does this by having a hierarchy of contexts (smaller and smaller elements, i.e. a course is ‘smaller’ than the ‘site’) where a user of the site is assigned a ‘role’ being a collection of ‘capabilities’ that state the permission to do something.
Whilst from the initial outset, this solution seems complex, it is in fact flexible, even if it does take (at least to me) a bit of time to get your head around it! I hope this all makes sense and is a starting point for you to learn more about it and how you can make adjustments to your site, but please do practice on a test server first! Complex and powerful systems are great, but they come with risk.
Conclusion
What do you think? Please let me know in the comments.
- Debugging SCSS – 16th November 2024
- Settings transfer – 16th October 2024
- Added value – 16th September 2024
