Actions

Actions provide an extensible mechanism to concisely describe which users are allowed to perform an action and enforce permissions.

Actions have an API code, used to construct the Action object, a title, which may be used in an administrative user interface to allow further configuration, and a number of allow and deny rules.

To be permitted to perform an action, the user must match at least one allow rule and not match any deny rules (or be allowed by the special "std:action:administrator_override" action).

Rules check permissions of users. The platform implements rules for whether a user is a member of a given group, and plugins can extend this mechanism to other properties of the user. See below for the extensibility mechanism.

Whether an action can be performed by a user is checked by calling allowed() on a SecurityPrincipal object, or enforced for the current user with the enforce() function on the Action object.

Interface

function O.action(code)

If plugins are being loaded, the action will be created it if it doesn’t already exist, otherwise an exception will be thrown. This ensures that, while actions can be obtained at any time given an API code, after the plugins are loaded, the platform has a complete list of all possible actions for administrative UI.

Extensibility

Writing rules using groups is sufficient for many applications, but custom permission systems may allow you to write rules using other properties. For example, a role based permission system may allow you to write:

To implement another kind of rule, plugins implement the std:action:check:X service, where X is the kind. The service function takes two arguments, user and the thing passed to the allow or deny rule, and returns true if the rule matches.

For example, the pluggable role based permission may implement the service like this: