tonystore/livewire-permission-manager
A Livewire-powered permission manager for Laravel that lets you manage roles and permissions through a simple, reactive UI. Integrates with Spatie's permission package to handle role assignment and access control without leaving your dashboard.
This package is a UI layer, not a permission engine. It gives you a Livewire-rendered screen for creating roles, permissions, and attaching them to users; the underlying authorization is almost certainly spatie/laravel-permission, so install and configure that first — run its migrations, seed at least one role, and confirm $user->assignRole() works before touching this package. Otherwise the UI will render against empty or missing tables and the failure modes are confusing.
Minimal path:
composer require tonystore/livewire-permission-manager
php artisan vendor:publish --tag=livewire-permission-manager-config # verify tag in README/source
php artisan vendor:publish --tag=livewire-permission-manager-assets # views / migrations if any
Then check the package's README.md and src/ for the component class name and config file. With ~17 stars and zero dependents, treat the source as the documentation — one grep -r "class .*Component" src/ will tell you the exact Livewire class to mount.
First use case: a single guarded admin route.
// routes/web.php
Route::middleware(['web', 'auth', 'role:super-admin'])
->get('/admin/permissions', fn () => view('admin.permissions'));
{{-- resources/views/admin/permissions.blade.php --}}
<livewire:livewire-permission-manager />
Or mount it directly as a full-page component if the package ships one. Either way, the first meaningful test is: create a role in the UI, assign it to a test user, and verify @can / Gate::allows() respects it. That single loop validates migrations, guard config, and cache in one pass.
Admin panel embed. The natural integration is inside an existing admin layout — wrap the component in your Blade @extends/<x-app-layout> and let it own only the role/permission table region. Don't let it render its own layout unless you intend to replace your dashboard chrome.
Route + middleware gating. Always protect the route separately from the package. The component manages permissions; it does not necessarily authorize who can open it. Use role: or a dedicated Gate (Gate::define('manage-permissions', ...)) so a user with the "admin" role can't accidentally edit roles they shouldn't.
Seed-then-edit workflow. Use seeders for baseline roles (super-admin, editor, viewer) and reserve the UI for day-to-day adjustments. The UI is for iteration; seeders are for reproducibility across environments, CI, and fresh deploys. Mixing the two — hand-creating production roles that don't exist in seeders — creates drift the moment you rebuild a database.
Multi-guard setups. If you have web and api guards, decide up front which guard the UI edits. Spatie scopes roles and permissions per guard; a UI that silently targets the default guard will show an empty permission list when your admin user lives on a different guard. Configure the guard in the package config before building on top of it.
Blade consumption. The output is standard Spatie data, so downstream checks are unchanged:
@role('editor') <a href="...">Edit</a> @endrole
@can('publish-posts') <button>Publish</button> @endcan
Testing. Because the UI is just a Livewire component, you can test it like any Livewire component: Livewire::actingAs($admin)->test(YourComponent::class)->call('assignRole', ...). Keep those tests minimal — assert the state change propagates to $user->hasRole() rather than testing the package's own rendering.
Extension via published views. If you need grouped permissions, search/filter, or a different table, publish the views and fork them locally rather than waiting on upstream. With 17 stars the release cadence will be slow; local view overrides are the lowest-friction extension point.
@can is false." Spatie caches roles/permissions per user; after programmatic changes (seeders, artisan commands, tests) you need php artisan permission:cache-reset or app(PermissionRegistrar::class)->forgetCachedPermissions(). The package UI usually flushes on its own writes, but your other code paths won't.composer require will eventually pull a breaking change or become incompatible with a Livewire 3.x minor. Lock it in composer.json and commit the lock file.wire: directives, mount signatures). Check composer.json of the package before installing alongside a recent Livewire.User is often hardcoded via config('auth.providers.users.model')), whether the super-admin role bypass is wired, and whether it uses syncRoles (destructive) or assignRole (additive) — the difference matters when editing a user with existing roles.config('permission-manager.guard') vs the guard your admin user authenticates under, not a broken install.Gate::before bypasses are set up. Spatie's docs recommend a Gate::before for a super-admin role. The package won't add that for you; if your super-admin can't do everything, that's why.php artisan vendor:publish --tag=... for CSS/JS and confirm your layout includes @livewireStyles / @livewireScripts (Livewire 3 handles this, Livewire 2 does not).vendor/. If the package goes stale (plausible at this star count), your wrapper becomes the migration seam to a homegrown component.How can I help you explore Laravel packages today?