Team roles and permissions

Weblabor Base has one set of roles for the whole application. Weblabor Teams keeps it for the admin panel and adds a set of roles inside each team, on Spatie Permission's teams mode. This guide says which roles a team is born with, how it writes more, and how you declare the permissions they can carry. How the right set is chosen on each request is in The team context.

Two guards

A permission belongs to one guard. Being an admin of the product says nothing about what the person can do inside a team, and being a team's owner says nothing about the admin panel. The same account can be both.

The roles a team is born with

config/app.php declares them:

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

When a team is created, every role in team_roles is created inside it with the permissions listed, and the role named in team_owner_role is created with every permission of the team guard and assigned to the creator. Every member added later receives the role named in team_default_role, which has to be one of the keys of team_roles.

Add a key to team_roles and every team created from then on has it. Teams that already exist do not: write a migration that creates the role in each of them when you need that.

The owner

The owner is the person in creator_user_id. Besides holding the owner role, the owner passes every policy check of the team without consulting a permission: the members, the settings, the billing. There is no way to make someone else the owner from the interface; the team was created by one person and stays theirs.

Roles the team writes

/team/roles is a CRUD of the team's roles, scoped to the team: a role created there has the team's id, appears only there, and its name has to be unique inside that team and nowhere else. The form lists every permission of the team guard as checkboxes.

A role can be cloned from the list by a member with create role: the copy keeps the permissions and the team, and gets a name that does not collide.

Deleting a role a member holds leaves that member with no role in the team; assign another one first from the members list.

Declaring a team permission

Permissions are declared once, in config/app.php → permissions, each with its 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',
],

Run php artisan db:seed --class=PermissionSeeder after adding one and it exists for every team, ready to be ticked in a role. With discover_front_permissions on, the seeder also creates retrieve, create, update and delete for every Laravel Front resource, on the guard the resource declares: a resource under app/Front/Resources/Team/ gets them on the team guard. See Build a team-scoped CRUD.

allow_permisisons_deletion deletes on seeding any permission that is no longer declared or discovered, so a permission you stop declaring disappears from every role.

What the shipped permissions guard

Checking a permission in your code

Inside a request under /team the context is already the team's, so the base's policies and helpers work as they are:

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

Pass the guard when you call Spatie directly, as in the second line, because the user's default guard is web. In a queued job, a command or a modal loaded outside the request, set the context first; The team context explains how.