Ecommerce Laravel Laravel Package

Product Decisions This Supports

Build vs. buy for a commerce back office. This package supplies the parts that are expensive to write and boring to specify: registration, login/redirect intent, Filament admin (admin) and merchant (app) panels, team-scoped tenant access, and storefront-adjacent account surfaces (/orders, /wishlist, /invoices, /payment_methods). It is a credible starting point for an internal storefront or a merchant-facing SaaS — not a finished product.

Authorization model as a product decision, not an implementation detail. v1.0.3 establishes the line the product now draws: registration produces a shopper (a user with no team and no role), and team membership is what grants the /app panel. That is a real product rule — merchants onboard through TeamPolicy::create, gated on the create_store permission, rather than being handed a team at signup. Anyone deciding "how does a merchant become a merchant?" has to decide it here, because signup no longer does it for you.

Roadmap sequencing: security debt gates launch, not feature work. The known-issues list is short but sharp: ArticleResource/CollectionResource have no policies with strictAuthorization off (a team member can CRUD — including price — without a permission check); SVG upload is a latent stored XSS the moment storage:link runs; /user/profile breaks with social login enabled; Password::default() is 8 chars with no complexity or breach check. Each of these is a "must fix before a stranger can reach it" item, and two of them are unreachable only by accident of current config. Plan the hardening sprint before any public exposure, and treat storage:link and social-login enablement as gated changes with an owner.

Release/upgrade policy. The versioning note is itself a decision input: v13.0.0 still resolves highest on Packagist, so composer create-project and unpinned composer require fetch the old code — the one that fatally errored on registration for every real user. Any adoption decision must include a pin (1.0.3 or ^1.0), and a team convention that this package is never installed unpinned.

Deprioritization candidates. RoleBasedRedirect is dead code from a property-management app (six targets, all 404). config('permission.teams') is false, so roles are global even though code reads as team-scoped — that mismatch will mislead every engineer who touches permissions, and it should be resolved (or documented) before roles multiply.

Test-quality confidence. The bug survived because FortifyActionsTest::makeTeam() manufactured the team and the staff role that production never created — green CI, broken registration. That is evidence about the suite, not just the bug: when evaluating "1245 tests pass," ask what state the fixtures construct versus what the app constructs.

When to Consider This Package

Consider it when:

• You need a Laravel + Filament commerce back office and storefront shell and want to skip 4–8 weeks of registration, panel, and tenancy plumbing.
• Your tenancy model matches theirs: teams gate the merchant panel, roles are global today, and merchants are granted a store through an explicit policy check.
• You can pin the version (1.0.3 or ^1.0) and can own the security backlog above — you have someone who will write the missing article_*/collection_* policies and seed the matching Shield permissions, as a pair, because the permission set doesn't contain them.
• You are pre-launch or internal-only, where a gated storage:link and a disabled social login are acceptable interim states.
• You want a shopper-facing storefront with a separate admin plane and are comfortable that "shopper" means user-without-team, redirected to the storefront with intended() restoring mid-checkout interruptions.

Look elsewhere when:

• You cannot pin dependencies, or your platform team installs via composer create-project as a matter of course — you will silently get v13.0.0 and the registration failure.
• You need per-tenant roles now. Roles are global; the code only looks team-scoped.
• You need a hardened auth baseline out of the box (breach checking, complexity, MFA) — you'll be writing it.
• You need a demo/marketing instance that doesn't ship sold out (inventory_count = 0 on every seeded product).
• You require a clean, audit-ready policy surface: missing policies plus strictAuthorization off is a posture, not a bug, and reversing it is your work.

How to Pitch It (Stakeholders)

For executives: This is a Laravel ecommerce foundation — storefront plus two admin panels — that we can build on instead of starting from zero. The latest release fixes a serious flaw where every person who signed up was silently attached to the merchant's own team and given staff access, and where anyone with no team and no role could still reach the merchant back office. That is fixed, and signup now correctly creates a plain shopper; merchants get a store deliberately, through a permission check, not by accident. Two caveats for planning: we must pin the version, because the default install still pulls an older release containing the bug; and there is a short list of known security items — two content types without permission checks, an image-upload path that becomes risky once we enable public file storage, and a weak default password rule — that we should close before we expose this publicly or onboard a real merchant. None of these block internal evaluation; all of them block launch.

For engineering: Registration and panel authorization were one bug and are now decoupled: signup yields a user with no team and no role, /app access is gated on team membership, and teams come from TeamPolicy::create behind create_store. canAccessPanel is now per-panel (admin → super_admin, app → team membership) and reads $this rather than auth()->user() — the old check authorized the session user instead of the one passed in, which matters in any queued or impersonated context. 1245 tests pass with 7 added; note the removed FortifyActionsTest::makeTeam() helper, which fabricated the team and the staff role and is precisely why CI stayed green while real registrations threw. Outstanding: add policies for ArticleResource and CollectionResource together with seeded article_*/collection_* permissions (the Shield set has none), turn strictAuthorization on, resolve the global-vs-team-scoped roles mismatch (permission.teams is false), strip image/svg+xml from product uploads or serve from a non-public disk, restore HasConnectedAccounts on User before enabling social login, and delete RoleBasedRedirect. Pin to 1.0.3; the v1 tag points here but Packagist still resolves v13.0.0 as highest.