Keep track of group invitations

i have wanted such a table for a while. josh koenig was recently looking into this too so perhaps one of you will submit a patch ... As for an url being insecure, thats news to me. Please send me private email with specifics on how to reproduce.

Yes, Josh and I are working together on this, so there should be some patches coming.

So I changed the title to better reflect the issue. I didn't intend to give the impression that there was a drupal security risk or anything, just that the og/subscribe/$gid link behaves in a way I don't quite understand.

Moderated: User can request subscription to a group, and must be approved.
Invite-Only: Administrators send an email that points user to a page where they request approval, and then the administrator has to approve them. So really the invite only case is the same as moderated except it sends out an email with the moderated link, instead of showing the link.

I suppose the behavior I expected was that if someone was invited to a group, they are considered already approved and so the link sent to them in the email should a) automatically subscribe them to the group without approval and b) be unique to that user. I wrongly assumed that og/subscribe/$gid defaulted to subscribe without approval, instead of moderated as it does.

We are working on trying to open up the invite.module to support this type of action by OG.

Farsheed

thanks for the elaboration. the difference between those two types of groups has nothing to do with invites. in moderated, any user may request admission to the group. in invite-only other, you must be invited by someone (i.e. there is no subscribe link). invite only resembles some of the uppity country clubs around here.

i'm very open to changes to invitations, and look forward to your patches.

As for invite, perhaps lets use job_queue.module as inspiration. That module is a simple table of wth two columns - function name and arguments. arguments holds a serialized array. The idea is that upon accepting an invitation, invite module should invoke any registered functions+arguments. So this would work for og_subscribe_user() and and other modules that want to react to invitations ... If this sounds complicated, just use an invite hook.

I'm working on a module to do this, to be called og_invite, based heavily on the "invite" module (but not close enough to justify just opening up invite to use it directly). It will also replace the entire group invite page. Because of the requirements for the site I'm working on, it will also have the ability to auto-approve invitees the first time they visit the group if they were invited by a group admin.

It's not ready at the moment, but I remembered this thread and thought I'd bump it and mention what I'm working on while I'm at it.

Thanks for the update, Devin. If this makes more sense as a patch to og, I would consider that.

@All - there is a new release candidate (http://drupal.org/node/180858). Please report back any problems.

would be great if someone could share the code. just attach it here it if it isn't pretty enough to be a formal contrib module.

I'm getting ready to write a plugin for the invite module that asks which group (out of the user's list of subscribed groups) should be attached to an invite. I need to use the invite module because I need its User Relationships integration as well. If nobody has done this yet, then I will be happy to upload my module once it's finished. If someone has already done this, no need to reinvent the wheel. :) It looked like Devin's module didn't use the invite API though. Is that right? My implementation will be very similar to what User Relationships does now (user_relationships_invites.module).

I've got a basic version of this module working now. The only problem is that it doesn't work for inviting current users to the group, only for inviting new users to the group because of how the invite module works.

hi - Post Carbon Institute has been funding enhancements to og_reg_codes and and groups aware extension to the user_import module. Reg codes is working with private groups, and takes over all of ogs current invite notifications. Redeeming the codes is almost transparent, and could easily be switched to be unique per invite, rather than per group, which would let us track the redemption of the invites

happy to share, and lets get the invites process working better

@vaelen: feel like sharing? ;)

I need this feature to work with invite.module - and if it only works for new users that's fine with me!

This might not be the thread for this but it's related enough: What i have in mind is an automated user->group process. On the intranet i'm working on, all groups are actually clients (rarely with more then one user ("client" role) and a manager ("agent" role)). Since i found no use in Invite only groups, all groups are closed, and I use the invite.module to invite new clients (automatic role assigning is another issue) and manually create a new group and then manually assign that user (only after they register) to that group.

I'd like to change this process into something like: When an "agent" invites a new user, a new group is automatically created, set with that agent as it's manager, and once the invited user registers they will automatically be a member of that group.

Other ways to get this done:
1) possibly the other way around: when a user registers to the site a group is created, but then the problem is setting the correct group manager, who should be the user who invited that user, this is the closest i got).
2) possibly have a user first create a group, then add an "Invite to group:" field on the invitation page for selecting which group this user should be invited to. Seems this is what this thread is about. This adds another step, but seems much more logic & generic. these 2-step process could be combined using pagerouth.module.
3) Anyone...?

