++ fix import e permessi

This commit is contained in:
Francesco Picone
2026-07-25 22:39:38 +02:00
parent 3a530704a2
commit 9421891989
9 changed files with 375 additions and 33 deletions

View File

@@ -0,0 +1,51 @@
<?php
use Illuminate\Database\Migrations\Migration;
use Spatie\Permission\Models\Permission;
use Spatie\Permission\Models\Role;
use Spatie\Permission\PermissionRegistrar;
return new class extends Migration
{
/**
* Guarantee that no "assistente" can modify or delete existing
* assignments.
*
* The only way to edit/delete an assegnazione is through the Registro's
* admin CRUD, which is gated on `settings.manage` (backend abort_if + the
* @can in registro.blade.php). By baseline the assistente role never has
* that permission, so an assistente can only view the registro, create new
* assignments (territori.assign) and return them (territori.return).
*
* RolesAndPermissionsSeeder grants additively (givePermissionTo, never
* syncPermissions) so it can re-run without clobbering UI-granted
* permissions — which means it also never *revokes*. If an administrator
* had ever granted settings.manage to the assistente role through the UI,
* that drift would survive every re-seed. This migration closes that gap
* for existing databases. It is idempotent: a no-op when the role already
* lacks the permission.
*/
public function up(): void
{
app(PermissionRegistrar::class)->forgetCachedPermissions();
$role = Role::where('name', 'assistente')->first();
$permission = Permission::where('name', 'settings.manage')->first();
if ($role && $permission && $role->hasPermissionTo($permission)) {
$role->revokePermissionTo($permission);
}
app(PermissionRegistrar::class)->forgetCachedPermissions();
}
/**
* Intentionally irreversible. Re-granting settings.manage to the
* assistente role would reintroduce the very ability this migration
* removes, so rolling back must not do it.
*/
public function down(): void
{
// no-op
}
};