Filament Users Laravel Package

Getting Started

Install the plugin and register it on your Filament panel — that is the entire minimal setup:

composer require panservicesas/filament-users

// app/Providers/Filament/AdminPanelProvider.php
use Panservice\FilamentUsers\FilamentUsersPlugin;

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

Then publish the config if you need to override defaults (user model, resource class, navigation group, impersonation behavior):

php artisan vendor:publish --tag="filament-users-config"

Where to look first: the published config/filament-users.php (or the package's src/FilamentUsersPlugin.php if you skip publishing) — it is the single source of truth for which model/resource is used and which actions are enabled. Second, look at Panservice\FilamentUsers\Resources\UserResource to see what the stock resource renders, since your first customization will almost certainly be subclassing it.

First use case: drop the panel plugin in, log in as an admin, and you immediately get a Users table with a working impersonate action. The v2.5.2 changes (copyable email, no row-click navigation, impersonate confirmation) are already what you get out of the box, so a fresh install needs zero configuration to reach a usable state.

Implementation Patterns

Extending instead of editing. Never patch the vendor resource. Subclass it and point the config at your class:

// config/filament-users.php
'user_resource' => App\Filament\Resources\UserResource::class,

class UserResource extends \Panservice\FilamentUsers\Resources\UserResource
{
    public static function table(Table $table): Table
    {
        return parent::table($table)
            ->columns([
                ...parent::table($table)->getColumns(),
                TextColumn::make('last_login_at')->since(),
            ]);
    }
}

Impersonation as a support/debugging workflow. The stock action now asks for confirmation before switching identity (v2.5.2). Treat impersonation as a privileged operation: gate the resource with a policy, and if you need finer control, wrap the action's visible() in a role check. A common pattern is a "Support" role that can impersonate but only view the user list.

Pairing with spatie/laravel-permission. Wire your roles into the resource by adding a roles column and a Select filter, or replace the form's role field with a Select::make('roles')->multiple()->relationship(...). Keep the permission checks on the policy, not the resource, so Filament's canViewAny/canImpersonate gates stay consistent.

Authorization via policies. Register a UserPolicy and let Filament resolve it. This is the cleanest integration point for row-level actions — impersonate, edit, delete all respect the policy without touching the package.

Email copyable + record URL disabled. As of v2.5.2 the email column is copyable and the table row no longer navigates to a view page by default. If you want row-click navigation back, re-enable it in your subclassed table with ->recordUrl(fn (User $record) => UserResource::getUrl('view', ['record' => $record])). If you want the email copyable but with a custom format, override the column and add ->copyable().

Gotchas and Tips

Config caching bites on first install. After publishing config, run php artisan config:clear — a stale cached config is the most common reason a customized user_resource class appears to be ignored.

The impersonate confirmation is a behavior change. If you had tests or E2E flows that clicked impersonate and expected an immediate redirect, v2.5.2 inserts a confirmation modal. Update those assertions (Livewire tests need ->callAction(..., ['confirm' => true]) style handling or a ->assertSee('confirm') step).

Row-click navigation removal affects UX expectations. Users who relied on clicking a row to view a user now must use the row action buttons. If your help docs or onboarding screenshots reference row-click, refresh them. Conversely, if you rely on row-click to reach a custom view page, restore it explicitly (see above) — it does not come back automatically.

Impersonation needs a login guard that supports Auth::login(). If your panel uses a non-default guard, or you have multiple guards, the impersonate action will silently switch the wrong session. Verify filament-users config's guard matches the panel's guard; mismatches are the usual cause of "impersonate does nothing."

Copyable email depends on Filament version. ->copyable() is available on Filament 3 table columns and infolists. On older Filament 2.x panels the column renders without the copy affordance — confirm your filament/filament constraint before filing a bug about the missing copy icon.

Do not use the package's user model assumption blindly. The default config points at App\Models\User. If your user model differs (custom table, UUIDs, soft deletes), set 'user_model' in the config before first use, otherwise the resource queries the wrong table and you get confusing "no users" empty states.

Extension point worth knowing: the plugin exposes a navigationGroup() and a resource getNavigationLabel() override — use these rather than reordering the panel's navigationGroups() array, which is fragile across Filament minor upgrades.

Debugging impersonation: the action logs nothing by default. Add an ->after() on your subclassed action (or a model observer on login) to record impersonator_id on the session/audit table; otherwise you cannot tell who impersonated whom during an incident review.