subscribing...

happy to share, and lets get the invites process working better

I would love to get this going. It makes sense to me to have the joining of the invite-only groups be taken care of by having a group admin send the user an invite with a special code, which they can then use to join the group. (Or have the user tagged as "invited", and when they come to the join URL, give them access).

This is a standard feature of most social networking websites like Flickr.

Is the code available somewhere?

Thanks,
Andrey.

Something close would be the og_user_roles registration codes feature (info here).

Working patch for 6.x-2.x, to be reviewed. It also contains some minor bugfixes I uncovered along the way.
1) Adds missing ability to set existing og_email_max variable in settings.
2) Adds form validate/error for self entered username (in addition to self email)
3) Adds missing break in og_user hook 'register' case

Features:
1) Adds new table og_invite, to store email/gid for future members.
2) New Users, on registration, will be auto-added to groups they were (pre)invited to join by admins. Normal user invitations function as before.
3) Silently adds existing users (just like current add_user behavior) to group if invited by admin, rather than sends an invite email to them.
-- Should this be optional/avoided for open or moderated groups? For moderated groups, does it make sense to invite, then still have to approve if they do join?
4) Invite link now appears for group admin for all groups, not just open and moderated ones.
-- Invite Only groups still won't allow normal users to invite, yet.
-- Potentially, a new group type/permission/setting (Need Invite by Any Existing Member) might be needed to offer all possible cases.
5) Recommends using invite form (for added email recognition) in help text for add user form.
-- reduce overlap and have just one form?

Feedback very welcome... I'd like to see this functionality get accepted for 6.x-2.0 final.

I'll be backporting to D5 next week.

Hi Seth, I applied the patch but noticed that it didn't automagically create og_invite table for me?
Does og.install do this or do you need to an update_60xx() or something?

Additionally - I've got an event that adds a role when a user joins a group.

I suggest adding

rules_invoke_event('og_user_approved', $account->uid, $gid);

in og_user() below og_save_subscription() to trigger event

Good catch on the need for an update. (I was using a fresh install during my coding/testing, and forgot about that...)
I'll add that in, and reroll.

As for the rules_invoke_event, in og_save_subscription, it already calls as follows:

It looks like you need to use the event rule for og_user_insert, because the 'og_user_approved' rule doesn't cover new users who aren't already in the group and are newly added.

If we do need to add a call for a rules_invoke_event for og_user_approved, that seems like it's better done in the hook_og (ie an user_insert should also trigger an user_approved event in some cases?), rather do it in hook_user directly as a workaround. Is this the only place where og_save_subscription gets used that will not call user_approved? I don't think so.

Moshe?

Some feedback just on the writeup in #17:

BUGFIX
1) - lets keep this hidded to avoid pref bloat.

FEATURES
3) This is a bit of a mess with all the different use cases.
4) "Potentially, a new group type/permission/setting (Need Invite by Any Existing Member) might be needed to offer all possible cases.". Yes, that is probably needed. I have no thoughts right now on how to implement exactly. MY first thought is that this is a 'per group setting', not a new group type.
5) I would love to merge these if possible.

I also want this in 6--2 final. i will do a code review soon.

I have no clue about rules integration. i'll give it some more attention.

I had to commit some lingering patches in the queue and now this has a few broken hunks. Could you please reroll and incorporate recent follow-ups? Thanks for working on this.

I'll reroll this (with an install/update hook and some of the followup) this weekend.

subscribe

3) Silently adds existing users (just like current add_user behavior) to group if invited by admin, rather than sends an invite email to them.
-- Should this be optional/avoided for open or moderated groups? For moderated groups, does it make sense to invite, then still have to approve if they do join?

Moshe - 3) This is a bit of a mess with all the different use cases.

4) Invite link now appears for group admin for all groups, not just open and moderated ones.
-- Invite Only groups still won't allow normal users to invite, yet.
-- Potentially, a new group type/permission/setting (Need Invite by Any Existing Member) might be needed to offer all possible cases.

Moshe - Yes, that is probably needed. I have no thoughts right now on how to implement exactly. MY first thought is that this is a 'per group setting', not a new group type.

5) Recommends using invite form (for added email recognition) in help text for add user form.
-- reduce overlap and have just one form?

Moshe - I would love to merge these if possible.

Ok, thinking this through before I code it up... as you said, the use cases are a bit confusing.

