Filament Gatekeeper Laravel Package

Product Decisions This Supports

• Authorization architecture for Filament admin panels: Gatekeeper targets the recurring question of whether to hand-roll per-resource permission matrices (roles × resources × actions) or adopt a plugin. The v1.1.5 auto-discovery work lowers the cost of the "adopt" path by removing manual field/column enumeration from the setup.
• Build vs. buy for RBAC/ACL: If your roadmap includes granular, per-field visibility or edit restrictions in Filament (e.g., support agents see status but not billing fields), this package is a candidate to evaluate against a hand-built Policy + Gate layer. Deduplicated discovery in v1.1.5 suggests the maintainer is hardening the automatic permission-generation path rather than adding scope — a signal the core model is stabilizing.
• Feature scoping: Auto-discovery of fields and columns implies permissions can be derived from existing Filament resource definitions. That makes "field-level permissions" a configuration task rather than a bespoke engineering project, which changes the estimate for any roadmap item that previously assumed custom middleware and Blade-level gating.
• Onboarding and maintenance cost: The README rewrite with full auto-discovery documentation reduces the internal documentation burden of adopting a third-party authorization layer — relevant when deciding whether the team can own this without a dedicated maintainer.
• Upgrade risk assessment: v1.1.5 is a patch release containing a feature (discovery deduplication) and a CI-only fix. No breaking changes, no deprecations. Safe to adopt on the current minor line; no migration planning required.

When to Consider This Package

Consider it when:

• You run Filament in production and need role/permission management that maps onto Filament resources, pages, and widgets rather than a generic Laravel ACL.
• You want field- and column-level permission granularity without writing discovery logic yourself — the v1.1.5 deduplication directly improves correctness when resources expose the same field through multiple paths (e.g., shared form schemas, relation managers, table columns overlapping form fields).
• Your team is small or mid-sized and would otherwise maintain a bespoke permission UI in the admin panel.
• You are comfortable depending on a single-maintainer, community package for an authorization surface, and can pin versions and review diffs on upgrade.

Look elsewhere when:

• You need audited, compliance-grade access control (SOC 2, HIPAA) where a vendor-supported or first-party solution is required. A community Filament plugin is unlikely to satisfy procurement here.
• Your authorization model is not Filament-shaped — heavy API-first or multi-tenant custom-domain rules are better served by a dedicated package (e.g., spatie/laravel-permission) with your own Filament UI.
• The package's discovery heuristics do not cover your resource patterns (heavy custom Livewire components, dynamically built schemas). Auto-discovery is convenient precisely until it silently misses a surface; verify coverage before relying on it for sensitive fields.
• You require semantic-versioning guarantees around feature additions in patch releases. v1.1.5 shipping a feature under a patch number is common in small projects but worth noting for dependency policy.

How to Pitch It (Stakeholders)

For executives: This is a small, actively maintained add-on for our admin panel that lets us control who can see and edit individual fields, not just whole screens. The practical effect is that we can ship role-specific admin experiences — support staff see tickets but not billing data, for example — as configuration instead of custom development. The latest release (v1.1.5) improves automatic detection of fields so setup is less error-prone and better documented. Cost is low, risk is contained (it is additive, patch-level, and reversible), and it removes a recurring reason we defer permission-related requests.

For engineering: v1.1.5 deduplicates field/column discovery and rewrites the README with full auto-discovery documentation; the only other change is a CI fix. There are no breaking changes or deprecations, so this is a low-risk bump. The important detail is the deduplication: resources that expose the same column through both a table and a shared form schema previously produced redundant permission entries — expect cleaner permission sets and simpler seeders after upgrading. Validate discovery output against your most dynamic resources (relation managers, custom Livewire fields) before depending on it for sensitive data. Recommendation: adopt behind a feature flag in a non-critical panel first, pin the version, and review the generated permission matrix as part of the PR.

Caveat on confidence: this assessment is based solely on the v1.1.5 release notes; the package's underlying API, test coverage, and maintainer activity were not independently reviewed and should be checked before a production commitment.