Advanced Admin Permissions FAQs

Yes. Your existing roles and assignments are unchanged, and nothing is restricted, negative or time-boxed until you set it. Advanced Admin Permissions stores additional roles as extra native authorization_role rows, so no migration runs against your existing users. The permission guardrails apply immediately, though: no admin can change their own roles, and an admin can only change, delete or unlock an account whose roles they could grant themselves. See Installing Advanced Admin Permissions.

Yes. The package contains two Magento modules, and the website and store view restriction lives entirely in Hyva_AdvancedAdminPermissionsScope. Disable that module and you keep multiple roles, negative roles, expiring grants, bulk assignment, integration roles, the audit log and the effective-permissions viewer. See What the Package Installs.

No. Each role is indexed once - the answer the ACL gives for every resource - and the index is cached in Magento's own ACL data cache, so a multi-role request 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. The cache rides on Magento's existing ACL invalidation, so saving a role's resources or rebuilding the resource tree clears it.

Yes. Changing anyone's roles raises their ACL reload flag, so an admin who is logged in while their roles change stops answering permission checks with the roles they used to have. Magento caches the role on the session, and nothing but a save of the user clears it, which is why the flag matters.

Deny wins, but only for a role explicitly flagged as negative. Ordinary roles combine as a union, so access is granted when any of them allows the resource. A negative role's resources become denials that override grants from the user's other roles. See Negative (Deny) Roles.

Check the user's own Scope Restriction tab. A restriction stored on the user overrides their roles entirely, so a user set to Not restricted works in every scope regardless of what their roles say. Leave users on Inherit from the assigned roles unless you specifically want an exception. See How Role and User Restrictions Combine.

Restricting an admin to a store view does not narrow website-scoped data below the website that store view belongs to. Products, prices and cart rules belong to a website, and there is no smaller box to put them in. If you need the narrower boundary, restrict by website instead and split the catalog across websites.

Magento ships Home, 404 Not Found and Enable Cookies as All Store Views CMS pages. Global data is readable but not writable for a restricted admin, because every store view without an override inherits it, so saving one would change what store views outside their reach display. Give each website or store view its own copy of those pages if your restricted admins need to edit them. See Reading Global Data and Writing It Are Different Questions.

Yes. User and role management are not denied to restricted admins. A website manager can add colleagues, assign them roles and unlock their accounts. The permission guardrails keep that safe rather than taking the screens away: they cannot edit their own access, cannot grant a role they could not grant themselves, cannot allow a website or store view they cannot reach, and cannot change an account whose roles reach further than their own. So the colleagues they set up end up restricted at least as narrowly as they are.

Some admin areas are global by nature and there is nothing in them to narrow, so Advanced Admin Permissions denies their ACL resources to restricted admins rather than filtering them, which takes the menu entries with them. The full list, and why each one is on it, is in Areas That Are Denied Rather Than Narrowed. The list is a di.xml argument, so you can draw your own line.

Mostly, yes. Enforcement follows the conventions Magento itself uses - a store_id or website_id column on the main table, a <table>_store or <table>_website link table, the catalog product website assignment - so entities that follow those conventions are covered without anyone writing code. An entity whose scope cannot be determined is allowed through, so it is not an allowlist. For an entity that scopes itself some other way, add a strategy through Extension Points.

Advanced Admin Permissions refuses a grant when the role reaches further than the acting admin does, refuses any change to your own access, refuses changes to an account whose roles reach further than yours, and caps grants at your own expiry horizon when all of your grants are time-boxed. The Role Assignment Audit Log records the refusal with its reason, and the Effective Permissions viewer shows which resources you're missing. See Permission Guardrails.

Anyone who can run bin/magento on the server can lift any scope restriction (hyva:admin-permissions:scope … --off), clear negative flags (hyva:admin-permissions:set-negative-role --off), create a full administrator (admin:user:create) or write to the database directly, and the guardrails check none of it. The privilege escalation guards only apply when an admin is acting through the panel or the API, because the CLI, cron and data patches have no session to escalate from and gating them would make the module impossible to seed. Treat shell access as equivalent to full administrator access.

Yes. The audit grid is governed by its own ACL resource, Hyva_AdvancedAdminPermissions::audit, which appears in the role resource tree under System → Permissions as Role Assignment Audit Log. Grant it to the roles that should be able to read the log.

Beta feedback is exactly what this release is for. See Providing Feedback & Getting Help for the community Slack, technical support and how to report bugs.