If a new group setting is added, that adds a new column to the og_table, likely a tiny int (similar to og_register). Lets call it og_memberadd. This setting would allow normal members to _add_ new members to the group, without admin approval. This will need to be added to the schema, an update, the devel_generate function, and potentially any other code that creates new group nodes. We'll default to FALSE, so this new functionality is off unless explicitly turned on.

The add and invite form can now be merged into one form in code (two urls and menu items still, to maintain backward compat with all OG modules that might refer to them, og_views for example)

If og_memberadd (or og_is_admin) is true, (and the group is Open or Moderated) the form gets an added select dropdown (radio?) "Add Users" or "Invite Users". (The add_user url will default to one, the invite url will default to the other). If it's Invite Only or Closed, it's just an Add form, no Invite option, and you can't access this form unless you are an admin or og_memberadd is true. [Using emails not currently on the system will still send an invite so when that person joins the site using that email address, the new user is autoadded then, if "Add Users" is the option. If it's "Invite Users" (only possible with Open/Moderated), then email invitations with both join and subscribe urls will go out, and we won't autoadd these people to the group on signup]

This og_memberadd setting turned on would/should have the following effect on each of the 4 group types:

• Open - Any member may now (optionally) auto-add any other site member (or newly invited user when they join) to this group. That new member may leave if desired, but isn't asked about the join - it just happens, if the current member decides to auto-add instead of invite. (The normal invite option will still be the default invite, sending new users the invitation link to subscribe)
  This could be desirable in some cases: Think viral marketing, or social groups where dozens of people might be recruiting friends but not have admin access. Party invitations for example - you get invited by a friend to a Party Group, and can now see the group details/info/etc, and can now invite others... who can in turn invite others themselves. Someone outside of the group can still join just by wanting to join.)
  It likely won't be wanted in most cases, but it is a possible new feature - only admins can add people to a group right now.
• Moderated - Any current member may now (optionally) be able to add people without any moderator approval, but uninvited users would still need admin/moderator approval. This would allow Open Web of Trust groups: If I trust you, I can add you, and I trust you to add others you trust. People none of us know have to get permission via a moderator still.
• Invite Only - This would turn the group into a Closed Web of Trust - nobody uninvited can ask to join, but anyone in the group can add someone new. In this case, the invite/add form would be forced to 'add', since Invite Only groups have no subscribe url for an invitation to point to.
• Closed - This would turn the group into a Sticky Web - once anyone adds you to this group, you cannot leave unless an admin removes you. The person who added you cannot remove you either. Not sure of a good use case, but perhaps someone will find this useful. Again, there would be no Invite, only Add on the form, since there is no subscribe url for an invitation to make sense.

Other considerations now needed are some form of email/messaging telling the user they have been auto-added to a group by someone else. I think the existing mail functions will be fine, and we can add the optional custom invite/add text from the add/invite form to the message.

Moshe - 1) - lets keep this hidden to avoid pref bloat.

I'll remove it from my patch.

I see a number of variables in og with no admin setting form to access them. Do you mind a contrib module that just collects these together for those who want to let admins change them? I can code that up as og_extravariables.module.

#24 is a terrific writeup of how the new setting will affect the 4 group types. makes a lot of sense to me. but how can we possibly convey this on the node/add form for a group? i feel like we need to have a 'group rules' section which is just a textual list of rules and that section changes as you make changes in the form. i don't recall seeing any UI like this in Drupal but it seems nifty to me.

yes, you may go ahead and do a og_extravariables module. i'm not sure if i want it in core og but if not it will be helpful in contrib.

I have some comments about the proposed changes in #24.

My understanding of how group invites currently work for moderated groups is as follows:
1) User A (group admin) sends an invite to User B (not a group member).
2) User B follows link in email.
3) User B clicks "join group".
4) User A approves User B to join the group.
5) User B is now a member of the group.

If this is correct, the step that seems redundant, and the step that seems like it should be removed, is step 4.

My understanding of #24, is that it proposes to get rid of steps 3 & 4. Step 3 seems like a very important step for many types of sites, and I would recommend keeping this separate from the removal step of 4.

Yes, you are correct in your understanding, wrt the new patch, but not specifically for the changes in #24.

As an admin, you cannot current add non-users who are only emails, you must follow the above flow you laid out: invite them, then ALSO approve them when they do join.
The 'auto-adding new users when they register' is meant to fix that hole.

