Filament Saved Filter Laravel Package

Technical Evaluation

Architecture fit

• This release moves the package from "saved views on resource list pages" to "saved views on any table surface": ManageRelatedRecords pages (tabs included) and custom pages using InteractsWithTable now participate. Outside list pages, views are keyed by page class, which correctly prevents cross-contamination with the resource list's views — but also means page class identity becomes part of the persistence key (see risks).
• Custom pages must call configureSavedFilters() inside their own table(). That is a per-page opt-in, consistent with the fluent builder-level configuration already established, but it is a silent-failure API: forget the call and the feature simply doesn't appear.
• Shares the same hard coupling pattern as before, now at laravel-saved-filter ^1.10 (previously ^1.1). The pair remains a single deployable unit; the dependency floor has moved substantially.
• New deep-link contract: the active view is serialised into the URL as ?view=<id>. This turns "which view is active" from client state into a routable, shareable, and therefore enumerable and authorization-relevant identifier.
• Email reports become a first-class subsystem: per-tenant "My email reports" slide-over, per-report timezone, schedule summary in the view picker, and view/report IDs carried in the report context. This is meaningfully more than UX polish — it is a scheduling and notification surface with its own data model.
• Optional soft dependency on laravel-report-url for reports too large to attach (temporary download links).

Integration feasibility

• Feasible for existing adopters, but the upgrade is no longer "bump and migrate". The notes explicitly require publish and migrate again, which means new migration files land in the host app. That must be inspected, not assumed.
• Blocking prerequisites in order: dependency ^1.10, republished migrations, php artisan migrate, then the package. Any custom page work is additional developer effort.
• Shortcut features from the prior release are unchanged and remain opt-in; the new features are separately opt-in per page, which supports staged rollout.
• Evidence is still release-notes-only. No changelog diff, migration source, or test artefacts supplied. The two highest-risk items (migration file identity, ?view= authorization) cannot be resolved from the notes.

Technical risk

• Migration republish clobbering (high): vendor:publish --tag="saved-filter-migrations" writes into database/migrations. If it overwrites a previously published file that is already recorded in the migrations table, the new timezone/context columns will never be applied — migrate sees the filename as already run. Confirm the dependency ships a new, later-timestamped migration rather than editing the existing one, and diff the published directory before running anything.
• ?view=<id> is an IDOR surface (high): integer IDs in URLs invite enumeration. Applying a view by ID must re-check owner/tenant/shared scope server-side on every request, not just at render time. A missing check leaks another user's filter state, grouping, and — per the previous assessment — potentially a colleague's name.
• Link precedence ambiguity (medium): the notes state "filters from the same link still win" over the view. That is a sensible rule but an untested one; combined links (?view=4&filters[...]) produce non-obvious effective state that support will have to explain.
• Dangling view links (medium): deleting a view, or a recipient lacking access, leaves ?view=4 in circulation. Decide and document whether that degrades silently to the default view or errors.
• Page-class keying (medium): renaming, moving, or splitting a custom page class orphans its saved views with no migration path described. Class refactors in the admin surface now carry data consequences.
• Cross-tenant aggregation in "My email reports" (medium/high): a slide-over listing the user's reports "on every table of the tenant" implies a broad query across report rows and table classes. Verify tenant scoping and that it does not become an N+1 or a slow query on large tenants.
• Timezone correctness (medium): per-report timezone introduces DST edge cases, invalid/legacy timezone strings, the fallback chain (user timezone → app default), and ambiguity about whether the scheduler or the queue worker evaluates the schedule. Duplicate or missed sends around DST transitions are the classic failure.
• Email context now carries view and report IDs (medium): every schedule links to its view, so emailed links must resolve safely for a possibly-unauthenticated or wrong-tenant click, and must not become a second enumeration vector.
• Import conflict semantics (low/medium): overwrite / skip / "Name (2)" needs defined behaviour on repeated imports (does it reach (3)? does it collide with an existing literal "Name (2)"?).
• Optional laravel-report-url (low/medium): absent → large reports presumably fall back to attachment and may bounce on mail size limits; present → temporary signed links with expiry and temp-file cleanup obligations.
• Version drift (medium): now laravel-saved-filter <1.10 yields hard failure or silent feature absence; the acceptable window is narrower than before.
• Release identity (housekeeping): release metadata reports tag 3.1.0 while the notes describe 1.6.0. Confirm which artifact is being evaluated before pinning.

Key questions

1. Which tagged artifact is this — metadata says 3.1.0, notes say 1.6.0? Confirm the exact version to pin.
2. Does the ^1.10 upgrade ship a new timezone/context migration, or does it edit previously published migration files? Provide the generated SQL and confirm migrate:rollback behaviour.
3. How is ?view=<id> authorized on read? Owner-only, shared-scope, or tenant-wide? Is an inaccessible/deleted view a 403, a redirect, or a silent default?
4. What is the precedence order when a link contains both view and filters, and is it documented user-facing?
5. Does the "My email reports" slide-over scope by tenant, by user, or both — and what is its query cost on a tenant with many tables?
6. Where is the report schedule evaluated — app timezone, queue worker timezone, or per-report timezone — and how are DST transitions handled?
7. Are emailed "Open the view" links signed/expiring, and what happens on click by an unauthenticated or wrong-tenant user?
8. What happens to saved views when a custom page class is renamed or moved?
9. Is laravel-report-url required or optional, and what is the fallback and cleanup policy for temporary links?
10. Any breaking changes? Semver says no, but the dependency floor and the republish requirement change the install contract materially.

Integration Approach

Stack fit

