Filament Ban Laravel Package

Getting Started

composer require jeffersongoncalves/filament-ban
php artisan vendor:publish --tag="filament-ban-migrations"
php artisan migrate

Optionally publish config and translations (translations are new in 1.1.0):

php artisan vendor:publish --tag="filament-ban-config"
php artisan vendor:publish --tag="filament-ban-translations"

Then:

1. Add the package trait (typically HasBans / Bannable) to your User model.
2. Register the plugin in your panel provider: ->plugin(FilamentBanPlugin::make()).
3. Open your UserResource and attach the provided ban/unban actions to the table.

Where to look first: the README for trait/middleware names, src/ for the plugin class and actions, config/ for table/column names, and resources/lang/ for the new locale files. Your first use case should be: ban a test user from the Users table, then confirm that user can no longer reach the panel.

Implementation Patterns

• Table actions on the user resource. Add the ban action with a confirmation modal and a reason field, and show the unban action only when the model is currently banned (->visible(fn ($record) => $record->isBanned())).
• Bulk moderation. Pair the ban action with a bulk action for clearing spam/abuse queues in one pass, and gate both behind a policy so only moderators see them.
• Enforcement layer. Typically the package supplies a middleware or a canAccessPanel() override — register the middleware in bootstrap/app.php (Laravel 11+) and rely on the model method for panel access so both web and API entry points are covered.
• Temporary bans. Store banned_at / banned_until and a scheduled command that lifts expired bans; surface the expiry as a DateTimePicker in the action form.
• Notifications and audit. Hook the action's after() callback or listen to package events to email the user and write to an audit table (actor_id, reason, expires_at), so bans are explainable later.
• Localization (new in 1.1.0). Set the app or panel locale (->locale('de') per panel) and the ban/unban actions, modals, and notifications render in the new locales (ar, az, de, es, fa, fr, hi, it, ja, nl, pl, pt, ru, tr, uk, uz, zh_CN). Publish translations only when you need to override wording.
• Tests. Use RefreshDatabase, create a banned user, assert the panel returns 403, then assert unbanning restores access.

Gotchas and Tips

• Bans don't evict live sessions. A banned user with an active session may keep browsing until the session expires. Invalidate sessions or force logout on ban if that matters.
• Middleware registration differs. Laravel 10 uses app/Http/Kernel.php; Laravel 11+ uses bootstrap/app.php. A missing registration silently leaves the panel open.
• Self-lockout. Guard the ban action with ->disabled(fn ($record) => $record->is(auth()->user())) so an admin cannot ban themselves out of the panel.
• Migrations are not auto-run. If the ban columns are missing you get confusing SQL errors, not a clear package error — publish and migrate before wiring the UI.
• Locale directory quirks. New locales use codes like zh_CN; if you publish translations, keep the directory names intact and confirm your app's locale string matches, otherwise Filament falls back to English.
• Permissions still apply. The actions respect Filament policies; if the buttons are missing, check UserPolicy before assuming the plugin failed.
• Caching. After changing the panel provider or plugin registration, run php artisan filament:cache-components / clear config cache — stale component caches are a common "action not showing" cause.
• Extension points. Prefer overriding the action's form/notification through the published config and action callbacks over editing vendor files, so upgrades like 1.1.0 stay painless.