Filament Inverse Shield Laravel Package

Product Decisions This Supports

• Build vs. buy for role-based access control (RBAC) in Filament admin panels. Inverse-shield flips the usual permission model: instead of hand-assigning permissions to roles in an admin UI, you declare what each role can reach and let the package derive permissions from your Filament resources, pages, and widgets. This is a meaningful build-vs-buy line item — it can retire custom authorization glue and ad-hoc policy code in internal tools.
• Feature scoping for admin/back-office work. When a roadmap item reads "add roles and permissions," this package determines whether that's a half-day config exercise or a multi-sprint build.
• Roadmap risk around seeding and environment parity. v1.4.8 fixes seed behavior so the admin role keeps all its attributes when roles are seeded (previously attributes could be dropped). This is a data-integrity fix that affects how confidently we can treat role seeding as a repeatable, idempotent deployment step — relevant to any staging/production rollout plan.
• Upgrade policy decisions. A patch-level bugfix with no advertised breaking changes means we can schedule it in a routine maintenance window rather than a dedicated migration effort.
• Use cases it fits: internal admin panels, SaaS back-offices, multi-tenant tooling where roles map cleanly to resource access, teams already standardized on Filament.
• Use cases it doesn't fit: products needing per-record or per-field permission granularity, end-user-managed role editors, or non-Filament surfaces.

When to Consider This Package

Adopt when all of these hold:

• The product's admin surface is built on Filament and will stay there.
• Roles are a small, code-reviewed set (admin, editor, viewer, support) rather than something customers define at runtime.
• The team prefers permissions expressed in source control over a database-driven UI — i.e., RBAC changes should go through code review and deploy, not a settings screen.
• You want role seeding to be a reliable part of deploys; v1.4.8's attribute-preservation fix makes seeded roles a safer source of truth, though it's worth a regression test on your own role attributes before relying on it.

Look elsewhere when:

• You need a rich UI for non-technical admins to author roles and permissions (Filament Shield or a dedicated permissions UI is the better fit).
• You need policy-level, per-model, or per-field authorization beyond resource access.
• The admin panel isn't Filament, or you're hedging on a frontend/framework migration.
• Your roles carry many custom attributes and business logic — the seeding path is the part most likely to surprise you, and this release is evidence it's still being hardened.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose package that lets us define who can see and do what in our admin panels by writing it down in code, rather than building and maintaining a permissions system ourselves. It removes custom authorization work from the roadmap and makes access changes reviewable and auditable like any other code change.

To engineering: Inverse-shield derives permissions from Filament resources, pages, and widgets, so role definitions live in config alongside the code they govern. v1.4.8 is a low-risk patch — it preserves all attributes on the admin role during seeding, closing a gap where seeded roles could lose configuration. No breaking changes, no API surface changes. Action: bump the dependency in a routine maintenance pass and add a test asserting admin role attributes survive re-seeding. Caveat: this package suits a fixed, developer-owned set of roles; if we later need customers to define their own roles or need per-record permissions, that's a re-evaluation point, not an incremental extension.