Sitewide Administrator permissions not working

Explained also in this video: https://youtu.be/xo2z8NuKEH4

Hint for others: Make sure your admin user (user 1) has been granted the drupal role that you link to your group admin role! by default, user 1 does not have any roles.

God mode accounts have no place in proper access control code and Group follows that idea.

@kristiaanvandeneynde I can understand why an 'administrator' role might not automatically get these permissions, but saying that 'god mode' accounts are bad ignores the idea behind a root user. Of course, no-one recommends operating a computer as root, but there always is a root account for which the administrator of the computer always has access. user/1 has always been root in Drupal, for as long as I've used it (since ~2005, and while I definitely support your "read the manual" response, I think it's also reasonable that your average Drupal Administrator would expect user/1 to always have access to every entity and every operation on the whole site. I don't think user/1 should have any restrictions whatsoever. user/1 should always bypass every restriction every time.

I'm hoping this comes across as a very forceful but respectful disagreement.

I shouldn't have to do anything to allow user/1 administrative access to every group, but I do understand why there isn't a default way to give an administrative role administrative access to every group by default. I hope you will consider this argument as an more specific request than maybe the one in the original issue.

Including information about this in a README.md would make sense, so I have added it in the 📌 Adding README.md file Needs review issue.

This has to go into the documentation.
In order to have the site admin permissions as in Group 1.0, do the following:
1. Create a group role "Site Administrator"
2. Scope: Insider
3. Global role: Administrator
4. Check "Admin role"

This role should sync with the site role "Administrator".

@JordiK Thank you for providing simple instructions on how to recreate the version 1's sitewide administrator permissions. Despite having read the release notes multiple times, this change was not clearly explained in my opinion (e.g. it wasn't obvious to me that the new group roles could be auto assigned to users with a specific sitewide role.)

Anyway, I just wanted to point out that to fully recreate version 1's sitewide administrator access to all groups, you need to create two new roles: an "insider" one like you mentioned, and a corresponding one with scope set to "outsider". That way a user with the sitewide administrator role will have admin access to any group, regardless of whether they're a member of it or not.

Posting snippets from the 2.0.0 release notes.

Despite having read the release notes multiple times, this change was not clearly explained in my opinion

Sponsored by Factorial → : Video series on how to use the module

My employer was kind enough to sponsor an instructional video series on how to use the new versions of the Group module. You can find the series on our YouTube channel and more videos will be added over time.

(It's all explained in a lot of detail in those videos)

(e.g. it wasn't obvious to me that the new group roles could be auto assigned to users with a specific sitewide role.)

Roles and their UI have been reworked

No more advanced outsider roles or any of that nonsense. You can now define one of three roles:

• You have a specific global role and are not a member of the group: Outsider
• You have a specific global role and are a member of the group: Insider
• You are a member of a group and want extra permissions on top of the above: Individual

Anyway, I just wanted to point out that to fully recreate version 1's sitewide administrator...

All explained in the video series that were mentioned in the release notes. Furthermore there's these change records (and others like it):

• Access bypass permission has been removed →
• Administer group permission removed, group roles have an admin flag now →

It may not have been spoonfed to you how these roles have changed, but come on people. I went through the trouble or writing up release notes, change records and even recorder a video series where I go in full detail on all of this. What more can I do here?

I certainly appreciate all of your work on this module. Now that I understand the change, I can see that all of the information was there, albeit spread across release notes, change records, and videos. But for someone trying to understand this for the first time, it's difficult to have to go to multiple sources to glean little tibits of information and successfully assemble all of the puzzle pieces together in order to form a complete mental understanding.

I can only speak for myself, but since you asked, an explanation like the following in the release notes would have been easier for me to understand:

Roles and their UI have been reworked

No more advanced outsider roles or any of that nonsense. You can now define one of three roles:

• Outsider: This group role is automatically assigned to all users who are not a member of the group and have a specific global role.
• Insider: This group role is automatically assigned to all users who are a member of the group and have a specific global role.
• Individual: This group role can be manually assigned to a specific group member to give them extra permissions on top of the above.

For example, in order to give all group members admin permissions if they have the global role "Site administrator", do the following:

1. Create a group role "Site Administrator"
2. Scope: Insider
3. Global role: Administrator
4. Check "Admin role"

This group role will now sync with the site role "Site administrator".

This particular change is dramatically different from how permissions work everywhere else in Drupal. I feel like I understand your arguments for why you (and others) feel this is the appropriate way to handle permissions in Drupal, but it's very confusing (even for experienced Drupalers) because we expect User 1 to have all permissions everywhere regardless. In this case, that's a faulty assumption, but I haven't come across another contributed module in Drupal that handles administrative (lower-case A) permissions in this way. I don't mean to argue one way or another, but rather explain why this particular issue seems to be causing more grief to you and others.

Also from the group type edit form:

I think this is rather clear, no?

And part of my mission for 2024 is to actually move UID1's special privileges behind a setting that is off by default for D11. Will be easy once we land Access Policy API in core.

As someone upgrading from Groups 1 to 2 I hadn't actually seen this text until just now, so although it's helpful to new users, it doesn't really help users who are migrating and have already created their groups under a previous version of the module. Regardless, it is reasonably clear to me, but I think it could still be improved a little. Here's my suggested version:

Please note that Drupal accounts, including user 1, do not have access to any groups unless configured so. It is therefore important that you at the very least do one of the following:

• Assign the group creator a role below and set some permissions on that role. You can edit this group type at any time to set more creator roles, but this won't affect previously created groups.
• Allow certain global roles to automatically get some group permissions via Outsider or Insider group roles.

Optionally, you can set a role (whether the group creator's role or an Outsider/Insider role) as an admin role if you want that role to have all permissions for the group. If your use case does not require the group creator to be an admin of the group, then it is strongly advised to at least create an Outsider and/or Insider group role that synchronizes with whatever administrator global role you have configured.

* Note that the word "administrator" is currently misspelled in your last sentence.

• Re #15 updated the release notes.
• Re #18 fixed that typo recently, the other suggestions require a dedicated issue so we can create a merge request. Closed issues are not the right place for that.

My "other suggestions" in #18 were in direct response to your question in #17 "I think this is rather clear, no?". So I'm confused as to why you think this was not the right place for that response... Obviously you can do whatever you want with my feedback--take it or leave it, create a new issue for it, incorporate it into a future release, etc. But if you'd prefer not to receive feedback in a closed issue, then maybe best not to ask for it there. :)

Closed issues are not the right place for new merge requests. I think you misread my message?