Laravel Shopify Sdk Laravel Package

Product Decisions This Supports

• Role-based access for merchant teams — now a buy, not a build. v2.1.0 gates all fifteen Filament resources plus the Analytics dashboard behind per-action Shopify permission prefixes (draft_orders.*, fulfillments.*, discounts.*, metafields.*, analytics.view). If your roadmap includes admin/staff/analyst/packer personas with different views of orders, fulfillments, discounts, or metafields, this release delivers the authorization layer as a feature rather than a custom project.
• Deletes a known workaround from your backlog. Consumer apps that already run their own RBAC previously had to apply a deny-all policy on DraftOrder, Fulfillment, Discount, and Metafield, plus disable and re-register the Analytics page, just to hide them from non-admins. That maintenance burden and its regression risk can be removed. This is a concrete "build vs buy" win: fewer bespoke policies to own, test, and re-audit on every Filament upgrade.
• Unblocks enterprise/security review of the admin surface. The most common blocker in merchant-facing SaaS procurement is "can a staff account see more than it should?" A single, tested source of truth for visibility is a checkbox you can now tick in a security questionnaire instead of explaining a patchwork of policies.
• Enables permission-scoped tiers and upsells. Because gating is per-resource and per-action, plan boundaries can be expressed directly in permissions (e.g. read-only plan denies *.create/*.edit/*.delete; a "fulfillment ops" seat gets fulfillments.* but not metafields.*), rather than through page hiding or separate builds.
• Roadmap sequencing insight: adopt the permission contract deliberately. The backward-compatible fallback is important — a User model without hasShopifyPermission() gets full access. That makes this a zero-risk upgrade technically, but it also means "we upgraded" does not equal "we are gated." A PM should schedule the actual adoption step (implementing the contract, defining prefixes per role) as its own roadmap item with acceptance criteria.
• Quality signal for dependency confidence. Full gating is verified against real Filament classes (filament/filament as require-dev), with 106 passing tests / 226 assertions covering the no-user, no-grant, granted, and legacy-user cases plus a Filament-free unit matrix for cross-prefix leakage. That is the kind of coverage that justifies keeping the package in the critical path of your admin panel.

When to Consider This Package

Consider adoption when:

• You are building a Filament-based Laravel admin or merchant portal on top of Shopify, and more than one human persona uses it.
• You need differentiated visibility across orders, draft orders, fulfillments, discounts, metafields, or analytics — even in the simple case of hiding analytics and financial data from non-admins.
• You have (or expect) an external RBAC system and want the package's screens to respect it instead of fighting it with deny-all policies and page re-registration.
• You want authorization to be opt-in and reversible: no breaking change, existing apps see identical behavior, and the gating only activates once your User model implements hasShopifyPermission().
• You value upgrade safety — a fully backward-compatible release with regression tests on already-gated resources is cheap to adopt and cheap to defend in a change review.

Look elsewhere, or plan supplemental work, when:

• You run single-operator or internal-only tooling where every authenticated user is trusted; the permission contract adds setup with no user-visible benefit.
• You are not on Filament, or you have replaced its resources/pages with custom screens — the gating lives in the resources and the Analytics page, not in your own controllers.
• You need field-level or row-level scoping (e.g. an analyst sees only unfulfilled draft orders for one location). This release gates resource and action access; it is not an attribute- or record-level policy engine, so pair it with your own scopes.
• You need permissions beyond CRUD — approvals, exports, bulk actions, or custom page-level capabilities are not expressed in the shipped prefixes and will need your own checks.
• Your access model must be enforced on the API/queue side, not just the admin UI. Treat this as a UI gating layer and keep server-side authorization authoritative.
• Your org requires permission definitions to be centrally owned and audited — here they are string prefixes in the package, so confirm that naming convention and lifecycle (who adds metafields.* when a resource is added) is captured in your own governance.

Adoption checklist for the PM: confirm which User models implement hasShopifyPermission(); enumerate the intended role → prefix matrix and get it reviewed by security; delete the four now-redundant deny-all policies and the Analytics page workaround in the same change; add a test asserting a low-privilege user cannot reach each of the fifteen resources and the Analytics page.

How to Pitch It (Stakeholders)

For executives: This release removes the last gaps in who can see what inside the Shopify admin we ship. Before v2.1.0, four screens and the entire Analytics dashboard were visible to every logged-in user, which forced us to write and maintain custom restrictions. Now a merchant's roles can drive visibility across the whole admin from one tested mechanism. It is fully backward compatible — no migration, no downtime, no change for existing customers — and the package's test suite (106 tests) covers the access rules, which lowers our audit and security-review exposure. Net effect: less custom code to own, faster answers to customer security questions, and a clean foundation for permission-based plan tiers. The one action we owe is deciding and implementing our role matrix, so the gating is actually switched on for our users rather than running in legacy full-access mode.

For engineering: v2.1.0 closes the permission gap on DraftOrderResource, FulfillmentResource, DiscountResource, MetafieldResource (via HasShopifyPermissions with draft_orders.*, fulfillments.*, discounts.*, metafields.*) and the Analytics page (analytics.view through a canAccess() reusing the same logic). Everything routes through the existing checkPermission() path, so behavior is unchanged for apps that never adopted the contract — specifically, a User model without hasShopifyPermission() retains full access, and unauthenticated requests are denied. That gives us a genuinely safe upgrade: merge the dependency bump, then land our own change implementing hasShopifyPermission() on the user model and define the prefix-to-role mapping. In that same PR we should delete the deny-all policies on those four models and the Analytics page disable/re-register hack, since they become redundant and will otherwise mask real failures. Test coverage is solid and worth keeping: FilamentResourceGatingTest exercises the no-user, no-grant, granted, and legacy cases across all gated resources plus the page, and ShopifyPermissionsTest is a Filament-free matrix for per-action prefixing and cross-prefix leakage — extend that matrix whenever we add a resource or a custom capability. Note filament/filament is now require-dev, so CI must have it available.