Authorization

The admin calls the engine's services in-process, so it does not pass through the REST layer's ecommerce.can middleware. It enforces the engine's abilities itself:

• Entering the admin. Every admin route runs the ecommerce-admin.access middleware, which lets a user in only when at least one navigation entry is visible to them. The middleware is also registered as Livewire persistent middleware, so update requests from an admin page are re-checked.
• Each screen. A screen's Livewire component authorizes its ability in mount(), and again on every update request.
• Each action. Every action authorizes again before it runs, because a Livewire action can be called directly with a forged request.

A denial always ends in a 403. The default is deny: a screen answers 403 unless a Gate ability, an assigned cms-framework permission, or an ability filter grants access.

How an ability is decided

Abilities are {resource}.{action}. The engine's policies delegate to EcommerceAuthorizer, which checks, in order:

1. the Gate ability ecommerce.{resource}.{action}, when the host defines it;
2. otherwise the umbrella ecommerce.admin gate, when the host defines it;
3. then the ap.ecommerce.abilities.{resource}.{action} filter.

The simplest setup is the umbrella gate:

Gate::define( 'ecommerce.admin', fn ( $user ) => $user->is_admin );

For finer control, define individual abilities. A Gate ability receives the record when there is one, so it can check ownership:

Gate::define( 'ecommerce.order.viewAny', fn ( $user ) => $user->hasRole( 'fulfillment' ) );
Gate::define( 'ecommerce.order.view', fn ( $user, $order = null ) => $user->hasRole( 'fulfillment' ) );
Gate::define( 'ecommerce.order.update', fn ( $user, $order = null ) => $user->hasRole( 'fulfillment' ) );

A product whose type comes from a satellite that is not installed always renders read-only, with the engine's warning banner (<x-artisanpack-ec-product-type-warning :product="$product" />). This applies even to a full admin.

With cms-framework

When artisanpack-ui/cms-framework is installed, the engine:

• registers one RBAC permission per ability, with the slug ecommerce.{resource}.{action};
• creates a shop-manager role that holds all of them.

The admin uses the engine's ability catalog, so the permissions always match the engine's abilities. They are registered:

• by the engine's php artisan ecommerce:sync-permissions;
• by php artisan ecommerce-admin:install, which runs it;
• after every php artisan migrate.

php artisan ecommerce-admin:sync-permissions still works, but is deprecated: it prints a notice and runs ecommerce:sync-permissions.

A user holding a permission is granted the matching ability through the engine's ability filter. The filter only ever adds access, so an ecommerce.admin gate keeps working alongside RBAC. When you define the ecommerce.{resource}.{action} gate yourself, your gate's answer stands and the permission is not consulted for it.

Two-factor authentication

Neither the engine nor the admin applies 2FA. Add your 2FA middleware to admin.middleware. See Installation.

Every ability

These are the abilities registered as RBAC permissions (prefixed ecommerce.).

Inventory has its own abilities, separate from product.*, so staff can count and adjust stock without editing products. product.viewAny and product.update do not grant them.

The admin issues refunds under order.refund. refund.create and refund.view are used by the engine's REST API, not by the admin. Coupons have no view abilities of their own: they are shown inside their promotion, so the command palette's coupon results need promotion.viewAny and view on the coupon's promotion.

Abilities per screen

¹ A user with only licenseKey.revoke can open the screen, but sees each key masked to its last group and cannot search by key. Keys are shown in full only with licenseKey.view.

Screens appear in the navigation only for users who can open them.

Abilities per action

Viewing actions on every index screen (search, filter, sort, paginate, select rows, export the selection as CSV) need only the screen's ability, as do Cancel and Close buttons. The tables below list everything else. Method names are the Livewire actions, for reference when you test or extend.

A bulk action is shown only to users who hold its ability, and is checked again when it runs. Each selected record is also checked on its own: records the user may not change are skipped, and the result says how many were skipped.

Orders

License keys on the order are shown in full only with licenseKey.view.

Reviews

Products

Product import

Categories and tags

Inventory

Digital files and license keys

Customers

Promotions and coupons

Shipping and tax

Notifications and webhooks

Order statuses and kanban boards

Reports and settings

How this is tested

tests/Feature/Authorization/AuthorizationMatrixTest.php declares, for every registered Livewire component, the ability its mount() needs and the ability each public action needs. The suite proves each one both ways: a user who can enter the admin but lacks the ability is refused, and a user holding just that ability gets through. A component or action missing from the matrix fails the suite, so a new screen cannot ship without declaring its authorization.