A hidden field is not a permission

A store with four administrators eventually needs a fifth who should see less. A regional manager for one country. An agency editing content in two store views. A supplier's merchandiser who owns one category and nothing else. Adobe Commerce answers that with scoped roles; Magento Open Source answers it with a list of admin resources and no notion of which website, store view or category a role may act on.

So the gap gets closed by convention. Someone is told which store view to use. Everyone agrees not to touch the other one. It works until it does not, and when it does not there is no record of what happened, only a changed price and four people who did not do it.

What it is for

Admin Role Access Control gives a role a scope and enforces it. A Store Scope tab on each admin role names the websites and store views that role may work in – ticking a website grants all of its store views – and everything downstream respects it: orders, invoices, shipments, credit memos, customers and products. Out-of-scope records do not appear in grids. Mass actions cannot reach them. A direct URL to one returns 404. The admin store switcher offers granted store views only, on every screen that renders it, reports and the dashboard included.

New roles start restricted. That direction matters more than it sounds: a model that is open until someone remembers to close it fails silently, and a model that is closed until someone opens it fails loudly, on the first day, in front of the person who can fix it.

How it can be used

Scoped by store view, for a regional team. The base case. A role covers one website; its holders see that website's orders and customers and nothing else, and cannot switch context to a store view they were not granted.

Scoped by category, for a merchandising team. The category tree, the product form's category picker, the new-category dialog, autocomplete, the widget chooser and admin global search all show granted trees only. Creating, saving, moving or deleting a category outside the scope is refused – including moving an outside category into the scope, which is the loophole this class of feature usually leaves open.

Scoped by field, for a role that may edit products but not prices. Per-role Attribute Permissions hide product and category attributes and whole attribute groups, in Deny mode (hide the selected) or Allow mode (show only the selected). Attributes added by other extensions are covered automatically, and hiding a required field does not break saving, because stored values are preserved rather than blanked.

Opted out, for the people who need everything. An "Allow access to ALL" toggle lifts scoping for a role, and the built-in Administrator role is unrestricted automatically and cannot be locked out. A dedicated ACL resource controls who may edit a role's scope at all, so the ability to widen one's own access is itself a permission.

How it compares

Measured on 2026-09-03 by opening four live Marketplace listings in a browser, reading the price rendered for each edition rather than the one in the page's structured data – which is wrong on three of the four.

Everything comparable files under Content & Customizations → Personalization & Experience Management. On the Magento Open Source tier: MageAnts 69.00 and AITOC 79.00, both one-time; Amasty 265.00 per year, the only listing in the set with a published rating (3.0 from two reviews). Against that, this extension is 149,99 €, once – roughly double the one-time pair, and cheaper than the subscription from month seven onward.

The feature lists overlap a great deal, and it is worth being exact about that rather than implying a gap that is not there. AITOC's covers website, store, store view and category scoping, control over orders, invoices and shipments, and per-attribute restriction naming price, weight and quantity. Read as bullet points, the two products look alike. Amasty and AITOC are also long-established vendors with support organisations and years of releases behind them, which a new listing cannot claim.

The difference is where the rule is applied, and it is the whole argument:

Enforcement is server-side. A hidden product attribute is stripped from the save request, not merely absent from the form. The store a request is addressed to is validated before the page runs – on categories, products, mass attribute updates, custom variables, configuration and admin order creation. A direct URL to an out-of-scope entity returns 404 rather than rendering. Out-of-scope rows never enter a grid, a mass action, a report or the dashboard's bestsellers tab, including when no store filter is set at all. A field that is hidden in the form and accepted when posted is a user-interface convention; anyone who can open the browser's developer tools can post it. That is the distinction the title of this article is about.

The default is closed. New roles are restricted until granted. Every permission system's real-world failure is the one nobody configured.

Scope is readable by other code. A read API lets other modules honour the same scope instead of re-implementing it, and a health-check command reports each role's scope status from the command line – so the configuration can be audited without clicking through nine roles.

Removing a role removes its rules. Scope rows cascade away with the role, so a deleted role leaves nothing behind to be inherited by a re-used name.

What it does not try to be

It is not an audit log – it controls what a role may reach, and records nothing about what they did. It is not a storefront feature and renders no storefront markup. It is not a login or SSO product. It runs entirely on your own infrastructure, calls no external service and sends nothing off-site. The rest of the absences are in the FAQ on the extension's page.