🇩🇪Germany @kmetz

Also when calling getParent() on an unsaved subgroup - getParent() does call wrapLeaf() indirectly via isRoot(), and directly afterwards, in which case a MalformedLeafException should maybe be catched as well?

Unsure, since the unsaved subgroup technically does (or a bit later will) have a parent, but all of subgroup_depth / subgroup_left / subgroup_right / subgroup_tree are empty at the point of checking for a parent group.

I'm now use a workaround, by catching InvalidLeafException | MalformedLeafException when I check for parents of (potenitally) unsaved (isNew() === true) groups, which I know can be ignored in my special case.

I've encountered this issue when I called isRoot() on a not-yet saved subgroup (during insert).

I think that isRoot() should catch MalformedLeafException and return FALSE, same as isLeaf() does when it calls wrapLeaf().

Both methods for reference:

  /**
   * {@inheritdoc}
   */
  public function isLeaf(EntityInterface $entity) {
    $this->verify($entity);

    try {
      $this->wrapLeaf($entity);
    }
    catch (MalformedLeafException $e) {
      return FALSE;
    }

    return TRUE;
  }

  /**
   * {@inheritdoc}
   */
  public function isRoot(EntityInterface $entity) {
    $this->verify($entity);
    return $this->wrapLeaf($entity)->getDepth() === 0;
  }

I found a small bug in GroupPermissionChecker.php (see my gitlab comment, https://git.drupalcode.org/issue/group_permissions-3327680/-/commit/7981...). Fixing it, it looks very good so far, permissions seem to resolve correctly per-group.

Another thing that doesn't yet work is the "view group" permission in a list (like a view, or other access-controlled query result) of groups. The group type (bundle) level permission works as expected, that's implemented in \Drupal\group\QueryAccess\EntityQueryAlter. Is Not sure if there is an easy solution at hand for query altering, I couldn't look very deep into it yet. Is that a regression, or a separate issue? Anyways, a release without that fixed should make sense (it can be worked around somewhat, for example by disabling query altering in a view and filtering results directly in the view).

Thank you, appreciating the progress very much.

In 1f16f22d, a service class seems to be missing so I couldn't test it: Drupal\group_permissions\Access\GroupPermissionChecker (group_permissions.checker)