rupadana/filament-user-resource
A ready-made user management resource for Filament admin panels. It provides CRUD screens for users, profile and password fields, and a quick starting point for managing accounts in Laravel apps without building resource pages from scratch.
This package gives you a drop-in user management resource for a Filament panel — user CRUD plus a self-service profile page — so you don't hand-roll the same Resource for every project.
composer require rupadana/filament-user-resource, then publish the package config/migrations (php artisan vendor:publish --tag=..., check the README for the exact tags shipped with 1.0.x) and run php artisan migrate. Check what landed in config/ first — the published config is the real API surface of this package, and the toggles there (model class, navigation group, which features are enabled) determine most of its behaviour.PanelProvider (or let the resource auto-discover, depending on your Filament version). Boot the panel and confirm the "Users" nav item appears before you touch anything else.UserResource. Delete or rename the existing one in the same commit — two resources pointing at the same model produce duplicate nav entries and confusing route collisions.Extend, don't fork. The shipped resource class is meant to be subclassed: create app/Filament/Resources/UserResource.php extending the package class, then override form(), table(), getPages(), or getNavigationGroup() as needed. Upgrades stay painless because you never edit vendor files.
Keep profile and admin separate. The package's profile page operates on auth()->user(); the admin resource operates on arbitrary users. Resist merging them — you'll end up with permission checks scattered through form schema. Apply your UserPolicy to the resource and let the profile page rely on Auth.
Compose with roles, don't replace them. If you use Spatie Permission (or Filament Shield), leave role assignment to a dedicated relation manager / field and let this package own the identity fields (name, email, password, avatar). Trying to make one form own both identity and authorisation is the most common source of sprawl.
Per-panel scoping. In multi-panel apps, register the resource only on the panels that should manage users, and use modifyQueryUsing() for tenant scoping rather than relying on global scopes that will also hit the profile page.
Password handling. Prefer a single dehydrateStateUsing(fn ($state) => Hash::make($state)) on the password field and a ->dehydrated(fn ($state) => filled($state)) so blank-on-edit doesn't wipe credentials. Never let the package hashing and your own hashing both run.
Testing. Because these are Livewire components, livewire(UserResource\Pages\CreateUser::class)->fillForm([...])->call('create') plus a policy assertion covers most regressions; add a test that a non-privileged user gets 403 on the resource index.
composer.lock so a CI run doesn't silently pull a different patch.UserResource still exists, or the plugin is registered on two panels.auth() call can disagree; set the model/guard explicitly in config rather than assuming the default.php artisan permission:cache-reset and php artisan optimize:clear — stale caches mimic authorisation bugs.APP_URL or the storage symlink is wrong; confirm php artisan storage:link and that the configured disk is public in local dev.composer update rupadana/filament-user-resource --with-dependencies → re-diff published assets → clear caches → smoke-test create/edit/profile pages.How can I help you explore Laravel packages today?