- How do I install tapp/filament-authentication-log in a Laravel 12 app?
- Install the upstream dependency first: follow the laravel-authentication-log configuration, publish and run its migrations, and add the AuthenticationLoggable and Notifiable traits to your authenticatable model. Then run composer require tapp/filament-authentication-log:"^5.0" and register FilamentAuthenticationLogPlugin in your panel provider. Verify that log rows are actually being written before you add the UI, since the plugin is read-only. The 5.x line targets Filament 4/5, Laravel 12 and Laravel Authentication Log 5/6.
- Which Filament, Laravel and Laravel Authentication Log versions does this plugin support?
- The current 5.x line targets Filament 4.x/5.x, Laravel 12.x and Laravel Authentication Log 5.x/6.x. Earlier rows in the compatibility table cover Filament 2 and Filament 3 with their matching Laravel and log-package versions. Check the table before requiring anything, because a mismatch surfaces as a Composer resolution failure at build time rather than at runtime. That is the cheapest possible failure mode, so treat it as a version-table signal rather than a bug.
- Does this package replace rappasoft/laravel-authentication-log or is it a full authentication system?
- Neither. tapp/filament-authentication-log is a thin presentation layer: all persistence, event listeners and database schema live in rappasoft/laravel-authentication-log. The plugin only adds a read-only Filament resource, a relation manager, filters, tooltips and translations. You must install and configure the upstream package, including its migrations and model traits, before the plugin has anything to display.
- What is the difference between the AuthenticationLog resource and the relation manager?
- The AuthenticationLogResource is registered through FilamentAuthenticationLogPlugin and gives you a panel-wide, read-only view of all login activity with filters and tooltips. The AuthenticationLogsRelationManager embeds a single user's log history on your user resource. Most applications register both: the resource for global auditing and the relation manager for per-user context on the user record.
- Why is the plugin linking to the wrong user resource or wrong panel?
- User-resource detection is heuristic, so multi-panel setups and non-standard user resources can resolve incorrectly. That is why the package documents escape hatches: user-resource, resource-page, field-to-display and panelName. Set these in the published config to pin the correct resource and panel. Teams with multiple panels should decide up front which panel hosts the log resource and which panel hosts the user resource.
- How do I add a user's login history to my Filament user resource?
- Register AuthenticationLogsRelationManager in your user resource's relation list, which is getRelations() in current Filament versions. The relation manager reads from the upstream traits, so the model must use AuthenticationLoggable and Notifiable and the dependency's migrations must have run. If the authentication_logs table is missing, the relation manager will fail at render time, so confirm writes exist before wiring it in.
- Do I need to write my own migrations or models for the authentication log table?
- No. The authentication_logs table, model and event listeners all come from rappasoft/laravel-authentication-log. You publish and run that package's migrations and add the AuthenticationLoggable and Notifiable traits to your authenticatable model. This plugin introduces no tables, no migrations and no new write path on login of its own.
- How do I publish and customise the plugin's translations and config?
- Publish translations with php artisan vendor:publish --tag="filament-authentication-log-translations" and publish the config file with its matching tag. The translations cover resource labels, filters and tooltips, and can be edited in place after publishing. The config file is also where you set user-resource, resource-page, field-to-display and panelName when auto-detection does not suit your app.
- What PHP version does filament-authentication-log 5.x require?
- The PHP floor moves with the release cadence: 5.0.6 dropped PHP 8.2 support and added PHP 8.5 and Laravel 13 CI coverage. Match your runtime, Filament major and Laravel major to the 5.x compatibility row exactly, including the PHP constraint. A mismatch fails during composer require, so read a resolution error as a mismatch against the version table, not as a broken package.
- Is it safe to run in production, and what about log retention, privacy and maintenance risk?
- The blast radius is small: the plugin registers a resource and a relation manager in a panel, so an adverse outcome is a UI rollback, not a data migration. The real operational questions are upstream: whether you already run laravel-authentication-log, and what retention or privacy obligations apply to the stored IP addresses and user agents. Treat maturity signals seriously too, since a modest star count, zero dependents and a very recent release mean limited external production validation. Pin the version, review the upstream pruning configuration and keep a documented fallback path.