Filament Logger Laravel Package

Getting Started

v0.8.0 is primarily a compatibility release: Laravel 12 support, an Armenian translation, and a Dependabot update. There are no breaking changes or deprecations called out in the release notes. If you are on Laravel 12, treat v0.8.0 as the minimum version to try; otherwise the upgrade is low-risk.

Minimal setup:

composer require z3d0x/filament-logger

php artisan vendor:publish --tag="filament-logger-config"
php artisan vendor:publish --tag="filament-logger-migrations"
php artisan migrate

Register the plugin in your Filament panel provider:

use Z3d0X\FilamentLogger\FilamentLoggerPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        // ...
        ->plugin(FilamentLoggerPlugin::make());
}

Look first at:

• config/filament-logger.php — resource label, navigation, log model, and logging options.
• The published migrations and the activity_log table.
• The package’s ActivityResource — this is the day-to-day UI for browsing audit history.
• Your Filament panel provider — plugin registration and panel access.

First use case: log changes to a business-critical model, then review who changed what in the Filament “Activities” resource. For model-level history, use Spatie’s LogsActivity trait on the models you want to audit and configure the attributes to log:

use Spatie\Activitylog\Traits\LogsActivity;
use Spatie\Activitylog\LogOptions;

class Post extends Model
{
    use LogsActivity;

    public function getActivitylogOptions(): LogOptions
    {
        return LogOptions::defaults()
            ->logOnly(['title', 'status', 'published_at'])
            ->logOnlyDirty()
            ->dontSubmitEmptyLogs();
    }
}

If you only need Filament login/logout and resource-action history, enable those in the package config first before adding model traits everywhere.

Implementation Patterns

Central audit trail for Filament admins. Keep the package’s activity resource in an admin/settings navigation group and restrict access with a policy or resource authorization. This gives support and operations staff a consistent place to answer “who changed this and when?” without adding custom audit screens.

Model logging with intent. Use LogsActivity only on models where history matters. Prefer logOnly([...]) or logAllExcept([...]) rather than logging every attribute. This keeps the activity_log table useful and avoids storing secrets, tokens, or noisy timestamps.

Custom business events. Use the activity logger directly for events that are not simple CRUD changes:

activity()
    ->causedBy(auth()->user())
    ->performedOn($invoice)
    ->withProperties([
        'old_status' => $oldStatus,
        'new_status' => $invoice->status,
        'tenant_id' => tenant('id'),
    ])
    ->log('invoice.status_changed');

This is a good pattern for approvals, exports, impersonation, and manual admin actions.

Tenant-aware logging. In multi-tenant Filament panels, include the tenant ID in activity properties and scope the activity resource query to the current tenant. If you extend the package resource, override the query or add a policy so users cannot browse another tenant’s history.

Auth and resource event logging. Enable login/logout and Filament resource event logging in config where appropriate. These are useful for compliance and incident review, but they can generate volume quickly. Review the config after publishing rather than assuming every event is enabled.

Extend rather than edit vendor code. If you need different columns, filters, or navigation, point the package config at your own resource class that extends the package’s ActivityResource. This keeps upgrades to v0.8.x and later manageable.

Laravel 12 upgrade workflow. On Laravel 12, update the package, run composer update, run migrations, clear caches, and exercise the activity resource in a non-production environment. The release notes only advertise compatibility; they do not describe new runtime behavior, so focus testing on panel rendering, filters, and model event capture.

Armenian locale. v0.8.0 adds Armenian translation support. If your app uses hy, verify Filament’s locale is set correctly and that the package translations appear in the activity resource. No action is needed for other locales.

Gotchas and Tips

• v0.8.0 is not a feature release. The main reason to upgrade is Laravel 12 compatibility. Do not expect new configuration APIs or UI features from these notes.
• Check your Filament version too. Laravel 12 compatibility does not automatically guarantee compatibility with every Filament major version. Confirm the package’s Filament constraint in composer.json before upgrading a production panel.
• Do not overwrite published config blindly. After upgrading, diff config/filament-logger.php against the vendor default. Re-publishing can overwrite custom navigation, resource, or logging settings.
• Clear caches after config changes. Run php artisan config:clear and, in optimized deployments, php artisan optimize:clear.
• Activity logs grow quickly. Plan retention early. Schedule pruning/cleaning of old activity records and keep useful indexes on the activity_log table. Audit tables are easy to create and easy to forget.
• Avoid logging sensitive attributes. Exclude passwords, API tokens, personal data, and large JSON payloads. logOnlyDirty() helps, but it does not make sensitive fields safe to log.
• Causer can be null. Queue jobs, console commands, and unauthenticated requests may have no causer. Handle null causers in the UI and when filtering. If you use morph maps, keep them consistent across activity records.
• Authorization is your responsibility. The package gives you a UI, not a complete access-control policy. Restrict the activity resource to trusted roles, especially in production admin panels.
• Debug from the table first. If events are not appearing, inspect activity_log directly and check subject_type, causer_type, event, and properties. Then confirm the model uses the logging trait and the relevant event is enabled in config.
• Check migrations after upgrade. Even if v0.8.0 likely has no schema changes, run php artisan migrate and verify the published migration state before deploying.
• Extension points are config-driven. Use a custom activity model, custom resource class, or panel policy rather than modifying vendor files. That preserves the ability to take future Laravel/Filament compatibility releases.