Skip to content

Commit e9117ab

Browse files
NeillMNeillM
committed
#1339 Improve description of contextlevel in capability declaration
There was confusion in the developer chat channel around how the context level should be set in. This change will hopefully help make it clear how the context level should be set and what its effect is.
1 parent 0e98be8 commit e9117ab

File tree

5 files changed

+5
-5
lines changed

5 files changed

+5
-5
lines changed

‎docs/apis/subsystems/access.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -62,7 +62,7 @@ Where the meaning of array keys is:
6262
| --- | --- |
6363
| `riskbitmask` | associated risks. These are explained on [Hardening new Roles system](./roles.md). |
6464
| `captype` | _read_ or _write_ capability type, for security reasons system prevents all write capabilities for guest account and not-logged-in users |
65-
| `contextlevel` | specified as context level constant. Declares the typical context level where this capability is checked. This capability can be checked with contexts that are at a lower level (e.g. `moodle/site:accessallgroups` could be checked with CONTEXT_MODULE). |
65+
| `contextlevel` | specified as context level constant. Declares the lowest context level where this capability is checked. The definition affects where users have the ability to override the capability, for example if a capability is defined as having a `CONTEXT_SYSTEM` context users would not be able to override it at any other levels; however if it was set at `CONTEXT_MODULE` user would be able to override it at the activity, course, and category levels |
6666
| `archetypes` | specifies defaults for roles with standard archetypes, this is used in installs, upgrades and when resetting roles (it is recommended to use only CAP_ALLOW here). Archetypes are defined in mdl_role table. See also [Role archetypes](https://docs.moodle.org/dev/Role_archetypes). |
6767
| `clonepermissionsfrom` | when you are adding a new capability, you can tell Moodle to copy the permissions for each role from the current settings for another capability. This may give better defaults than just using archetypes for administrators who have heavily customised their roles configuration. The full syntax is: `clonepermissionsfrom` => `moodle/quiz:attempt` |
6868

‎versioned_docs/version-4.1/apis/subsystems/access.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -62,7 +62,7 @@ Where the meaning of array keys is:
6262
| --- | --- |
6363
| `riskbitmask` | associated risks. These are explained on [Hardening new Roles system](./roles.md). |
6464
| `captype` | _read_ or _write_ capability type, for security reasons system prevents all write capabilities for guest account and not-logged-in users |
65-
| `contextlevel` | specified as context level constant. Declares the typical context level where this capability is checked. This capability can be checked with contexts that are at a lower level (e.g. `moodle/site:accessallgroups` could be checked with CONTEXT_MODULE). |
65+
| `contextlevel` | specified as context level constant. Declares the lowest context level where this capability is checked. The definition affects where users have the ability to override the capability, for example if a capability is defined as having a `CONTEXT_SYSTEM` context users would not be able to override it at any other levels; however if it was set at `CONTEXT_MODULE` user would be able to override it at the activity, course, and category levels |
6666
| `archetypes` | specifies defaults for roles with standard archetypes, this is used in installs, upgrades and when resetting roles (it is recommended to use only CAP_ALLOW here). Archetypes are defined in mdl_role table. See also [Role archetypes](https://docs.moodle.org/dev/Role_archetypes). |
6767
| `clonepermissionsfrom` | when you are adding a new capability, you can tell Moodle to copy the permissions for each role from the current settings for another capability. This may give better defaults than just using archetypes for administrators who have heavily customised their roles configuration. The full syntax is: `clonepermissionsfrom` => `moodle/quiz:attempt` |
6868

‎versioned_docs/version-4.4/apis/subsystems/access.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -62,7 +62,7 @@ Where the meaning of array keys is:
6262
| --- | --- |
6363
| `riskbitmask` | associated risks. These are explained on [Hardening new Roles system](./roles.md). |
6464
| `captype` | _read_ or _write_ capability type, for security reasons system prevents all write capabilities for guest account and not-logged-in users |
65-
| `contextlevel` | specified as context level constant. Declares the typical context level where this capability is checked. This capability can be checked with contexts that are at a lower level (e.g. `moodle/site:accessallgroups` could be checked with CONTEXT_MODULE). |
65+
| `contextlevel` | specified as context level constant. Declares the lowest context level where this capability is checked. The definition affects where users have the ability to override the capability, for example if a capability is defined as having a `CONTEXT_SYSTEM` context users would not be able to override it at any other levels; however if it was set at `CONTEXT_MODULE` user would be able to override it at the activity, course, and category levels |
6666
| `archetypes` | specifies defaults for roles with standard archetypes, this is used in installs, upgrades and when resetting roles (it is recommended to use only CAP_ALLOW here). Archetypes are defined in mdl_role table. See also [Role archetypes](https://docs.moodle.org/dev/Role_archetypes). |
6767
| `clonepermissionsfrom` | when you are adding a new capability, you can tell Moodle to copy the permissions for each role from the current settings for another capability. This may give better defaults than just using archetypes for administrators who have heavily customised their roles configuration. The full syntax is: `clonepermissionsfrom` => `moodle/quiz:attempt` |
6868

‎versioned_docs/version-4.5/apis/subsystems/access.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -62,7 +62,7 @@ Where the meaning of array keys is:
6262
| --- | --- |
6363
| `riskbitmask` | associated risks. These are explained on [Hardening new Roles system](./roles.md). |
6464
| `captype` | _read_ or _write_ capability type, for security reasons system prevents all write capabilities for guest account and not-logged-in users |
65-
| `contextlevel` | specified as context level constant. Declares the typical context level where this capability is checked. This capability can be checked with contexts that are at a lower level (e.g. `moodle/site:accessallgroups` could be checked with CONTEXT_MODULE). |
65+
| `contextlevel` | specified as context level constant. Declares the lowest context level where this capability is checked. The definition affects where users have the ability to override the capability, for example if a capability is defined as having a `CONTEXT_SYSTEM` context users would not be able to override it at any other levels; however if it was set at `CONTEXT_MODULE` user would be able to override it at the activity, course, and category levels |
6666
| `archetypes` | specifies defaults for roles with standard archetypes, this is used in installs, upgrades and when resetting roles (it is recommended to use only CAP_ALLOW here). Archetypes are defined in mdl_role table. See also [Role archetypes](https://docs.moodle.org/dev/Role_archetypes). |
6767
| `clonepermissionsfrom` | when you are adding a new capability, you can tell Moodle to copy the permissions for each role from the current settings for another capability. This may give better defaults than just using archetypes for administrators who have heavily customised their roles configuration. The full syntax is: `clonepermissionsfrom` => `moodle/quiz:attempt` |
6868

‎versioned_docs/version-5.0/apis/subsystems/access.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -62,7 +62,7 @@ Where the meaning of array keys is:
6262
| --- | --- |
6363
| `riskbitmask` | associated risks. These are explained on [Hardening new Roles system](./roles.md). |
6464
| `captype` | _read_ or _write_ capability type, for security reasons system prevents all write capabilities for guest account and not-logged-in users |
65-
| `contextlevel` | specified as context level constant. Declares the typical context level where this capability is checked. This capability can be checked with contexts that are at a lower level (e.g. `moodle/site:accessallgroups` could be checked with CONTEXT_MODULE). |
65+
| `contextlevel` | specified as context level constant. Declares the lowest context level where this capability is checked. The definition affects where users have the ability to override the capability, for example if a capability is defined as having a `CONTEXT_SYSTEM` context users would not be able to override it at any other levels; however if it was set at `CONTEXT_MODULE` user would be able to override it at the activity, course, and category levels |
6666
| `archetypes` | specifies defaults for roles with standard archetypes, this is used in installs, upgrades and when resetting roles (it is recommended to use only CAP_ALLOW here). Archetypes are defined in mdl_role table. See also [Role archetypes](https://docs.moodle.org/dev/Role_archetypes). |
6767
| `clonepermissionsfrom` | when you are adding a new capability, you can tell Moodle to copy the permissions for each role from the current settings for another capability. This may give better defaults than just using archetypes for administrators who have heavily customised their roles configuration. The full syntax is: `clonepermissionsfrom` => `moodle/quiz:attempt` |
6868

0 commit comments

Comments
 (0)