• Broader fit than before: any Filament-style table surface (resource lists, relation managers, custom InteractsWithTable pages) is now in scope. This raises the value case for teams with heavy relation-manager usage.
• Custom pages require a deliberate code change (configureSavedFilters() in table()), so budget per-page effort rather than treating this as a free upgrade.
• Email reports make the package relevant to notification/scheduling owners, not just the admin UI team — a new stakeholder.

Migration path

1. Upgrade laravel-saved-filter to ^1.10 on a branch. Before publishing, snapshot database/migrations (filenames + checksums).
2. Run vendor:publish --tag="saved-filter-migrations"; diff the directory. Confirm the change is a new file, not a rewrite of an existing one. Abort and escalate if any previously-run file changed.
3. Run php artisan migrate against a production-shaped staging copy; inspect SQL; verify the timezone and report-context columns exist and are nullable/defaulted.
4. Verify migrate:rollback for the new migration only.
5. Upgrade the package. Re-render an existing list page and confirm saved views, per_page, and grouping behave unchanged.
6. Add configureSavedFilters() to one custom page / relation manager in staging and confirm keys do not collide with the resource list's views.
7. Enable shareable links behind an authorization test (owner / shared / other-tenant) before enabling in production.
8. Enable email reports last, starting with a single internal tenant and a short interval, using the timezone field explicitly.

Compatibility

• keyBindings() remains the escape hatch for the shortcut layer; unchanged from the prior release.
• Pin both packages and note the optional laravel-report-url in the lockfile / internal compatibility matrix. Update the matrix entry: package version ↔ laravel-saved-filter version ↔ optional report-url presence.
• Treat the published migration set as part of the compatibility contract — record which migration filenames the running system expects.

Sequencing

• Four separate, observable deploys: (1) dependency ^1.10 + new migration, (2) package upgrade with existing behaviour verified, (3) custom-page and relation-manager opt-ins, (4) shareable links + email reports + timezone.
• Do not combine the migration with the reports rollout: a timezone or deliverability problem would otherwise force a rollback of a schema change.
• Shareable links ship after the authorization test exists, not alongside it.

Operational Impact

Maintenance

• Two-package coupling plus one optional package; extend Renovate/Dependabot coverage and add the optional dependency to the upgrade runbook.
• Runbook gains a non-obvious step: "publish migrations, diff before migrating, confirm new files only." Write it down — the failure is silent.
• Track page-class renames as data-affecting changes; add a checklist item to any refactor that moves a custom table page.

Support

• New ticket classes:
  • "My report arrived at the wrong time" → timezone default chain and DST; support needs a one-line explanation and where to change it.
  • "The link opens the wrong/blank view" → ?view= precedence and access rules, plus deleted-view behaviour.
  • "I can't find my reports" → the per-tenant slide-over location.
  • "Import made a duplicate named (2)" → conflict-choice documentation.
  • "The email attachment is missing / link expired" → optional laravel-report-url presence and link TTL.
• Publish a short reference covering: view links, report management location, timezone behaviour, import options, and how to disable shortcuts. Discoverability without documentation is a support cost.

Scaling

• Storage growth now comes from three places: views (small), import duplicates (user-driven, can inflate count via "Name (2)" chains), and report rows with context columns (small per row).
• The "My email reports" slide-over is the first feature here with a plausibly expensive query on large tenants. Load-test it against a tenant with many tables and many users before general enablement.
• Email volume becomes an operational cost: if reports now run per user, per view, per tenant, notification traffic scales with adoption, not with table count.
• If laravel-report-url is used, temporary download artifacts need a retention/cleanup policy and storage budget.

Failure modes

• Migration file overwritten on republish → new columns never applied → runtime errors reading timezone/report context. Mitigate with the diff-before-migrate gate.
• Migration not applied at all → same class of runtime failure. Mitigate with a deploy gate or startup health check that asserts expected columns exist.
• ?view= without server-side authorization → cross-user / cross-tenant view disclosure. Requires a boundary test before enablement.
• Deleted or inaccessible view in a circulated link → silently wrong table state, or a hard error; decide which and document it.
• Timezone misconfiguration or DST transition → duplicate or missed report emails. Mitigate by evaluating schedules in a single, documented timezone and testing across a DST boundary.
• Custom page missing configureSavedFilters() → feature silently absent, reported as a bug.
• Page class renamed → orphaned views, no apparent cause.
• laravel-report-url absent + oversized report → bounced or dropped email.
• Dangling/expired download links → user-facing dead end.
• Everything from the prior assessment still applies: browser Ctrl/Cmd+Shift+S collision, Alt+1…9 tab-switch conflicts, incomplete typing guard, accessibility regression from global handlers. Keep menu-driven parity so shortcuts are never the only path.

Ramp-up

• Developer effort: moderate now, up from low — dependency bump, migration verification, per-custom-page opt-in, plus link-authorization work. Still contained, but no longer an afternoon.
• Operational effort: new — someone must own email report scheduling, timezone defaults, deliverability, and the optional download-link dependency.
• End-user effort: moderate and rising — more surfaces (relation managers, custom pages), shareable links, and a self-service reports panel. Recommend a pilot tenant covering one list page, one relation manager, and one email report before general rollout.
• Overall recommendation: adopt, in the staged sequence above. The per-page coverage, shareable links, and self-service report management are clear user value. Gate the rollout on three verifications that cannot be inferred from the release notes — migration file identity, ?view= authorization, and timezone/DST behaviour — and hold shareable links until the authorization test passes. Keep the keyboard shortcut layer behind the a11y and browser-collision review from the prior assessment.