Advanced Admin Permissions Command Line Reference
Everything Advanced Admin Permissions adds to the admin panel is also available from bin/magento, which is what you want for deployment scripts, scheduled audits and seeding a fresh environment. All commands live under the hyva:admin-permissions namespace. The hyva:admin-permissions:scope command only exists when the Hyva_AdvancedAdminPermissionsScope module is enabled, and the hyva:admin-permissions:import-role-scopes command only on Adobe Commerce, with the Hyva_AdvancedAdminPermissionsEnterprise module enabled.
The command line bypasses the permission guardrails
The guardrails that stop an admin widening their own access only apply when an admin is acting through the panel or the API. The CLI, cron, data patches and the installer have no session to escalate from, so these commands are not gated by the escalation guardrails. Integrity checks still apply, though: set-negative-role refuses to flag an all-resources role or one that would lock a holder out, and exits with a failure. Treat shell access to the Magento installation as equivalent to full administrator access.
Showing Effective Permissions
hyva:admin-permissions:effective prints everything an admin user or integration can reach, and which role grants each resource. It is the command line form of the Effective Permissions viewer.
| Argument or option | Meaning |
|---|---|
<user> |
Admin username or user id. Optional, and left out when --integration is used. |
-i, --integration=<name-or-id> |
Show the permissions of an integration instead, by name or id. |
-a, --all |
Also list denied resources. Without it, only allowed resources are listed. |
Check what one admin user is allowed, then the full picture including denials:
bin/magento hyva:admin-permissions:effective jane
bin/magento hyva:admin-permissions:effective jane --all
bin/magento hyva:admin-permissions:effective --integration=my-erp --all
Setting a Scope Restriction from the Command Line
hyva:admin-permissions:scope shows or changes the website and store view restriction of a role, admin user or integration. Run it with no options to print the current state, which is the quickest way to answer "why can this person not see that website?".
bin/magento hyva:admin-permissions:scope <role|user|integration> <id> [--websites=<ids>] [--stores=<ids>] [--off] [--inherit]
| Argument or option | Meaning |
|---|---|
<owner-type> |
One of role, user or integration. |
<owner-id> |
The role id, admin user id or integration id. The id must exist, and a role id must belong to a group role. |
--websites=<ids> |
Restrict to these website ids, comma separated. The ids must exist. |
--stores=<ids> |
Restrict to these store view ids, comma separated. The ids must exist. |
--off |
Remove the restriction, so this owner is explicitly not restricted. On a role, this just leaves the role unrestricted: it contributes nothing and does not override the user's other roles. |
--inherit |
Users and integrations only: fall back to the restrictions of their roles. Not valid on a role. |
The scope options combine under these rules:
--websitesand--storesare mutually exclusive.--offand--inheritare mutually exclusive.- Neither
--offnor--inheritcan be combined with a--websitesor--storeslist.
Restrict a role to two websites, restrict one user to a single store view, then inspect and reset that user:
bin/magento hyva:admin-permissions:scope role 3 --websites=1,2
bin/magento hyva:admin-permissions:scope user 7 --stores=2
bin/magento hyva:admin-permissions:scope user 7
bin/magento hyva:admin-permissions:scope user 7 --inherit
bin/magento hyva:admin-permissions:scope integration 4 --stores=2
Remember that --off and --inherit mean different things on a user. --inherit hands the decision back to the user's roles, while --off stores an explicit "not restricted" that overrides those roles. See Website and Store View Restriction.
Flagging a Role as Negative (Deny)
hyva:admin-permissions:set-negative-role flags or unflags a group role as a negative (deny) role, whose resources become denials that override grants from a user's other roles.
| Argument or option | Meaning |
|---|---|
<role-id> |
The group role id to flag. |
--off |
Remove the negative flag, turning the role back into an ordinary one. |
The set-negative-role command fails with "No group role found for that ID." when the id does not belong to a group role. Flagging a role is also refused, and the command exits with a failure, when the role allows all resources or when flagging it would leave any holder with no role that grants anything. Removing the flag is never refused.
Flagging a role as negative removes the end dates of that role's existing grants, because a negative role's grant cannot have an end date.
Flag role 4 as a deny role, then turn it back into an ordinary role:
bin/magento hyva:admin-permissions:set-negative-role 4
bin/magento hyva:admin-permissions:set-negative-role 4 --off
Setting or Clearing a Role Grant Expiry
hyva:admin-permissions:set-role-expiry sets or clears the expiry on an existing role grant of an admin user, for scripting a handover or an offboarding.
| Argument or option | Meaning |
|---|---|
<user> |
Admin username or user id. |
<role> |
Group role id whose grant expires. The role must already be assigned to the user. |
<when> |
Expiry date and time, exactly in the format YYYY-MM-DD HH:MM:SS, in the admin timezone and in the future. For example "2026-12-31 23:59:00". |
-c, --clear |
Clear the expiry instead of setting it, making the grant permanent. |
The set-role-expiry command refuses these inputs:
- A role that is not assigned to the user fails with "That role is not assigned to the user; assign it first."
- Leaving out both
<when>and--clearis an error. - A negative role's grant cannot have an end date.
Time-box a contractor's role until the end of March 2027, then make it permanent again:
bin/magento hyva:admin-permissions:set-role-expiry contractor 5 "2027-03-31 23:59:00"
bin/magento hyva:admin-permissions:set-role-expiry contractor 5 --clear
Revoking Expired Grants on Demand
hyva:admin-permissions:revoke-expired-grants removes the role assignments and expiry records of grants whose expiry has passed. It takes no arguments.
This is cleanup only. A lapsed grant has already stopped granting access by the time this runs, because expiry is enforced at permission-check time. The same job runs hourly through cron as hyva_advanced_admin_permissions_revoke_expired_grants, so a stopped cron delays the tidying, not the expiry. Each removed grant, for admin users and integrations alike, is recorded in the audit log as Revoked with the reason "Grant expired".
Importing Adobe Commerce Role Scopes
hyva:admin-permissions:import-role-scopes takes Adobe Commerce role scopes (Magento_AdminGws) over into Advanced Admin Permissions scope restrictions. It is only available on Adobe Commerce, with the Hyva_AdvancedAdminPermissionsEnterprise module enabled. The import-role-scopes command has this signature:
| Option | Meaning |
|---|---|
| (none) | Show what was or would be imported, without changing anything. |
--apply |
Import the role scopes and set the imported roles to "all scopes" in Adobe Commerce. |
--prefer=adobe-commerce |
For a role restricted by both, replace the role's own restriction with its imported Adobe Commerce role scope. |
--prefer=hyva |
For a role restricted by both, keep the role's own restriction and drop its Adobe Commerce role scope. |
The import-role-scopes command prints one row per role that Adobe Commerce limits, with its Adobe Commerce role scope, the restriction it maps to, and one of these statuses:
import- the role is imported, or would be imported.conflict- the role already has a restriction of its own. It's left alone unless you pass--prefer.skip- none of the role's websites or store groups exist anymore. Give the role a restriction, then run the command again with--prefer=hyva.
The same import runs automatically as a data patch on the first setup:upgrade after installation. Run the command afterwards to see what the data patch did and to settle the roles it left alone:
bin/magento hyva:admin-permissions:import-role-scopes
bin/magento hyva:admin-permissions:import-role-scopes --apply --prefer=hyva
While any role is unsettled, the import-role-scopes command warns you to keep Magento_AdminGws enabled: once it is disabled, setup:upgrade drops the columns its role scopes are kept in. See Adobe Commerce Support for the full picture.
Related Topics
- Extension Points - teaching scope restriction about an entity that scopes itself some other way.
- Website and Store View Restriction - what the
scopecommand's restrictions actually do. - Time-Boxed Role Grants - the admin panel side of role expiries.
- Effective Permissions Viewer - the admin panel side of the
effectivecommand.