Calculator returns roles other than individual

Sorry I figured it out by making a new role rather than assigning it to an existing one. I still attached it to the admin role for anyone else who experiences this same error.

I'm a clown, I'll leave this open for you to close at your leisure. I'm unsure of the preferred method for a question that isn't a question anymore.

This is what "Works as designed" is for.

I'm not sure this "works as designed". I am getting the same error in a pretty simple scenario and I'm not sure what @Chompp means by "I figured it out by making a new role rather than assigning it to an existing one."

I have a mostly fresh D10 site with Group 3.1.0 and Flexible Permissions 1.0.0.

I have a Drupal role that maps to a Group type role with Scope=Outsider and the "Admin role" checkbox unchecked on the group role Edit page.

The only Drupal permissions I have given the corresponding Drupal role are "Use the toolbar", "Access the Content overview page", and to create nodes of a single content type.

When I login with a user who has the role, and try to access admin/content, I get the same error mentioned above. The only way I can avoid the error is by setting the Group role's "Scope" to "insider".

-mike

I noticed you got help on Slack, please reopen if the issue persists. But it seems like there was some confusion about insider vs outsider. Please also take some time to watch the video series that were launched alongside Group v2/3, they contain a lot of useful info on the new features.

If you're here and have no idea where to find the video series he's talking about, here it goes: https://www.youtube.com/playlist?list=PLWsDPX910IWxhowXYlXDrSG_A5H7_shv5

Having same problem, I'll check the videos, but can we post the solution within the issue queue, or even a link to the slack?

(This problem for us is immergent in the middle of or d10 upgrade, where we didn't have it in there last week)

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

I'm getting the exact same behaviour as mentioned above. Have watched the videos but obviously the creator of the video does not run into this bug. I'm not assigning anything by code, just created a role as outsider according to the video instructions and the error pops up. Not sure hat to do next.
It would be beneficial if there's a solution out there (e.g. on slack) to post it back here.

Deleting and re-creating the group admin role fixed this error for me.

we are facing the same issue, we didn't assign any role by code. it's simply an issue if we have an outside role assigned to more than 1 Drupal role. It throws an error message:

Drupal\flexible_permissions\CalculatedPermissionsScopeException: The calculator "Drupal\group\Access\IndividualGroupPermissionCalculator" returned permissions for scopes other than "individual". in Drupal\flexible_permissions\ChainPermissionCalculator->calculatePermissions() (line 145 of /code/web/modules/contrib/flexible_permissions/src/ChainPermissionCalculator.php).

The workaround I can think of is to write a script to make people members of all the groups so they can see the groups even when they are not administrator.

Please open a new issue with steps to reproduce on a clean install. This issue has been closed 8 months ago.

if we have an outside role assigned to more than 1 Drupal role

Did you do this through code because that's unintended and the UI doesn't allow that.

The workaround I can think of is to write a script to make people members of all the groups so they can see the groups even when they are not administrator.

That would completely kill your site's performance

For me deleting and recreating the role did the trick

Getting this error as well as part of a Drupal 2.x upgrade.

No steps to reproduce, it would be unreasonable for us to do so as well given the size and complexity of our site.

Still, there's something amiss here in the upgrade.

I fell into this issue after these steps:

1. I have created a group type
2. I have created a group based on that type
3. I created a group role "User moderator" as an invidual role
4. I assigned various group permissions to this role (I assume also "individual" permissions)
5. I added members to the group
6. I created a Drupal role "User moderator" to combine this role with the group one (specs changed so I found out I also need this on Drupal level too)
7. I edited the group role and set it as "Insider" combined with the Drupal role
8. When vising /admin/group this error occurred

After all these steps, when I try to reach /admin/group I get the following:

Drupal\flexible_permissions\CalculatedPermissionsScopeException: The calculator "Drupal\group\Access\IndividualGroupPermissionCalculator" returned permissions for scopes other than "individual". in Drupal\flexible_permissions\ChainPermissionCalculator->calculatePermissions() (line 145 of modules/contrib/flexible_permissions/src/ChainPermissionCalculator.php).

Drupal\group\Access\GroupPermissionCalculator->calculateFullPermissions() (Line: 40)
Drupal\group\QueryAccess\GroupQueryAlter->doAlter() (Line: 150)
Drupal\group\QueryAccess\QueryAlterBase->alter() (Line: 336)
group_query_entity_query_alter() (Line: 552)

Thanks for the detailed report, now I have something to investigate (changing of scope on existing role)

@vensires I narrowed it down to the fact that changing a group role from individual to insider/outsider does not remove said role from existing memberships' "Group roles" field. That's what is causing the error. I'll see if I can come up with a sensible way of fixing this.

Okay so I see two fixes:

1. We run a script when role scope changes from individual to anything else to remove this role from all memberships
2. We scan for this role on memberships and reject the save through a validation constraint

1. is destructive and potentially bad, 2. is annoying if you actually want 1. to happen.

Then there's door number three where we allow bad roles to be assigned, but ignore them in the calculator. But I'm really not a fan of allowing your data to be inconsistent with your code, so I'm very unlikely of accepting any such changes.

Currently erring on the side of 2, but maybe it's safer to do both. Write a service that mass revokes a role, then disallow the role change until you use said service to revoke the role. We could then use the same service to mass revoke roles when they get deleted.

At first, thank you for your immediate actions on trying to solve this!

As for the script to clear things up, you already have the if{} condition to check if that happens. I think that, if we remove this, the rest of the code plays fine. I don't say we should remove this but maybe this script you are mentioning should be executed instead of throwing this exception in this exact if{}.

So the persistent cache will have valid data in any case and at some point a cron or something getting triggered only when needed, will fix things up. That's my perception of the solution at least.

The fact that this throws an exception is good, otherwise it would have flown under the radar and caused security issues. Flexible Permissions (and therefore Access policy API) is right to crash loudly here, it's Group that is abusing the system by allowing us to change scopes without running a safety check first.

This needs to be fixed in Group.

Proof of concept posted, needs tests and we need a follow-up issue to:

• Delete all references when a group role is deleted
• Create a UI element for reference deletion so we can circumvent the constraint

Strange, seems I cannot push to the issue fork.
Here's a patch with that commit applied.

Right, I clicked that button and pushed. Thanks @vensires 🙂

Caught a bug in one of the new storage methods while writing tests for them. Gonna move the one you wrote into a dedicated class for the constraint next week.

All green, pushed another test but that went green locally, so committing in a few and writing a CR in the meantime.

Follow-up created here: 📌 Disallow the programmatic assignment of insider/outsider roles to members Active

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