- Issue created by @Berdir
Spin-off from 🐛 Optimize CacheContextsManager:::convertTokensToKeys()/optimizeTokens() Active
In its current form, \Drupal\group\Access\GroupPermissionChecker::hasPermissionInGroup() will always only use 1-2 sets of permissions, but we always prepare all 3.
There is possibly an argument that calling all upfront and collecting the necessary cache contexts requires fewer redirects and updates in that regard, but per the core issue, the variation static cache is fairly expensive at the moment. It would be different if it would be a single lookup, then it might make less of a difference.
Special case for anonymous users, where we also always prepare all 3 but we know that it's definitely going to be outsider. We also check for the membership, which could be skipped either here or within the membership loader.
This is a bit tricky, because I don't see a way to do that without essentially completely dropping \Drupal\group\Access\GroupPermissionCalculatorInterface().
That might not be bad on its own, because the current approach seems to me as a mostly outsider-person a bit too abstracted. It's a separate service and interface, but there can't really be a different implementation, \Drupal\group\Access\GroupPermissionChecker::hasPermissionInGroup(). expects exactly those 3 scopes, it won't look at anything else.
So this might be tricky for BC if someone really customized that, but ignoring that, I think it would basically mean to inject flexible_permissions.chain_calculator directly instead of group_permission.calculator and instead of getting the item from the aggregated full permission thing, we'd calculate the scope we're interested in for each step and get it from that.
Active
3.3
Code