drupal / mutamad_roles
The three job roles of Mutamad and what defines each job: a content editor writes, a content approver publishes, a site administrator runs the site, its accounts and its evidence. Only Drupal core modules. Aligned to NCA ECC-2:2024 1-3-1 and 2-2.
Package info
git.drupalcode.org/project/mutamad_roles.git
Type:drupal-recipe
pkg:composer/drupal/mutamad_roles
Requires
- drupal/core: ~11.4.0
Requires (Dev)
None
Suggests
None
Provides
None
Conflicts
None
Replaces
None
This package is auto-updated.
Last update: 2026-11-12 10:13:15 UTC
README
Mutamad Roles
The three job roles of Mutamad, and what defines each job. Only Drupal core modules. Aligned to NCA ECC-2:2024 1-3-1 (separation of duties) and 2-2 (identity and access management).
Built and maintained by iSpectra.
The roles
| Role | Job | Given here |
|---|---|---|
Content Editor (content_editor) | Writes and edits content, and submits it for review | The content list, the files list, every revision, reverting a revision, their own drafts |
Content Reviewer (content_approver) | Reviews and publishes — never their own work | The content list, every revision |
App Admin (IT) (site_admin) | Runs the site: its configuration, its accounts and its evidence. Publishes no content; writes none but Canvas Pages, which a Content Reviewer publishes | The administration pages, site configuration, menus, user accounts, the content and files lists, site reports, every revision |
The names are the ones people see; the machine names in brackets are what
the other recipes grant to. None is an admin role, so none silently gains the
permissions of a module installed later. The site's administrator role
stays the break-glass account.
Separation of duties. Whoever writes does not publish, and a Content Reviewer does not publish their own work. The App Admin, who manages accounts, can make Content Editors only; reviewers and app admins are made by the administrator, and their accounts cannot be taken over by changing an email or password. So nobody can make or borrow a second account to approve their own work.
What else gives these roles their permissions
This recipe creates the roles; each Mutamad recipe grants them the permissions for its own area, and applies this recipe first:
| Recipe | Adds |
|---|---|
| Mutamad Security | Password policies per role; the site administrator assigns the editor role only; flood unblocking |
| Mutamad Crypto | MFA, required for the approver, the site administrator and the administrator |
| Mutamad Workflow | Submitting (editor) and publishing, returning, archiving (approver) |
| Mutamad Admin | Protects approver and site administrator accounts: only the administrator changes their email, password or roles |
| Mutamad Media, Editor, Forms, Multilingual | Their area's permissions |
Why a recipe of its own
A recipe cannot grant a permission "only if the role exists": on Drupal 11.4 a grant to a missing role stops the recipe. So every recipe that grants to the job roles applies this one first. Being small, and using only core modules, it lets a single Mutamad recipe — media, forms, the workflow — be applied to a vanilla Drupal site with just these three roles, not Mutamad's whole security baseline.
Requirements
Drupal core 11.4.
Apply it to an existing site
composer require drupal/mutamad_roles
drush recipe ../recipes/mutamad_roles
A role that already exists under the same machine name — content_editor,
which core's Standard recipe creates, for one — is kept and only gains
permissions. Recipes cannot remove a permission or a role.
License
GPL-2.0-or-later.