hasPermissionInGroup - either in or out.

@matslats I think the proper solution is to create new 'insider' admin role and give it the permissions you gave for the 'outsider' admin role. Besides fixing your issue, this will also be helpful in case someone would like to give more permissions to users who on longer outsider but become insider (member).

Do you mean to create an insider AND outsider admin role?
The problem is admins may or may not be inside the group.
I can do this but creating an admin role for each case doesn't feel like a 'proper' solution.

@matslats Yes, you should create insider and outsider role...
This is good for cases like the one mentioned in #3

I've just upgraded from groups v1 to v2, and I hit the same problem, which puzzled me for a while. The issue is also discussed in 💬 Sitewide Administrator permissions not working Closed: works as designed , which is closed as "works as designed".

@matslats, what I think you're asking for is an option to choose "Outsider or Insider" as the group option when adding a group role. This would save developers from having to create two separate roles. So, this is a feature request rather than a bug report. I've updated the Category.

I've only recently updated my project to from 8.1.x to 2.x and ran into the same problem.
At first I wanted to patch the same lines so it does the same thing as the outsider_in module use to do. I get that the new solution is a lot more flexible, but sometimes you just want a global role to work the same for an insider and an outsider.

Creating two group roles that sync wit a global role work, but it would be great if the was an option to set a role to outsider AND Insider.

This is covered in the video series that was linked in the 2.0.0 release notes. You need to set up an insider and outsider role for admins now, because in some cases people only want one but not the other and for those cases it's an optimization to not have useless roles.

I've given combined scopes a thought int he past and couldn't resolve it nicely, but with 4.x.x we might get a second shot at this. Either way, marking this as a resolved support request as it's already been explained above why it's behaving like this.

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