8 – Complex Group Permissions for Users and Content


My application holds content about projects. Projects have a number of entity reference fields including ones giving them both a team and a region. Projects live inside of units (1-to-1 relationship) which hold a lot of taxonomy terms specific to that unit. Users belong to units in either an unrestricted role or one of several restricted roles (referred to as “sub-roles”). Users with a restricted role belong to a specific team and optionally region, and are only granted access to projects which belong to that team and region. Users can have multiple different restricted roles inside of a single unit, each with different teams and/or regions. Each restricted sub-role is granted slightly different permissions to projects within the unit as well as some unit-level content that is not team or region specific. One of the sub-roles restricts its users’ access to projects on a user-by-user basis.

I’m tracking three solutions. I’m looking for better ones, or improvements to these:

  1. Use the group module. Each unit is a group. The group has two roles, unrestricted and restricted. Various permissions are set on the group for these two roles. Users with the restricted role have additional fields on their group membership entity to track the various levels of access they have in a multi-entity reference field; their sub-roles, teams, and regions. This requires implementing a lot of custom content permissions, as well as the custom sub-roles and permissions for them.

  2. Use the group and sub_group modules. Each unit is a group. It has subgroups for team+region (or 2 levels of subgroups). The unit group has two roles, unrestricted and restricted. The subgroup(s) have the restricted sub-roles. Permissions are attached to each group type as expected. This requires implementing custom code to add/edit/delete subgroups when the related terms change, add content to multiple groups and subgroups when its relevant fields change, and to manage the user membership to all the groups and subgroups. It also makes the number of subgroups grow N^2 (a third permissions field is being considered, so perhaps even N^3) which makes me feel like it’s the wrong approach and also I don’t know what speed implications for content permissions there might be.

  3. Unit is a node. All content and taxonomy terms relate to the unit by an entity reference field. Users have a multi-entity reference field to assign them to units, their custom roles, and if needed the teams and regions. All entity permissions are custom hooks. This feels like I’m declaring failure.