Group Authorization doesn't support the recommended versions of Group module, 2.0 and 3.0, blocking updating of Group module.
Changing my composer.lock dependency to group 2.0, I was able to update to Group 2.0 to see how Group Authorization would fare, and got this error on the Group Authorization UI page:
Error: Call to undefined method Drupal\group\Entity\GroupRole::isInternal() in Drupal\authorization_group\Plugin\authorization\consumer\GroupConsumer->buildRowForm() (line 65 of modules/contrib/authorization_group/src/Plugin/authorization/Consumer/GroupConsumer.php).
Group Authorization needs a 2.0.0 version compatible with Group 2.0/3.0
Group API changes are documented here:
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib...
In the Group 2.0 release notes, roles have been completely reworked:
https://www.drupal.org/project/group/releases/2.0.0
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | group-membership-2023-11-02.png | 33.91 KB | bluegeek9 |
| #12 | authorization_group-2023-11-02.png | 28.18 KB | bluegeek9 |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #3
karlsheaHitting "The calculator "Drupal\group\Access\IndividualGroupPermissionCalculator" returned permissions for scopes other than "individual""
See #3352235-8: An already assigned individual role can be made out/insider, leading to a crash in the permission calculation
??
Edit: Nevermind! My converted roles were screwed up.
Comment #4
karlsheaTo support Group 4.x in the future we'll run into https://www.drupal.org/node/3383363
Comment #5
karlsheaThis is working, but on login is throwing messages about insider roles being revoked.
Comment #7
karlshea@bluegeek9 you were right, it should have been
!$role->getGlobalRoleId(), it was because my roles were screwed up.Comment #8
karlsheaAll committed to 2.0.x-dev, but it's working for me using Group 2.2.1!
Comment #9
willabby commentedThank 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?
Comment #10
willabby commentedComment #12
bluegeek9 commentedI 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)
Comment #13
karlsheaThe 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.
Comment #14
karlsheaYeah agree here, we should be able to create the membership without assigning roles.
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.
Comment #15
bluegeek9 commentedI 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.
Comment #16
karlsheaI 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?
Comment #17
bluegeek9 commentedI 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.
#3399106: Revoke membership and roles previously assigned by authorization
I think we can hold off on a 2.0.0 release for another week. There are 13 sites using the module.
Comment #18
karlsheaSounds good to me!
Comment #20
bluegeek9 commentedMy 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().
Comment #21
bluegeek9 commented