Inter-team permissions

[judgej]

We have been using v4 for some time, but with teams applied. Out implementation looks very similar to the teams introduced in v5, with one major exception: all model roles and model permissions must have a team set.

Our team IDs are nullable, which means they work across teams. So a super-admin user can have a role that applies to ALL teams, just by setting their team_id to null for an admin role.

The way this operates in this package is to make the team ID mandatory for every user role. So on creating a team, users requiring access to that team with an elevated privilage must be explicitely added to that team.

Now, it looks to me like this package already handles roles in this way:

https://github.com/spatie/laravel-permission/blob/main/src/Traits/HasRoles.php#L65

Here a user role can be for the team currently set or can be null, for "any team".

The database migrations to convert the package to team-based permissions makes those columns mandatory, they cannot be null.

So - if I made the team_id columns optional in the migrations, would this just work as I want? Could I add a role to a user with a null team_id in the user/role pivot table, and have a role that the user will then have in every team they go into? Would be awsome if it worked this way, then I can drop a bunch of custom permissions code we have.

[judgej]

In short, I want to set the team_id on model_has_roles to nullable(), and set it to null where I want a user to have that role on ALL teams. Will this simply work out of the box, or break things? It looks like it may work, but wondering if someone closer to the code or with more experience in this has any insights.

My few super-admin users do not need to be a member of a team to be able to select that team to do some admin in there.

[parallels999]

My few super-admin users do not need to be a member of a team

Use Gate::before

basic-usage/super-admin#content-gatebefore

[judgej]

And can see that would be very useful for true super-admins that have permission to do absolutely anything, and Gate::before() will come in useful for that. What I needed were roles for slightly-less-than-super admins - several levels that have various tasks to perform across any team, but not necessarily have all possible permissions.

[judgej]

Ah, just read the role check again, and it doesn't do quite what I had hoped:

        return $relation->wherePivot(PermissionRegistrar::$teamsKey, getPermissionsTeamId())
            ->where(function ($q) {
                $teamField = config('permission.table_names.roles').'.'.PermissionRegistrar::$teamsKey;
                $q->whereNull($teamField)->orWhere($teamField, getPermissionsTeamId());
            });

The whereNull($teamField) applies to the roles table in the relationship. I am looking for the team ID in the pivot table to optionally be null too. Something like this:

        return $relation->wherePivot(PermissionRegistrar::$teamsKey, getPermissionsTeamId())
            ->orWherePivotNull(PermissionRegistrar::$teamsKey) // <<<=== new condition
            ->where(function ($q) {
                $teamField = config('permission.table_names.roles').'.'.PermissionRegistrar::$teamsKey;
                $q->whereNull($teamField)->orWhere($teamField, getPermissionsTeamId());
            });

That one line - I think - would open up roles that can span across all teams, making super-admins much easier to manage. If you didn't want that feature, then leave the team ID field as not-nullable.

If this works for me, would it be a feature worth submitting?

[judgej]

The pivot methods in eloquent are a bit of a mess. They all have an "or" version, but you cannot chain them because eloquent does not wrap them up parenthesis. Not sure what the point of them are.

So instead, I have moved the pivot conditions to a where clause, which works because the pivot table is joined to the authenticated table. My roles() method, added to my User model to override the one provided by the permissions trait, now looks like this:

    /**
     * A model may have multiple roles.
     */
    public function roles(): BelongsToMany
    {
        $relation = $this->morphToMany(
            config('permission.models.role'),
            'model',
            config('permission.table_names.model_has_roles'),
            config('permission.column_names.model_morph_key'),
            PermissionRegistrar::$pivotRole
        );

        if (! PermissionRegistrar::$teams) {
            return $relation;
        }

        return $relation //->wherePivot(PermissionRegistrar::$teamsKey, getPermissionsTeamId())
            ->where(
                fn ($query) => $query->where(config('permission.table_names.model_has_roles').'.'.PermissionRegistrar::$teamsKey, getPermissionsTeamId())
                    ->orWhereNull(config('permission.table_names.model_has_roles').'.'.PermissionRegistrar::$teamsKey)
            )
            ->where(function ($q) {
                $teamField = config('permission.table_names.roles').'.'.PermissionRegistrar::$teamsKey;
                $q->whereNull($teamField)->orWhere($teamField, getPermissionsTeamId());
            });
    }

That's for PHP 8.1+, so replace the arrow function for earlier versions.

So this allows me to make the team_id nullable on model_has_roles. When null, that role then applies to all teams for that user. There is no need to add superusers to each new team as they are created.

The pivot conditions moved to the where clause work because this is an inner join (outer joins need conditions to be added to the join clause, since they are conditional on the join returning a row, but that doesn't count here and so is safe).

It is necessary to notify the table name in the pivot condition, as the same column appears in both joined tables - the roles and model_has_roles. I'm happy with this - I can submit it as a PR if this is a desired feature.

[parallels999]

wherePivot it is not the same as where, works the same under certain circumstances, but not all

[judgej]

This is the approach I'm trying now:

1. Add global (inter-team) privilages to team 0. There is no team 0, so it's just a kind of placeholder.
2. For any non-team section of the site, set the permissions team ID to zero in middleware: setPermissionsTeamId(0); All roles and privileges used are those on team 0.
3. For the team-based pages there are two possible approaches:
   • Use the team 0 roles to sync up those roles on all teams for the users that have them. Team 0 is a kind of master list of administration roles. Just use the roles and permissions as normal.
   • Or in the user's can() method, try checking ability for the the current teram first, then if that says "no", switch to team 0 and try again, switching back to the original team at the end. Any method, like can(), that this needs to be done for will need extending, and could be quite intensive on the database when switching teams too many times.

Then team-based roles can be added when in a team context, and administration roles can be added when not in a team context.

Note: My team is set in the URL path, so any administration path that does not have a team in there, does not have a team selected, and so the user is not in a team context. I also realised that a user does not have to be a member of team to have roles on that team, which is great.