Laravel Reporting Laravel Package

Getting Started

• Install with Composer: composer require atendwa/laravel-reporting. Use v0.1.7+ if you run Filament panels with multi-tenancy, because this release fixes report resources being pulled into a panel’s tenant scope.
• Publish and review the package config/migrations first, then run migrations. The published config is the best place to understand report registration, resource behavior, and any Filament integration options.
• Register the package’s Filament plugin/resources in the relevant panel provider if you are exposing reports through Filament. For non-Filament usage, start with the simplest report class or config entry and render/export it through the package’s documented entry point.
• First use case: create one small report, such as a sales or activity summary, expose it in a non-tenant panel, and verify it renders correctly. Then add a tenant-aware report and confirm v0.1.7 keeps the report resource out of the panel tenant scope while your report query applies tenant filtering explicitly.

Implementation Patterns

• Keep report definitions in dedicated classes or config entries, and keep Filament resources thin. Put query logic, filters, and aggregation in the report layer rather than in the resource class.
• Register resources per panel rather than globally. In multi-tenant Filament apps, treat v0.1.7’s behavior as intentional: report resources are not automatically scoped by the panel tenant. Apply tenant constraints inside the report query when tenant isolation is required.
• Separate global/admin reports from tenant-facing reports. Use panel registration, resource access checks, and explicit query scopes to control who sees what instead of relying on implicit tenant scoping.
• Integrate with existing Filament authorization and navigation. Use policies or canAccess checks for resource visibility, and avoid duplicating tenant filters in both the resource and report query without tests.
• Day-to-day workflow: define the report, register the resource in the correct panel, test as both a tenant and non-tenant user, then add exports or scheduled delivery only after visibility and scoping behavior is verified.

Gotchas and Tips

• v0.1.7 changes tenant-scope behavior for report resources. If you previously depended on Filament implicitly scoping those resources to the current tenant, audit visibility after upgrading and add explicit query scoping where needed.
• Clear caches after upgrading: run php artisan optimize:clear and confirm panel provider registration is still correct.
• Multi-tenancy issues often appear as resources missing from one panel or visible across tenants. Check the panel’s tenant() configuration, resource registration, and report query constraints together.
• Do not rely on resource-level tenant scoping and report-level tenant scoping interchangeably. Duplicating both can hide data unexpectedly, while relying on neither can leak data across tenants.
• Use the package’s extension points—published config, custom report classes, resource overrides, and panel plugin options—rather than editing vendor files.
• This is a 0.x package, so pin the version in production and review changelogs before minor upgrades. The v0.1.7 fix is small but relevant for Filament multi-tenant deployments.