Changelog - Advanced Admin Permissions

All notable changes to Advanced Admin Permissions are documented in this file.

The format is based on Keep a Changelog.

[0.1.0] - 2026-09-30

The 0.1.0 release for Advanced Admin Permissions is the initial (beta) release.

Added

• Multiple admin roles per user. The User Role tab is a multi-select checkbox grid, the users grid lists every role a user holds, and permission checks in the admin panel and the REST, SOAP and GraphQL APIs consider all of a user's roles: access is granted when any assigned role allows the resource. Existing single-role users keep their role and behavior unchanged, and roles are stored as multiple native authorization_role rows, so no database schema changes are made. The Role Users tab on a role only touches users whose membership of that role changed, so saving a role no longer strips its holders' other roles or expiry dates.
• Negative (deny) roles. A group role can be flagged as negative, so the resources it lists become denials that override grants from a user's other roles. Only fully ticked resources are denied, and the top-level admin resource never is. Set the flag with the Negative (deny) role checkbox on the role's Role Resources tab, or with hyva:admin-permissions:set-negative-role. Flagging is refused when the role allows all resources, when the acting admin holds the role, or when it would leave any holder with no role that grants anything. A negative role's grant cannot have an end date, and flagging a role deletes the existing end dates of its grants. The roles grid gains a sortable, filterable Negative column.
• Scope restriction by website or store view. A Scope Restriction tab on the role, admin user and integration edit pages limits what each one can see and change. The tab appears once the role, user or integration has been saved. Roles combine as a union, a restriction stored on the user or integration overrides their roles, and a role with nothing configured contributes nothing to that union.
• Scope restriction enforcement across the admin panel and the REST and SOAP APIs (GraphQL is not scope-restricted). Collections behind grids, dropdowns and mass actions are narrowed, entities loaded directly by id are blanked, saves and deletes outside the allowed scopes are refused, store and website pickers only offer permitted scopes, and system and design configuration only open and save the scopes the admin holds. Detection follows the conventions Magento itself uses, so most custom entities are covered too.
• Global data handling for restricted admins. Store view 0 stays readable but is not writable, because every store view without an override inherits it. A restricted admin cannot change a product's or category's default values unless they hold every store view inheriting them, cannot assign a record to All Store Views or move one there, and cannot save a record spanning into a scope they lack.
• Denial of globally-scoped admin areas to restricted admins, including Data Transfer, All Stores, Taxes, Backups, Integrations, Currency Rates, Attributes, Customer Groups, Order Status and Index Management. The list is a di.xml argument, so an installation can draw its own line.
• Time-boxed (expiring) role grants. The User Role tab gains an Expires (admin timezone) column per role, backed by a hyva_permissions_role_grant_expiry table. Expired grants stop granting access immediately at permission-check time, and an hourly cron job removes what is left of them. CLI: hyva:admin-permissions:set-role-expiry (admin users only) and hyva:admin-permissions:revoke-expired-grants.
• Bulk role assignment. The admin users grid gains Assign a role and Remove a role mass actions. The chosen role is added to or removed from every selected user while leaving their other roles untouched, the acting admin's own account is skipped, and the run is one transaction.
• Role-assignment audit log. A read-only grid at System → Permissions → Role Assignment Audit records every role grant and revocation with the target, role, acting admin and timestamp, filterable by all of them plus action and date range. Revocations are recorded wherever they happen: on the user and role forms, through the mass actions, when the hourly cleanup or revoke-expired-grants removes a lapsed grant (reason "Grant expired"), and when a role is deleted (reason "Role deleted"). Flagging and unflagging a negative role is recorded too. Attempts that did not take effect are recorded as Grant failed, Revocation failed or Making a role negative failed with the reason, on every path. Usernames and role names are denormalized so the log stays readable after a user or role is deleted, and entries are kept indefinitely.
• Roles for integrations. An integration's API tab gains a Roles option in Resource Access, next to Custom and All. Granted roles are unioned with the integration's own resources at every REST, SOAP and GraphQL permission check, and a negative role among them wins over both. A scope-restricted role restricts the integration's REST and SOAP calls as well, and an integration can carry a restriction of its own. Grants live in a hyva_permissions_integration_role table and are recorded in the audit log, which gains a Target Type column.
• Effective-permissions viewer. An Effective Permissions tab on the admin user and integration edit pages renders the full ACL resource tree with an allowed or denied marker and the granting role per resource. hyva:admin-permissions:effective prints the same on the command line, with --all also listing denied resources. Every verdict comes from Magento's own Authorization::isAllowed(), so the view cannot drift from what the application enforces.
• Privilege escalation guards, enforced wherever access can be widened and only when an admin is actually acting: an admin cannot change their own role assignments, scope restriction or grant expiries, in either direction; a role may only be granted when the acting admin is allowed every resource that role allows, and a role's resources can only be set to what the acting admin is allowed; turning a negative role back into an ordinary one counts as a grant; an admin may only change, delete or unlock an account whose every role they could grant themselves (its two-factor reset included); and an admin whose own grants all carry an expiry cannot create access that ends later than theirs. Taking ACL access away from someone else is never refused by these rules. A scope-restricted admin cannot, however, remove a role, delete a role or set an end date on a grant when the user would afterwards reach a website or store view the admin cannot reach.
• User and role management stay available to restricted admins. A restricted admin can add colleagues, assign them roles and unlock their accounts; the privilege escalation guards keep them from passing on more than their own reach, so the colleagues they set up are restricted at least as narrowly as they are. See Restricted Admins Can Manage Their Own Team.
• Extension points for scope restriction: ScopeCollectionFilterInterface, ScopeEntityGuardInterface and ScopeWriteRuleInterface, all resolved through ordered di.xml pools.
• CLI commands hyva:admin-permissions:effective, hyva:admin-permissions:scope (only with Hyva_AdvancedAdminPermissionsScope enabled), hyva:admin-permissions:set-negative-role, hyva:admin-permissions:set-role-expiry and hyva:admin-permissions:revoke-expired-grants.

