Skip to content

Improve description of contextlevel in capability declaration #1349

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Improve description of contextlevel in capability declaration #1349

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/apis/subsystems/access.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ Where the meaning of array keys is:
| --- | --- |
| `riskbitmask` | associated risks. These are explained on [Hardening new Roles system](./roles.md). |
| `captype` | _read_ or _write_ capability type, for security reasons system prevents all write capabilities for guest account and not-logged-in users |
| `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). |
| `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 |
| `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). |
| `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` |

Expand Down
2 changes: 1 addition & 1 deletion versioned_docs/version-4.1/apis/subsystems/access.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ Where the meaning of array keys is:
| --- | --- |
| `riskbitmask` | associated risks. These are explained on [Hardening new Roles system](./roles.md). |
| `captype` | _read_ or _write_ capability type, for security reasons system prevents all write capabilities for guest account and not-logged-in users |
| `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). |
| `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 |
| `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). |
| `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` |

Expand Down
2 changes: 1 addition & 1 deletion versioned_docs/version-4.4/apis/subsystems/access.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ Where the meaning of array keys is:
| --- | --- |
| `riskbitmask` | associated risks. These are explained on [Hardening new Roles system](./roles.md). |
| `captype` | _read_ or _write_ capability type, for security reasons system prevents all write capabilities for guest account and not-logged-in users |
| `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). |
| `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 |
| `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). |
| `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` |

Expand Down
2 changes: 1 addition & 1 deletion versioned_docs/version-4.5/apis/subsystems/access.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ Where the meaning of array keys is:
| --- | --- |
| `riskbitmask` | associated risks. These are explained on [Hardening new Roles system](./roles.md). |
| `captype` | _read_ or _write_ capability type, for security reasons system prevents all write capabilities for guest account and not-logged-in users |
| `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). |
| `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 |
| `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). |
| `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` |

Expand Down
2 changes: 1 addition & 1 deletion versioned_docs/version-5.0/apis/subsystems/access.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ Where the meaning of array keys is:
| --- | --- |
| `riskbitmask` | associated risks. These are explained on [Hardening new Roles system](./roles.md). |
| `captype` | _read_ or _write_ capability type, for security reasons system prevents all write capabilities for guest account and not-logged-in users |
| `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). |
| `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 |
| `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). |
| `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` |

Expand Down