invites.php should query the displaued user not the logged in users invites

[shawfactor]

invites.php in nouveau currenty queries bp_has_groups( 'type=invites&user_id=' . bp_loggedin_user_id() ) and shows the current users invites regardless if the context. This is incorrect the template should query the diaplayed users invites. The current setup is inconsistent with other profile screens

Trac ticket: ​https://buddypress.trac.wordpress.org/ticket/8675

[oztaser]

Hi there,

Member navigation items access based on bp_core_can_edit_settings(). If we want to keep this access control, I agree. We need to fetch invites by using bp_displayed_user_id for Nouveau and Legacy template packs.

I also think we need to show the Groups subnav.

[imath]

Hi @oztaser

Thanks a lot for your patch, could we elaborate the issue because I'm not sure to understand what's wrong and why we should do things differently (it's probably an english to french trouble for me :) ).

@dcavins since you've been working into this area, could you also bring your voice here?

[oztaser]

Hi @imath,

The problem occurs in /members/someuser/groups/invites/ page. We give view access to users who can edit settings but we show them their group invites not displayed user's. To see more detail you can look BP_Groups_Component class and see how we setup navigations.

To reproduce:

• logged-in as an admin user
• send group invite to some random user
• go it's group invites page (/members/someuser/groups/invites/), you'll see the page and maybe some invites but its your invites not displayed user.

Before the patch: ​https://imgur.com/huuoLXI
After the patch: ​https://imgur.com/IZTYmU2

I hope this helps :)

[imath]

Awesome 👍. Thanks a lot I got it. I’ll look at it asap 👌

[dcavins]

I believe this used to be done as "security" so that a user couldn't view another user's group invitations (there used to be several instances like this in the member profile, if I'm remembering correctly). But, I agree, it's wrong, and the right behavior is to show the invites belonging to the profile that's being viewed, AND preventing access to that screen unless the logged-in user is the displayed user or can bp_moderate. The legacy template pack relies on the behavior of bp_has_member_invitations() ​https://github.com/buddypress/buddypress/blob/ce0b69c4c8b2b27fd1b78ebd02f2145a209cef53/src/bp-members/bp-members-template.php#L3126 which will show the displayed user when set. Should Nouveau just use that function instead?

Thanks!

[imath]

Thanks a lot @dcavins for your feedback, both template packs are using bp_has_members_invitations() to list site invites. But for Groups, we are using a Groups loop (bp_has_groups()) in Nouveau as well as in Legacy.

[imath]

As explained in a review to @oztaser 's PR: ​https://github.com/buddypress/buddypress/pull/15#pullrequestreview-937082276

I understand why we were doing so, if an admin accepts the invite it generates some errors on both template packs.

We'd first need to work on:

• groups_action_join_group()
• bp_nouveau_ajax_joinleave_group()

In these functions we are using bp_logged_in_user_id()...

More globally I'm wondering, if we were to go this way if we should also generate an email to inform the user the Admin accepted the Group invites on behalf of the user. Deciding for a user is always a concern for me.

Hey @imath, thanks for the review. Actually I've never tried to use Accept/Reject buttons, I'll look asap.

Hi again @imath,

I believe accept/reject buttons should work for admins after my last commits. Can you look again?

I also agree about your concern to inform users but I'm not sure where to generate it.

Hi again @imath,

I've added an email notification based on your suggestion.
I have two questions:
1-) Should we create a new email or just use existing ones?
2-) Should we add unsubscribe link to email or we always inform users after that action?

Thanks a lot @adiloztaser for these improvements.

I think we should have two specific emails eg: "An administrator accepted an invitation to join {{group.name}} on your behalf. If you disagree with this, you can leave the group at anytime using this link: leave-group.url

In this case we don't need the unsubscribe link.

The new code you added looks great.

Thank you for feedback @imath, I'll keep working on it.

Hi there.

I've added new emails, as you guess to do that I needed to increase the db_version. I don't know is there any rule for this, if I did anything please let me know.

I couldn't add leave url to accepted invate email because we have nonce check and I didn't create a valid url. I've added member groups page, I think it's good enough for navigating user.

Thank you for review and suggestions @imath. I hope its ready to go.

[imath]

Just ran some ultimate tests with the BP REST API, everything is good to go.

[imath]

In 13273:

List the displayed user groups invites in member's front-end screen

As a site admin can view the displayed user groups invites, listed invites have to be the one of this user and not the ones of the site admin.

Adapt the Group Invites feature so that site admins can accept or reject on behalf of the displayed user the listed invites. These two actions made by an admin will generate a specific BP Email informing the user of it.

Props oztaser, dcavins, espellcaste

Closes ​https://github.com/buddypress/buddypress/pull/15
Fixes #8675