Skip to main content
The Permissions page is the catalogue of every fine-grained permission DryRunPro recognises. There are 38 permissions across roughly a dozen modules, and they are the atomic unit that Roles bundle together. Live URL:
Reach it via the User management sub-menu in the left rail, then Permissions. This page documents what each permission slug means, which module it belongs to, and which roles include it by default. Cross-link Roles for the role catalogue and Project Users for how to grant per-user overrides.

​
What you see when you land here

The page header is Permission List in bold, with a “Show / entries” pagination control below it and a Search field on the right. Below the controls, a single table with columns ID and Title. Each row is one permission slug. The list, ordered by ID descending in the screenshot:

​
Permission groups

The 38 permissions cluster into ten functional groups. Below, each group is documented with the permissions it contains and what each one gates.

​
Project access

​
Adobe Commerce (project) management

​
Staging (dryrun) management

​
Composer overrides

​
Magento Open Source extensions

​
Docker

​
AWS infrastructure

These permissions are only relevant to the AWS-hosted DryRunPro deployment (the canonical 247Commerce one). Self-hosted variants use a different infrastructure layer.

​
User-level controls

​
Default role allocation

The four default Roles bundle these permissions as follows:
  • Admin has every permission.
  • Team Leader has all adobe_*, aws_access, aws_create, aws_edit, aws_show, aws_delete, user_alert_edit, create_your_own, app_connector, team_members_access, staging_terminal_access, staging_administer_access. (Effectively everything except some niche compress / Adobe-only flags.)
  • Developer has project_overview_access, adobe_commerce_show, adobe_commerce_access, all adobe_staging_*, all adobe_compose_*, adobe_open_source, adobe_opensource_show, all adobe_docker_*, aws_access, aws_create, aws_show, user_alert_edit, create_your_own, app_connector.
  • Tester has adobe_staging_access, adobe_staging_show, audit_logs_show (where present), profile_password_edit.
For exact membership, see Roles. The chip clusters there are the source of truth.

​
Granting a permission to a single user

Sometimes you do not want to change the role definition (which would affect every user on that role); you just want to grant one extra permission to one user. The Project Users Edit dialog has a “Direct permissions” multi-select. Tick the extra permission slug, save, and the user gets it as an override on top of their role. The user’s effective permissions become the union of role + direct permissions + team-level grants.

​
Custom permissions

The 38 permissions in the catalogue are seeded by DryRunPro at deploy time. The platform does not allow tenancy admins to create new permission slugs; that requires a code change. If you need a new permission for a custom workflow, raise a feature request through your DryRunPro account manager.
  • Roles, the bundles that consume these permission slugs.
  • Project Users, where role and direct permissions are assigned.
  • Teams, the team layer that gates project access (independent of permissions).
  • Add Project, gated by adobe_commerce_create.
  • Delete Project, gated by adobe_commerce_delete.

​
Frequently asked questions

Why do I see 38 permissions in the table but the role chips show fewer? The role chips show the permissions assigned to that role. A role rarely has all 38; only Admin does. The catalogue is the universe; each role is a subset. Can I re-order the permission list? No. The list is sorted by ID descending and is not reorderable from the UI. The IDs are stable across deployments, so you can reference them in scripts. The user has the role with adobe_staging_create but cannot spin up a dryrun. Why? Permission is necessary but not sufficient. The user also needs team access to the project (or a direct project assignment). A Developer who is not on any team that includes Project X cannot spin up dryruns on Project X regardless of their role. Add the user to a team via Teams, or assign them directly via the Project Users Edit dialog. Why is adobe_staging_mcpm separate from adobe_staging_edit? Magento Cloud Patch Manager integration is a sensitive operation (it can patch the Magento core on the dryrun). It is split out so admins can grant the rest of the staging permissions without granting MCPM. Most Developers do not need MCPM. What does staging_administer_access actually unlock? The Site-Wide Analysis Tool link on the Staging Detail page. Without this permission the link is hidden. Can a permission be revoked from a single user via this page? Not from this page. The Permissions list is read-only / catalogue-only. To revoke a permission for a specific user, edit the user’s Project User record and untick the direct-permission entry, or change their role. Are permissions inherited from team membership? Some are. Teams can carry team-level permission grants that apply to every member; this is typically used to grant a tester role’s user the right to spin up dryruns when they are working on a specific project. Most tenancies do not use team-level grants; user-level overrides are simpler. Why are AWS permissions in the catalogue when my deployment is on a different cloud? The catalogue is platform-wide, not deployment-specific. AWS permissions are no-ops on non-AWS deployments. Future releases will surface deployment-relevant permissions only.