- How do I install eightynine/filament-reports in a Laravel Filament panel?
- Install it with Composer, then register FilamentReportsPlugin::make() on your panel provider using the plugin() method, and publish the package config. If the package persists report definitions or saved filters, publish and run its migrations as well. Realistic effort to a first working report is hours rather than days, assuming your Filament version matches the package constraints.
- Which Filament, Laravel and PHP versions does filament-reports support?
- The package is built as a Filament panel plugin targeting Filament v3 or v4 panels on PHP 8.1 and a current Laravel major, but the exact Composer constraints should be verified in a spike rather than assumed from the README. Filament ships breaking majors roughly annually, so pin your versions and check the composer.json requirements before committing. Confirming your target panel's Filament major is the single fact that gates everything downstream.
- Are report definitions application-owned classes or package config arrays?
- This is the architecture question worth answering before you commit: the package expresses report definitions as PHP classes rendered as Filament pages or widgets, but you should confirm whether that is a thin definition layer over your models or a parallel query DSL. Prefer app-owned classes under app/Reports implementing the package contract, with a thin internal seam on top, so report logic stays testable and portable. If logic lives in vendor-shaped classes, it becomes harder to unit test or move off later.
- Can filament-reports export reports to CSV or Excel, and are exports queued?
- Exports are advertised as part of the feature set, but the package does not clearly document whether they are queued and streamed or run synchronously inside the Livewire request. Synchronous exports over wide date ranges and unbounded tables are the classic failure point for report builders, so test this early with realistic data volumes. If exports are in-request only, wrap them in a queued job of your own.
- Are report filters safe from SQL injection in filament-reports?
- Report builders compose selectRaw, aggregate expressions and date truncation, which is an injection-adjacent surface whenever a user-supplied filter or column name reaches raw SQL. Verify in a spike whether filters are bound as parameters or interpolated into raw SQL, and treat dynamic column selection as untrusted input until proven otherwise. Do not expose arbitrary column or filter input to lower-privileged users before auditing that path.
- Does filament-reports respect Filament's tenancy and authorization policies?
- Because it registers as a standard Filament plugin and renders as Filament pages and widgets, report screens inherit the panel's existing navigation, policies and tenancy scoping by construction. The risk is that the package bypasses that layer with its own query path and returns rows a user should not see. Confirm multi-tenant scoping and policy enforcement explicitly before shipping reports to tenant users.
- Can I display a filament-reports report as a dashboard widget?
- Yes. The package is designed to render report results either as tables on a Filament page or as dashboard widgets, which lets you surface key aggregates on the panel dashboard without building custom widgets. Filters, sorting and aggregates defined on the report carry over, so a single definition can serve both the full report page and a summary widget.
- Does filament-reports work with MySQL, PostgreSQL and SQLite?
- Cross-database support is not documented, and report builders lean on date truncation, aggregate expressions and grouping, which behave differently across MySQL, PostgreSQL and SQLite. Date functions, GROUP BY strictness and timezone handling are the usual sources of incorrect or failing reports. Run your reports against your actual production driver, not just the SQLite database used in local testing.
- Is filament-reports production-ready given its low star count and single maintainer?
- With roughly 101 stars, zero visible dependents and one apparent maintainer, the package is not meaningfully exercised in production by anyone the registry can see. Treat it as source-available code you are adopting rather than a dependency you are consuming, and budget for a fork at the next Filament major. Pin the version, keep your report definitions app-owned, and plan for upgrade work yourself.
- How do I test reports built with filament-reports, and what is the migration path off it?
- Define reports as application classes under app/Reports implementing the package contract, keeping a thin internal seam so query logic can be unit tested and swapped later. Check whether the package ships a real CI matrix that verifies Filament and Laravel compatibility, or merely asserts it in the README. If you ever move to a custom report screen or another package, app-owned definitions limit the lock-in to the rendering layer.