Users without "View group invitations" can't see their invitations

I can confirm that I'm running a fresh install with group 3.0.0-beta3 and ginvite 4.0.0-alpha1. I expected to see invitations when I logged in as the invited user, but there are no invitations available.

The warning with "You have pending group invitations. Visit your profile to see them." does correctly appear, but when I click on it, I see "No invitations available."

Regarding who should 'own' the invite. I'm not so sure. For example the creator should be able to be given the permission to revoke the invitation, or edit it to add a role? While the invitee should (always?) be able to see the invite, but certainly not edit it to change the role.

So invitee being able to see an invite seems to be a bit different from the usual 'own' type permissions.

Thinking about it: having an 'accept invitation' permission which is just the entity access/route not the list entity query is the basic requirement. The creator of the invites is in addition to edit permissions, also more likely to need a list of 'invites made' with a view. So while it might be interesting to add a permissions handler to vary based on an invitee field it seems like overkill for what is actually needed.

@ekes, I see your point, but do you have any other ideas?

If I understand it correctly it would be possible to add the invitee to another field, when they are a user, and add full 'flexible permissions' access handling on that field too; but it would be a whole amount of work for not much gain I think.

Just extending the Group\RelationHandlerDefault\AccessControl for view to accept invitation for the invitee user should be enough, even if it might still deny access in views or other entity query lists? I can have a go.

Update

Looking at the code it is no problem to add a check on the account email and the invite email for viewing in the AccessControl plugin. It then means still making a list somewhere, without an entity query that gets altered, and moving the accept operation.

So is the other alternative to keep access false, but alter the view not to get groups access - or to add our own. [At which point implementing the flexible permissions... no that makes no sense for one specific view. Maybe best still just for our one view?]

@ekes thanks so much for looking into that. Do I understand correctly from the update in #10 that then we can still have a view of "All My Invitations"? Or would that end up needing to be a custom list?

we can still have a view of "All My Invitations"? Or would that end up needing to be a custom list?

Exactly. It would have to become a custom list, because unless you add permissions not only in the entity_access (easy in the AccessControl) but also so it changes the entity_query_alter that Group does, the views wont display the items.

So one more option: Make the view that packages with the module switch off query rewriting. This stops the access control from Group (it sadly would stop any other rewriting that other modules implement). Add a tag to the view query. Then use the views tag hook and here implement access control to only show invitations to the user with that email address.

It isn't doing anything that the custom list wouldn't. But that it bypasses other unknown modules rewrites does rather highlight the problem.

So we can give access to view the relation which could be used to be the place to accept the invitation; but it's not easy to make a safe list of invitations without going the full 'flexible permissions' implementation route which I just understand to be possible, but don't actually know exactly how you'd do this and if it really is possible.

Do we really need to show creator his/her own invitations

    $permissions['delete own invitations'] = [
      'title' => 'Delete own invitations',
      'description' => 'Allows users with permissions to delete own invitations to group.',
    ];

Yes if this is the current situation, or the desired situation. It allows a member, doesn't need to be an admin of a group, just a user, to retract an invitation they made and not be able to delete one that someone else made.

But I do see your point that it might be easier just making it group wide permissions. Which was why I initially went there too. So maybe it's still the best option.

For what it's worth to patch the hole for now this is what I did to the view with everything else as it stands:
Added a filter on the user email https://github.com/localgovdrupal/localgov_microsites_group/commit/33405... it gets the email from https://github.com/localgovdrupal/localgov_microsites_group/commit/33405... replaced with https://github.com/localgovdrupal/localgov_microsites_group/commit/33405...
So that only shows the invites to the email address of the {user} of /user/{user}/invitations. Then to get access and this is the bit I'd be reticent about putting everywhere by default https://github.com/localgovdrupal/localgov_microsites_group/commit/33405... query rewriting is off, but additionally the {user} is validated https://github.com/localgovdrupal/localgov_microsites_group/commit/33405... and the current account needs to be able to edit said {user} to get to the view.

@ekes I am trying to use your method of patching the hole for now, but where does "invitee_mail_value" come from? You said, "added a filter on the user email" so just add user email field to the view filter and set it to that value "***GINVITE_USER_EMAIL***" ?

@ekes, nvm I managed to get this working. When I was trying to add email as a filter, it was showing from the user category. I didn't realize if I searched "invitee" email it would show the field you were referring to. This workaround seems to be working for now but as you said disabling sql rewriting is not ideal. The group field seems to not be showing up, but other than that, I am able to accept the invitation now.

I am not familiar enough with this code to offer a suggestion, but sounds like you guys have some ideas already

This issue is not fixed. It seems that in "GroupInvitationPermissionProvider.php" we check for the "view group invitations" on a view operation. This permission never exists on an invitee since the invitee is not a member of the group yet. Therefore this user can never view its own invitations. Hence, any group permission will never work since the invitee is not a member of the group yet.

A workaround is to create a new Outsider role (non-admin) to the group, for example named "Non-member". This role is then based on the "Verified user" global role. In the group, on this role you can assign the "view group invitations" permission to.

Without a workaround I don't see a solution where we use a permission provider on group level. Because an invitee is always an outsider and therefore cannot have these permissions (unless we have the outsider role).

I don't think an outsider role is the way to go, especially when we have alot of group types and perhabs sub groups, you don't want to specifically add this outsider role to every group just because of this permission check.

@Lobster, yes the invitee is a registered user but not part of the group yet. So it will never have the permission "view group invitations".

You can test this by just inviting a user and then login as the user and go to /user/group-invitations. You will not see the invitation there. The workaround makes them visible but I don't think this workaround should be the fix for this issue.

In my opinion this permission "view group invitations" is for group admins to see all invitations of a group at /group/%group/invitations. This makes sense to put this permission in the group structure. However, a user viewing its own invitations should not depend on this permission. Because its not part of the group yet. I think in the access check you want to skip this permission when the invitee id === current user id.