Without the added option from #24, the 'normal' method (the new default) would NOT retain #3 and #4 as it stands now, but since the same person (ie admins) who is doing the invite would then have to do an approval, what's the harm here? You are authorizing a (future) user with a known email to join the group, and saving yourself a step later.

#24 is about adding a _new_ option, in which as said above: "Moderated - Any current member may now (optionally) be able to add people without any moderator approval, but uninvited users would still need admin/moderator approval."

The flow after #24 would become (if this option is enabled):

1) User A (group member) sends an invite to User B (not a group member).
2) User B follows link in email.
3) User B signs up on site.
4) User B is now a member of the group.

Note that there is NO moderation in this case. Uninvited Users would still be subject to join moderation by an admin.

1) User A (group member) sends an invite to User B (not a group member).
2) User B follows link in email.
3) User B signs up on site.
4) User B is now a member of the group.

Seth, this exactly what I need. Thank you so much for anticipating this need, and working it out. Is there any chance of a 5.x patch?

Yes, there will be a 5.x patch (I've got it working already), but I need to finish the 6.x patch - I rejiggered it to fit with Moshe's newest dev code, but haven't done the work in #24 yet..., because I'm swamped with other work, including finishing a presentation for Design4Drupal next weekend.

Patch, as mentioned above, enclosed. Still does not implement changes in #24, but does apply to latest dev.\

Moshe was nice enough to offer me maintainership for OG D5, so once we get the D6 changes settled, I'll backport it all to D5, review other pending D5 patches, and roll up a new D5 release.

Hey,

Here is a new version of that patch that includes what is IMHO the most important aspect: the removal of the redundancy in inviting an existing user, having them request to join, and then having to approve them (with the last step being removed). This is in lieu of the old patch's functionality whereby invite just added users outright, which I feel isn't correct because there is already a separate add user form...you're not really being 'invited' if you're forced to attend :-) The nifty memory function for approving anonymous users remains. In my opinion, pending a bit more testing, this could very well be committed. The net changes are, on the back end:
Changes to the invite functions, some UI functions, user and subscription functions, and adding a table.

More importantly, on the front end the main, probably quite uncontroversial differences to the enduser/admin are:
Adding functionality to remember email invites of non-users and add them once they join (I didn't test this but left it unchanged; presumably Seth did)
Removing redundant step in inviting registered users, but retaining necessity of them actually taking action of joining the group themselves.

On a sidenote, I am wondering why the invite functionality neither calls a hook nor uses messaging for sending stuff out. I might start a new case/look for existing ones about that to make it a bit more standards compliant in that regard.

David

New and improved patch, includes an action.

David

Wow, thanks for pitching in David, this is a dynamic group! Your ideas sound very good, but I think that there are so many different use cases for group behavior it's hard to say that it's better than Seth's original. The solution I am looking for is an extremely pared-down invite: once the original invitation is sent, no further action is required by the group admin --invitees just get in automatically once they create local drupal accounts. So, in my case, Seth's (sounds like it) suits my needs better -- can this distinction be a radio button in the OG admin UI? What would you call it? Maybe Seth's could be a subset of Invite-Only and yours could be a subset of Moderated? (does that even make sense?)

I am very interested in seeing a D5 backport (of Seth's), and am willing to set a bounty for it. Would $200 be enough? My department has antique payment menthods, and won't do PayPal (yet ... I'm working on that). If you can send me an invoice (PDF, e.g.), I can get you paid. I'd like it to go to Seth, if he is available.

Thanks,
Zach

Hey! Sorry i wasn't clear on this point, but actually the functionality for users that aren't already on the site remains the same in my patch as in seth's--they will be automatically added upon joining. It's only for already existing users where it changes to require the registered user to join themselves once invited, and I think this is reasonable because there already exists an add user form that does the add-without-asking thing for registered users.

Thanks,
David

David, I think that your version makes perfect sense for most cases, but in my case we are looking for a one-stop, ultra-simple invite form that invites (via email) and joins-to-group automatically for all invitees. We are constraining the UI in a big way, and are not using a lot of the OG defaults. We're not using any other form besides node creation and invite (so yeah, Seth's :)

duplicate. delete me.

+1 for David's solution in #35

Back from a camping vacation, and I'll review David's changes and find the time to code up the stuff in #24 as well, hopefully.

More soon.