Filament Saved Filter Laravel Package

Product Decisions This Supports

• Scheduled reports become a first-class product surface, not a side feature. This release adds per-report timezone (defaulting to the user's timezone attribute, then the app's), a "My email reports" slide-over that lists the user's reports across every table in the tenant, and a view picker that shows what is currently scheduled for the selected view. That combination turns "email me this view" from a hidden one-off into a manageable subscription — a decision point about whether reporting is a roadmap pillar or just an escape hatch for exports.
• Shareable view links as an acquisition/retention lever. The active view now lives in the URL as ?view=4 and opens correctly even when the Views UI is in dropdown mode (explicit filters in the same link still win). This is the cheapest possible collaboration primitive: a user can paste a link into a ticket, chat, or runbook and land a colleague on the exact filtered, grouped, paged view — no shared-view ACL, no permission redesign. Decide whether URL-addressable table state is a default expectation across your admin surfaces.
• Scope expansion beyond list pages. ManageRelatedRecords pages (tabs included) and custom pages using InteractsWithTable now get saved views, keyed by page class so they don't collide with the resource list's views; pages without tabs surface them in the Views menu (pages must call configureSavedFilters() in their own table()). This affects backlog sizing: "saved views" is no longer a per-resource feature but a cross-cutting platform capability, and the remaining gaps (e.g. email reports staying list-page-only) should be documented as known limits rather than discovered in QA.
• Multi-tenant administration. "My email reports" spans every table of the tenant, letting users enable, disable, or delete reports in one place. That supports a product decision about whether report hygiene is user self-service or an admin/ops responsibility — and it removes a support-ticket class ("I have no idea what I'm subscribed to").
• Import/export conflict handling. Importing views now offers overwrite (as before), skip, or "Name (2)". Choosing the default matters: overwrite is destructive and skip silently drops user intent, so "Name (2)" as the safe default is a defensible product stance for a user-authored artifact.
• Build vs. buy (revised upward in the package's favour). URL-addressable state, cross-page view keying, per-report timezone handling, tenant-wide subscription management, and conflict-aware import are each small individually and expensive collectively. In-house you would ship filters persistence and stop there; the long tail is what justifies adoption.
• Use cases it unlocks: operations dashboards with recurring triage routines, support queues with a shareable "my open tickets" link, finance screens that group by cost centre and persist it, scheduled digests sent in the recipient's local timezone, related-record tabs (e.g. a customer's orders) that remember their own filters, and admin panels where users have asked "why does it forget my settings?"
• Release sequencing. Views-in-URL and the reports slide-over are additive and low-risk; the import-conflict behaviour changes an existing flow and should be called out in the changelog. Treat that one as the item needing a deliberate default decision rather than a silent upgrade.

When to Consider This Package

Adopt when most of the following hold:

• You have (or are about to build) multiple data-heavy list screens, plus related-record and custom table pages, in a Laravel admin panel or Filament-style back office.
• Users repeatedly re-apply the same filters, sort, page size, or grouping — a clear signal from support tickets or session analytics.
• You want scheduled email digests of filtered views, especially across timezones or multiple teams; per-report timezone plus the tenant-wide reports slide-over cover the operational basics without a bespoke job/cron surface.
• Shareable, bookmarkable table state is valuable and you are content with link-based sharing rather than a permissioned shared-view model.
• Shared/team views are on your roadmap; the visibility labels (Preset vs. Shared vs. creator) mean you won't have to hand-roll attribution UI.
• Keyboard-driven power users are a meaningful segment, and you want shortcuts available without committing to them by default.
• You can accept the upgrade obligations: this release requires jeffersongoncalves/laravel-saved-filter ^1.10 (timezone column, view and report IDs in the report context so every schedule links to its view), and you must re-publish and re-run migrations (vendor:publish --tag="saved-filter-migrations" then migrate). Per-view page size and grouping from the prior release similarly depend on the newer dependency line. Treat the dependency bump plus migration as one coordinated release step, including read-replica and large-table considerations.
• If email attachments may exceed your mail limits, you are willing to install laravel-report-url to deliver oversized reports as temporary download links rather than shipping your own storage/signed-URL layer.

Look elsewhere or defer when:

• Your screens are few and simple, or filters are one-off rather than recurring — persistence is cost without payoff.
• You cannot take a schema migration and a dependency bump in the same release window; pinning back forfeits page-size, grouping, and the report/timezone linkage this release depends on.
• You need view-sharing semantics beyond visibility labelling and URL links — e.g. granular per-role ACLs, approval flows, or org-hierarchy inheritance of views. Confirm against the package's sharing model before committing.
• Email reports on non-list pages are a hard requirement: this release explicitly keeps email reports on list pages, so related-record tabs and custom pages get saved views but not scheduling.
• You are on a Laravel/PHP version outside the package's supported matrix, or your front end is not a Blade/Livewire-style stack where these UI affordances apply.
• Global keyboard bindings would collide with host-app shortcuts; the opt-in ->tabShortcuts() and configurable ->keyBindings() mitigate this, so only avoid if you need full key-map ownership.

How to Pitch It (Stakeholders)

To executives: Saved views now travel — the active view is encoded in the URL, so a user can paste a link and a colleague lands on the same filtered, grouped, paged table. The same views can be scheduled as email reports with a per-recipient timezone, and users get one place to see and manage every report they're subscribed to across the tenant. Saved views also extend past list screens to related-record tabs and custom table pages, closing the "why does it forget my settings?" gap across the admin panel. Scope is additive and the risky surface is small, but the upgrade does require a dependency bump and a database migration, so it needs a coordinated deploy rather than a routine merge.

To engineering: This release adds (1) saved views on ManageRelatedRecords pages and custom InteractsWithTable pages, keyed by page class so they don't collide with resource-list views — such pages must call configureSavedFilters() inside their own table(), and pages without tabs render views in the Views menu; email reports remain list-page-only. (2) Active view in the URL as ?view=4, which takes effect in dropdown mode too, while explicit filters in the same URL win; the report email's "Open the view" button uses it. (3) A tenant-wide "My email reports" slide-over to toggle or delete reports. (4) Per-report timezone — user's timezone attribute, else the app default — and the view picker now shows the current schedule for the selected view. (5) Import conflicts resolve to overwrite, skip, or "Name (2)". Upgrade requires jeffersongoncalves/laravel-saved-filter ^1.10 (timezone column, view and report IDs in the report context), so re-publish migrations with --tag="saved-filter-migrations" and re-run migrate in the same deploy as the dependency bump; audit any existing report rows for the new view/report linkage and backfill timezones where the user attribute is null. laravel-report-url is optional but needed if you want oversized reports delivered as temporary download links instead of attaching them. Prior guidance still holds: default save/manage shortcuts are overridable or disableable via ->keyBindings(), opt-in ->tabShortcuts() (Alt+1…9, Alt+] / Alt+[) is suppressed while typing, and both should be verified against existing global key listeners.