Advanced Roster For Filament Laravel Package

Technical Evaluation

Verdict: Adopt for a time-boxed pilot, not yet for a business-critical scheduling surface. v0.3.0 is a meaningful capability release (extensible filtering + persisted views), but the package is pre-1.0, single-vendor, and the new RosterFilter contract is a public API that will churn before 1.0.

Architecture fit. This is a Filament panel plugin (Laravel + Livewire/TALL stack), so it fits only if the roster UI lives inside a Filament admin panel. It is not a headless scheduling service — there is no evidence of an API, queue integration, or domain event surface. Treat it as a presentation-layer component over roster data we own. The new RosterFilter contract plus a filter registry is the right shape: it gives us an extension seam (custom role/location filters) without forking the package, which materially improves the build-vs-buy calculus versus hand-rolling toolbar, modal, badge, and per-user persistence ourselves.

Integration feasibility. Low-to-moderate effort. Install is a single composer require occtherapist/advanced-roster-for-filament:^0.3, plus panel provider registration, config publish, and — critically — whatever migration backs "per-user persistence" of filter state. That persistence is the main integration unknown: it implies a new table or user-preference column, and we need to know whether it is tenant-scoped and how it behaves when a persisted filter references a deleted role, location, or assignee. The custom filter example in the README de-risks our primary extension case.

Technical risk.

• Pre-1.0 churn: ^0.3 in Composer pins to >=0.3.0 <0.4.0, so patches are safe but any 0.4 bump may break the RosterFilter contract we will have implemented against. Budget for rework at each minor.
• Bus factor: single maintainer (occtherapist), no visible commercial backing or release cadence guarantees.
• Default-on flag: features.filters ships enabled, so the toolbar/modal/badge appear without opt-in — fine greenfield, but it means UI review must happen before merge, not after.
• Query risk: a filter registry that composes arbitrary constraints onto a roster query is a classic N+1 / unindexed-scan source at scale; unproven here.
• Authorization surface: an assignee filter with a modal picker can expose user lists; must confirm it respects panel policies and multi-tenancy.

Key questions.

1. Which Filament major/minor and Laravel/PHP versions are supported — is this Filament 3 only, or 4-ready?
2. Does per-user filter persistence require a published migration, and is it tenant-aware?
3. How are multiple active filters composed (AND semantics, or configurable)? Is filter state reflected in the URL / shareable?
4. Does the assignee picker respect existing authorization and tenant scoping?
5. What is the package's test coverage and CI matrix, and is there a documented deprecation policy for the RosterFilter contract?
6. Are there query-performance guardrails (indexes, eager loading) for rosters in the thousands of rows?

Integration Approach

Stack fit. Confirm the target panel is Filament-based before committing; if roster UI is Inertia/Vue or a public-facing calendar, this package is not a fit and the assessment ends here. Assuming a Filament panel: the plugin is additive — it does not own our roster schema, so our models, policies, and seed data remain authoritative.

Migration path. No prior assessment exists, so treat this as greenfield onboarding rather than an upgrade. Pin ^0.3, publish config and migrations into version control (never rely on vendor-published state), and record the resolved package version in the lockfile as the baseline. Do not adopt the flag-on default silently — explicitly set features.filters in our config so the behavior is intentional and auditable.

Compatibility. Verify Filament minor version against the package's constraint before install; Filament minors have historically broken plugin assumptions around panel registration and asset publishing. Check that our existing roster resource (if any) does not already implement its own table filters that would now double up with the registry.

Sequencing.

1. Spike in a throwaway branch against a seeded staging dataset; time-box to ~1–2 days.
2. Publish and review config + migrations; confirm persistence table shape and tenancy.
3. Implement one custom RosterFilter (location) as a proof of the extension contract — this is the real test of the release, not the built-in assignee filter.
4. Validate filter composition, reset, and badge-count behavior against pagination and large result sets.
5. Roll out behind the flag to an internal cohort, then enable panel-wide.
6. Re-assess at 1.0 or at the first 0.4 minor, whichever comes first.

Operational Impact

Maintenance. Ongoing cost is modest but non-zero: track releases for contract breaks, own our custom filter classes in our own namespace so a vendor change is a contained fix, and keep the published config/migrations diffed against vendor defaults on each bump. Absent a 1.0, assume we may need to vendor-fork a single file rather than wait on upstream.

Support. No evidence of commercial support; expect GitHub issues with maintainer-dependent latency. Mitigate with an internal runbook covering: how to disable features.filters as a kill switch, how to clear persisted filter state for a user, and who owns escalation.

Scaling. Two growth vectors. First, the per-user persistence store grows with user count and filter variety — plan for pruning of stale rows. Second, filter query cost grows with roster size; confirm indexes exist on the columns our custom filters target (role, location, assignee) and load-test at realistic row counts rather than demo data.

Failure modes.

• Flag default-on surprises users with a changed toolbar on deploy — mitigated by explicit config.
• Persisted filters referencing deleted roles/locations/assignees causing errors or silently empty rosters — needs a defined fallback behavior.
• Contract break on a 0.4 bump breaking our custom filters at runtime — caught only if we have a smoke test on the roster page.
• Filter modal or registry exception taking down the whole roster view (no graceful degradation) — verify the roster still renders if a filter class throws.
• Cross-tenant leakage via the assignee picker — highest-severity failure mode; test explicitly.

Ramp-up. Low for developers already fluent in Filament/Livewire — the README's custom role/location example is the main onboarding artifact and covers the 80% case. Budget roughly half a day for a Filament-fluent engineer to ship a first custom filter, plus review time for anyone touching query composition. Non-Filament engineers will need context on panel providers and Livewire component lifecycle before they can debug filter behavior.