Advanced Admin Permissions Command Line Reference

Beta - commands may change

Advanced Admin Permissions is in beta. Command names, arguments and output may change in backwards-incompatible ways before the general release. Pin the module version if you script against them.

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 five commands live under the hyva:admin-permissions namespace. The hyva:admin-permissions:scope command only exists when the Hyva_AdvancedAdminPermissionsScope module is 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.

bin/magento hyva:admin-permissions:effective [<user>] [-i|--integration=<name-or-id>] [-a|--all]

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:

--websites and --stores are mutually exclusive.
--off and --inherit are mutually exclusive.
Neither --off nor --inherit can be combined with a --websites or --stores list.

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.

bin/magento hyva:admin-permissions:set-negative-role <role-id> [--off]

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.

bin/magento hyva:admin-permissions:set-role-expiry <user> <role> [<when>] [-c|--clear]

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 --clear is 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.

bin/magento hyva:admin-permissions:revoke-expired-grants

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".

Extension Points - teaching scope restriction about an entity that scopes itself some other way.
Website and Store View Restriction - what the scope command's restrictions actually do.
Time-Boxed Role Grants - the admin panel side of role expiries.
Effective Permissions Viewer - the admin panel side of the effective command.