Sitewide Administrator permissions not working

This bug is a "full stop" unusable module that has completely hampered development. Thank you for prompt attention or any input you can provide.

I can confirm this. I was trying out the Group module the other day, and was surprised to see that my admin user (/user/1) was locked out of newly created groups, and couldn't list nor edit or delete them. I also couldn't uninstall the module, since it had content.

I assume this is a bug, since in my opinion, users with the administrator role should always have full access to "everything" in a Drupal installation, including editing and deleting groups in the Group module.

I have updated the Issue Summary with the steps required to reproduce the bug. I agree it is critical. It also happens with 3.x-dev, so upping the version.

I think this is related to having removed the bypass group access permission.
I don't understand why this permission had to be removed, but right now site admin or user 1 doesn't have full access of those groups.

Closing.

@everyone Please read the release notes, especially the part about reworked roles: "Roles and their UI have been reworked". You'll find that if you create a group role that syncs with the global admin role, all will be fine. I am having trouble grasping that people would truly think I would remove a commonly used feature and not have an alternative in place.

@markfien please read the issue guidelines. This issue is far from critical, it's simply due to people not checking out new features. If that "completely hampers your development", you should probably take a closer look at your development process.

I assume this is a bug, since in my opinion, users with the administrator role should always have full access to "everything" in a Drupal installation

Not in Group. God mode accounts have no place in proper access control code and Group follows that idea. Hence all the effort I poured into #540008: Add a container parameter that can remove the special behavior of UID#1. As mentioned above, you can configure this to be true, but then that's a deliberate action on your end rather than something Group does out of the box. God mode accounts are Bad™.

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.

@kristiaanvandeneynde I just reread your comment and noticed the issue about removing special permissions for user/1. I would delete this comment if I could, but it sounds like you're already aware of people's expectations around user/1 and are against it. Since this issue is not the place to have that discussion, please accept my apology for not reading thoroughly. Previous comments are unnecessary considering your efforts on that issue.

Including information about this in a README.md would make sense, so I have added it in the #2878723: Adding README.md file 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 recorded 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?