Laravel Saved Filter Laravel Package

Product Decisions This Supports

• Build vs. buy on scheduled report delivery: this is no longer just a saved-filters persistence layer. 1.10.0 adds per-report timezone handling and passes saved_filter_id / report_id into scheduled sends — meaning the package now owns the "deliver this saved view to this person on this cadence" primitive, not just the view definition. If "email me this report weekly" is on your roadmap, this is the cheapest path to a working scheduler without designing timezone, DST, and re-send semantics yourself.
• Internationalization / global-customer readiness: the nullable timezone column (IANA name, null = app default) with correct DST behavior is the kind of detail that silently blocks EU/LATAM/APAC rollouts. A PM can now commit to "your 08:00 report arrives at 08:00 local time, year-round" as a supportable promise. describeSchedule() surfacing the zone in user-facing copy ("Sent every day at 08:00 (America/Sao_Paulo)") also removes a class of "why did this arrive at 3am?" support tickets.
• Compliance and lifecycle decisions: the new builder context (report_id for signed unsubscribe routes, saved_filter_id linking a delivered email back to the view that produced it) is what makes scheduled sends defensible. Unsubscribe links and provenance are table stakes for marketing-adjacent email; getting them from the package rather than bolting them on is a compliance de-risking decision.
• Reliability risk assessment: the DST fix is a genuine defect — on spring-forward days a report whose local time is skipped (01:30 in Lisbon) could send twice. Duplicate customer emails are a reputational and occasionally contractual problem. Worth a line in release notes to stakeholders and a targeted QA case, but it is fixed in this version, not a reason to hold.
• Deployment/runbook planning (recurring, not one-off): the earlier assessment framed publishing migrations as a one-time onboarding step. It is now a per-minor-release rhythm — 1.10.0 ships a new nullable-column stub, and you re-run vendor:publish --tag="saved-filter-migrations" + migrate. Already-applied stubs are skipped, so it stays idempotent and safe, but the release checklist needs a standing "check for new stubs" item rather than a one-time setup task.
• Upgrade cost: zero code changes required, nullable column, idempotent stubs. No forced migration window, no coordinated release, no customer comms — same low-cost profile as 1.2.0.

When to Consider This Package

Adopt when:

• You need saved filter persistence plus scheduled delivery — the package now spans both. Building scheduling yourself means owning timezone resolution, DST-correct occurrence computation, and delivery linkage; that is more work than it looks.
• You are selling into multiple timezones and want per-user/per-report local send times without building a timezone model. null falling back to the app zone also gives you a sane default for the single-region case.
• You need auditable, linkable scheduled sends — the injected saved_filter_id and report_id support unsubscribe flows and "which saved view produced this email" debugging out of the box.
• You can absorb a recurring publish-migrations step in every release that ships a stub. This is the main ongoing operational tax, and it is small but real.

Look elsewhere when:

• You only want saved filters as a data layer and have no interest in scheduling. The package's center of gravity has moved toward report delivery; you are taking on surface area (and migrations) you won't use. A hand-rolled table may still win here.
• You still need a full UI — filter builder, saved-view switcher, sharing/permissions UX, schedule management screens. Every release reinforces that this is the backend; the interface and the "manage my subscriptions" page remain your build.
• You need complex filter semantics — nested boolean logic, relational joins, query compilation. Nothing in 1.10.0 changes this; you'll pair it with your own query layer.
• Your deployment model forbids publishing vendor migrations or runs migrations from a separate service. The re-publish-per-release requirement makes this friction worse over time, not better.
• You need SLAs, security review, or a contractual support relationship. Note the version history has moved from 1.2 to 1.10 in roughly the same window — that is genuine evidence of active maintenance and should soften the earlier "young and unsettled" concern, but shipping cadence is not the same as support commitments, and the recurring migration stubs confirm conventions are still evolving release to release.

How to Pitch It (Stakeholders)

To executives: The package has grown from "remember my filters" into "remember my filters and email them to me on a schedule," which is a much larger slice of the reporting feature set we'd otherwise build. This release makes scheduled reports safe to sell internationally: each report carries its own timezone, send times hold across daylight-saving changes, and the emails we send can carry proper unsubscribe links and trace back to the saved view that produced them. It also fixes a bug that could have sent a customer the same report twice on a DST transition day. The upgrade requires no code changes and no downtime — but it does add one recurring step to our release process (re-publishing the package's migration files), so it belongs in the release checklist, not just the onboarding doc.

To engineering: 1.10.0 adds a nullable timezone column (IANA name, null = app default) and computes occurrences from the date rather than by stepping a shifted time, which closes the spring-forward double-send. Unknown zone strings fall back to the app zone instead of throwing. Scheduled sends now always receive saved_filter_id and report_id alongside tenant_id, so the mail builder can construct signed unsubscribe routes and deep links. Upgrade path is the usual: vendor:publish --tag="saved-filter-migrations" then migrate; already-run stubs are skipped, so it's idempotent and safe on existing environments. Two things to internalize: this publish step now recurs with each schema-bearing release, so CI/deploy templates should treat it as standard rather than a one-time setup; and we should add a DST-transition test case to our QA checklist for any scheduled-send feature we build on top.

Recommendation: Adopt and upgrade — the timezone and builder-context features materially expand what we can promise customers, and the DST fix removes a live reliability risk. Add "re-publish package migrations" to the standing release checklist and update deploy templates before provisioning any new environment. Re-evaluate if we need filter-builder UI, complex query semantics, or formal support commitments; those remain outside this package's scope.