Costable Laravel Package

Getting Started

• Update to 1.5.0 and start with the package’s index/report flow that uses buildIndexQuery; this is now the main integration point for search and filtering.
• Look first at your resource/report query class, the package’s buildIndexQuery implementation, report filter configuration, and card definitions.
• First use case: build an auth-scoped, searchable index/report where the logged-in user only sees their data, with an “All” date range and cards loaded separately from the main request.

Implementation Patterns

• Extend or override buildIndexQuery rather than adding ad-hoc where clauses in controllers. Call the parent method first, then add your own constraints so package search and auth scoping stay consistent.
• Add eager loading with with() for relationships shown in index tables, reports, and exports. Treat the N+1 fix in 1.5.0 as a baseline, but verify your own custom columns and cards are not introducing new lazy loads.
• Use the package’s auth-aware query scoping for logged-in users, and add explicit policy/gate bypasses for admin or support roles instead of weakening the default scope globally.
• For report filters, use the new “All” range for dashboards and exports, but pair it with sensible pagination, chunking, or background export handling for large datasets.
• Keep cards on their own request path. Do not load card data inside the main index/report action; use the package’s separated card loading behavior and cache card payloads per user/filter combination where appropriate.

Gotchas and Tips

• Always call parent::buildIndexQuery() when overriding it; skipping it can break package search, auth scoping, and future fixes.
• Test auth scoping with multiple users, guests, and admin roles. Query-level auth can conflict with existing global scopes or manually added user_id filters.
• Enable Model::preventLazyLoading() in local/testing to catch N+1 regressions in custom columns, filters, and cards.
• The “All” report range can be expensive; avoid unbounded exports and make sure indexes support the date/user columns used by filters.
• Card requests should be idempotent and cache-keyed by filters, user, and date range; clear those keys when underlying data changes.
• Use package extension points such as custom filters, query callbacks, and card classes before forking core query logic.