Changed

• Permission checks for an identity with more than one role no longer assemble an ACL of every role's rules on each request. Each role is indexed once and the index is cached in Magento's ACL data cache, riding on its existing invalidation, so a multi-role request now costs about what a single-role one does. Measured on a 305-resource installation, the first check of a two-role request went from around 25 ms to around 8 ms.

Known Limitations

• Adobe Commerce is not supported in 0.1.0. Its own role scopes would apply on top of the scope restriction, and the role edit page would show two scope editors saving independently. Adobe Commerce support follows in a later release.
• Only the admin panel and the REST and SOAP APIs are scope-restricted. GraphQL is not scope-restricted, although the combined permissions of an identity's roles do apply to it.
• Asynchronous and bulk REST requests (/rest/async/… and /rest/async/bulk/…) are refused to a restricted admin or integration token, because their work runs later in a queue consumer where no restriction can be applied.
• Background processes run outside the enforced areas by design, so most things a restricted admin can queue run unrestricted. A restricted admin can therefore queue a newsletter to store views they do not hold. The catalog Update Attributes mass action is checked when it is submitted.
• Widget instances store their scope in a comma separated store_ids column, which the write rule reads but the collection filter does not, so they appear in the grid outside the admin's scopes even though they cannot be saved.
• Category collections are not filtered, only the admin category tree and the product form's category picker, because filtering a collection would make the "Update on Save" indexers write a partial index.
• Magento's own All Store Views CMS pages (Home, 404 Not Found, Enable Cookies) become read-only for restricted admins.
• The command line is not covered by the privilege escalation guards. The CLI, cron, data patches and the installer have no admin session to escalate from, so shell access to the Magento installation is equivalent to full administrator access. Integrity checks, such as the refusal to flag an all-resources role as negative, still apply on the command line.