[buddypress-trac] [BuddyPress Trac] #5911: Improve user feedback in Group's invite screen.

[buddypress-trac]

#5911: Improve user feedback in Group's invite screen.
-------------------------+------------------
 Reporter:  imath        |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  2.2
Component:  Theme        |     Version:  2.0
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------

Comment (by imath):

 Sorry Boone, i'm hesitating, because i'm not sure i understand well :)

 > Have we recorded an unsent, unconfirmed invitation from the logged-in
 user? If so, make sure there's an <li> for the user
 1/ That's what's built-in so far, i think. Am i correct ?

 > Are there any other invites/requests in the system for this user that
 predate our unsent invite? If so, add a message to the template: "Sending
 an invitation to this user will automatically..."
 2/ The user you are talking about is the one the logged in user is trying
 to invite, right ?

 > Have we just unchecked a box? If so, be sure only to delete the
 invitation in the system that has the logged-in user as the inviter, *not*
 all invitations. (And if we have logic that prevents ore than one
 invitation from being sent to a single user for a given group, we should
 remove it - there's no reason I can think of why it shouldn't be possible
 for someone to receive more than one invite to a group from different
 people.)
 3/ '''*not* all invitations''' I'm not sure to get it. I'm understanding
 that in {{{wp_bp_groups_members}}} there could be more than one row for a
 group id / user_id, one row for each inviter_id.

 I think point 2/ would need an information about the checkboxes clicked to
 be sure to activate the right ones for the current group > meaning JS, i
 guess we could deal with this by storing data ( eg: group_id => array(list
 of ids clicked)) in {{{bp-invite-extras}}} cookie for instance and
 eventually use the ajax querystring filter to transport this data.

 But point 3/ is making me think that you suggest to use 1 specific row for
 each inviter, which would resolve the problem of the checked checkbox and
 {{{<li>}}} elements displayed, i've just tested by commenting the
 {{{groups_check_user_has_invite()}}} in the function
 {{{groups_invite_user()}}}. In this case, all inviters have the checkbox
 and li element in the group's invite screen and the invited user only has
 1 notification. Before the user accepts it the {{{wp_bp_groups_members}}}
 table looks like this :
 ||= id =||= group_id =||= user_id =||= inviter_id =||
 || 51 || 10 || '''2''' || 1 ||
 || 53 || 10 || '''2''' || 3 ||
 After he has accepted the invite, it looks like this
 ||= id =||= group_id =||= user_id =||= inviter_id =||= ... =||=
 is_confirmed =||= is_banned =||= invite_sent
 || 51 || 10 || 2 || 0 || ... || 1 || 0 || 1 ||
 || 53 || 10 || 2 || 3 || ... || 0 || 0 || 0 ||
 || 54 || 10 || 2 || 3 || ... || 0 || 0 || 0 ||
 || 56 || 10 || 2 || 1 || ... || 0 || 0 || 0 ||

 The group members count is ok, but each inviter keeps the invited li
 element in the group's invite screen. So i guess we could delete where
 is_confirmed != 1 once the user accepted the invite to solve this

 But then, we would need to revisit {{{groups_uninvite_user()}}} function
 as it's a simple alias to the BP_Groups_Member::delete() method.
 Apparently removing an invite is the same as removing a member from the
 group.

 In my example 2 invites for the same user generates 3 extra rows, so i
 guess it can be exponential with the number of invites a user can receive
 :)

 Suddenly i have a doubt! Maybe i completely misunderstood your comment. Is
 it the case ?

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5911#comment:4>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac