403 error if you use VBO in group related views

#34 works ok for me.

It's the equal to #34 patch, but without a warning.

https://www.drupal.org/files/issues/2023-03-07/3020883-35.patch →

Adjusted Patch:
If group can neither be resolved by path nor by context, it is fetched by views argument if the argument is of plugin "group_id".
Caveat: If there are multiple group arguments, this would only check for the last. In that case the other solutions might have already gotten a valid group.

Hi all, facing the same problem, is there a patch on D10

Hello, community!
Have the same issue, any updates?

Cross-posting from #group on Drupal Slack:

If you create a MR against 3.3.x and add a test to prove this works, I can accept it. I'm seeing a few potential scenarios in that patch so all of these cases should ideally be proven to work.

Caveat: If there are multiple group arguments, this would only check for the last.

The first loop breaks on first occurence found, the second loop uses the last occurence found. Please make this consistent, probably by making the second loop "break" when something is found.

Okay before any work is done, I'm seeing an opportunity to fix this without having unpredictable loop results in Group.

Currently we have:

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    return new static(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $container->get('group.permissions'),
      $container->get('extension.list.module'),
      $container->get('group.group_route_context') <---- This is bad m'kay?
    );
  }

What if we change the configuration form to allow you to choose a context provider and make it default to group.group_route_context to preserve BC? This way, you can make your own context provider that either gets the group from the view args or from whatever else you can think of. It would also instantly make this work with the Group Sites module.

The only question is whether you can reliably get a view object from a route, i.e.: Answer the question whether the route represents a view and, if so, which view that is. If you can do that, then the solution above would be far superior than the current patch.

You can find an example of a form element asking for a context provider in the Group Sites module: https://git.drupalcode.org/project/group_sites/-/blob/1.0.x/src/Form/Gro...

Moving this to VBO, needs quite some refactoring but It'll be a big step forward for VBO so definitely worth an effort.

This is big unfortunately and will need a (sub) major release. No BC issues expected though.

We need to get back to the primary solution unfortunately - the "great improvement" will make VBO useless on block displays, those dedicated routes were needed.

@Kristiaan, general thoughts: context - based access is something that should be avoided as it creates ways to bypass restrictions - an individual either has access or doesn't and not maybe has and maybe not, so site builders can accidentally leave some doors open and create security issues. Also, it seems bad that group prevents access to routes without group context as usually in cases outside of some module scope neutral would be returned. Can we just return TRUE if no context is available?

Graber → closed merge request !83

That basically ;)

I agree with @graber, Patch #51 "ignores" the group permission when the group is not in context. Modules like VBO has to provide group context on their own if they want to provide group permissions.