Group 2.0/3.0 compatibility

Hitting "The calculator "Drupal\group\Access\IndividualGroupPermissionCalculator" returned permissions for scopes other than "individual""

See #3352235-8: Calculator returns roles other than individual →

Also make sure you do not try to assign an insider or outsider role to a membership via code.

??

To support Group 4.x in the future we'll run into https://www.drupal.org/node/3383363 →

This is working, but on login is throwing messages about insider roles being revoked.

@bluegeek9 you were right, it should have been !$role->getGlobalRoleId(), it was because my roles were screwed up.

All committed to 2.0.x-dev, but it's working for me using Group 2.2.1!

Thank you for your quick response! I have applied the 2.0.x-dev version and all errors are gone. It has been several years since I set up Group, so trying to wrap my head around the new permissions/roles.

When I updated group authorization to 2.0.x-dev version, and checked on the group assignments, all my Group and Roles were empty. All my LDAP Queries map to a "member" role. I went back to my groups and noticed that on updating to Group 2.2.1 it converted my Member role to "Insider" which is "Assigned to all members who have the corresponding global role." Technically all my members are also authenticated users, so that I guess makes sense? But I switched the role to "Individual" since I need it to show on the group assignment page, and when I refreshed, member was restored to the Group and Roles drop down.

Any chance you could tell me what the difference is between those two types of roles? And, why Group Authorization only recognizes the "Individual" role?

I tested with a fresh install.

I created a new group type. There were two default Administrator roles, an inside, and an outsider. I created a new role, Superstar as an Individual.

I think we need to include an option for role 'None'.

Group roles can belong to one of three scopes:

Outsider: Assigned to all non-members who have the corresponding global role.
Insider: Assigned to all members who have the corresponding global role.
Individual: Can be assigned to individual members.

Outsider and Insider roles are automatically granted based of Drupal roles. If you need a user from an LDAP group mapped to an Outsider role you need to use the authorization_drupal_roles module, part of the authorization project. To map a user to an Insider role, they must be a member, and they must have the corresponding Drupal role.

group (2.2.1)
authorization (1.1)
authorization_group (2.0.x-dev)
ldap (4.5.0)

The thing that's kind of weird about Outsider/Insider roles vs the older versions of groups is that you'll need to create duplicate roles (one outsider, one insider) if you don't want a user to lose permissions when becoming a member. That's nothing to do with this module though, it's just a heads-up since it works a little differently.

I think we need to include an option for role 'None'.

Yeah agree here, we should be able to create the membership without assigning roles.

If you need a user from an LDAP group mapped to an Outsider role you need to use the authorization_drupal_roles module

Or an Insider role: you'd map them to the global role using authorization_drupal_roles, and map them to the group using this module. The Insider role would get picked up automatically.

I added the 'None' role, but the revokeGrants needs to be updated. I think we should add a base field to the user entity to track the group:roles granted to a user by the authorization_group, like authorization_drupal_roles does for roles. This would also allow us to revoke only memberships granted by authorization.

I don't disagree in theory, but that would leave existing installs in a weird state where if they updated then none of the existing roles would be cleared since they don't exist in that field. Unless an update hook was written to pre-fill those values for every user with a role, but is having that hook making the right assumptions?

I also don't have much more time I can put into this module at the moment past possibly taking a look at updating revokeGrants.

Do we just want to cut a release where it keeps working the way it has been? Or should 2.x stay as just a dev release until a decision is made?

I created a new issue to handle the new field.

I think the way revokeGrants works currently is it removes any group:role which a mapping exists for, but the user was not granted by a provider.

We can add the field, and bulk inserts users' current group:role memberships, which a mapping exists for. This retains the existing behavior for existing users and add the ability to manually assign a user.  

✨ authorization_group_groups field Active

Sounds good to me!

My main contribution was unit test. I also made small changes. I did remove submitRowForm, because the Authorization module does this for us, just not in parent::submitRowForm().

Automatically closed - issue fixed for 2 weeks with no activity.