Roles y permisos del equipo

Weblabor Base tiene un solo conjunto de roles para toda la aplicación. Weblabor Teams lo conserva para el panel de administración y agrega un conjunto de roles dentro de cada equipo, sobre el modo de equipos de Spatie Permission. Esta guía dice con qué roles nace un equipo, cómo escribe más y cómo declaras los permisos que pueden llevar. Cómo se elige el conjunto correcto en cada petición está en El contexto del equipo.

Dos guards

Un permiso pertenece a un guard. Ser admin del producto no dice nada sobre lo que la persona puede hacer dentro de un equipo, y ser propietario de un equipo no dice nada sobre el panel de administración. La misma cuenta puede ser ambas cosas.

Los roles con los que nace un equipo

config/app.php los declara:

'team_owner_role' => 'administrator',
'team_default_role' => 'user',
'team_roles' => [
    'user' => [
        'retrieve members',
    ],
],

Cuando se crea un equipo, cada rol de team_roles se crea dentro de él con los permisos listados, y el rol nombrado en team_owner_role se crea con todos los permisos del guard team y se asigna a quien lo creó. Cada miembro agregado después recibe el rol nombrado en team_default_role, que tiene que ser una de las claves de team_roles.

Agrega una clave a team_roles y cada equipo creado desde entonces la tiene. Los equipos que ya existen no: escribe una migración que cree el rol en cada uno de ellos cuando lo necesites.

El propietario

El propietario es la persona en creator_user_id. Además de tener el rol de propietario, el propietario pasa cada comprobación de política del equipo sin consultar un permiso: los miembros, la configuración, los cobros. No hay manera de hacer propietaria a otra persona desde la interfaz; el equipo fue creado por una persona y sigue siendo suyo.

Roles que el equipo escribe

/team/roles es un CRUD de los roles del equipo, acotado al equipo: un rol creado ahí tiene el id del equipo, aparece sólo ahí y su nombre tiene que ser único dentro de ese equipo y en ningún otro lado. El formulario lista cada permiso del guard team como casillas.

Un rol se puede clonar desde la lista por un miembro con create role: la copia conserva los permisos y el equipo, y recibe un nombre que no choca.

Eliminar un rol que un miembro tiene deja a ese miembro sin rol en el equipo; asigna otro primero desde la lista de miembros.

Declarar un permiso de equipo

Los permisos se declaran una vez, en config/app.php → permissions, cada uno con su guard:

'permissions' => [
    'dashboard admin' => 'web',
    'dashboard user' => 'web',

    'retrieve members' => 'team',
    'create members' => 'team',
    'update members' => 'team',
    'delete members' => 'team',
    'edit settings' => 'team',
    'manage plans' => 'team',
],

Corre php artisan db:seed --class=PermissionSeeder después de agregar uno y existe para cada equipo, listo para marcarse en un rol. Con discover_front_permissions encendido, el seeder también crea retrieve, create, update y delete para cada recurso de Laravel Front, en el guard que el recurso declara: un recurso bajo app/Front/Resources/Team/ los recibe en el guard team. Ve Construye un CRUD acotado al equipo.

allow_permisisons_deletion elimina al sembrar cualquier permiso que ya no se declara ni se descubre, así que un permiso que dejas de declarar desaparece de cada rol.

Qué protegen los permisos que vienen incluidos

Comprobar un permiso en tu código

Dentro de una petición bajo /team el contexto ya es el del equipo, así que las políticas y los helpers de la base funcionan tal cual:

$this->authorize('viewAny', UserTeam::class);
auth()->user()->hasPermissionTo('edit settings', 'team');

Pasa el guard cuando llames a Spatie directamente, como en la segunda línea, porque el guard predeterminado del usuario es web. En un job en cola, un comando o un modal cargado fuera de la petición, establece el contexto primero; El contexto del equipo explica cómo.