As far as I can tell, the only difference between an open group and invite-only group is that the og/subscribe url is hidden and sent through email in the case of an invited user. What I am thinking would fix this is to store invites as GID | EMAIL in the database and simply check if the user's email matches the invited email before subscribing them. This way, if a user clicks og/subscribe/$gid it checks to see if they were actually invited before subscribing them, so that a clever user can't just go around adding themselves to invite-only groups.

Additionally, on a user's profile page there could be a drupal_set_message or similar asking if they would like to accept or decline the invitation to a group, since now we would be keeping track of the invites.

This way unregistered users wouldn't have to go back to their email to click the link again; they would simply login and click the link to subscribe to the group immediately. This would also notify a registered user that they've been invited to a group without having them check their email.

Thoughts? I tried searching for similar issues in the queue but did not find any, so apologies if this is a duplicate.

Comments

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.

Title:Invite URL is not secureKeep track of group invitations

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.

Category:bug» feature

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...?

Priority:Normal» Critical

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).

Version:5.x-3.1» 6.x-2.x-dev
Assigned:zirafa» sethcohn
Status:Active» Needs review
StatusFileSize
new6.46 KB

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:

<?php
function og_save_subscription($gid, $uid, $args = array()) {
 
$sql = "SELECT COUNT(*) FROM {og_uid} WHERE nid = %d AND uid = %d";
 
$cnt = db_result(db_query($sql, $gid, $uid));
[
snip]
  if (
$cnt == 0) {
   
drupal_write_record('og_uid', $subscription);
   
module_invoke_all('og', 'user insert', $gid, $uid, $args);
  }
  else {
   
drupal_write_record('og_uid', $subscription, array('nid', 'uid'));
   
module_invoke_all('og', 'user update', $gid, $uid, $args);
  }
}
//And then in hook_og
function og_og($op, $gid, $uid, $args) {
  if (
module_exists('rules')) {
    if (
in_array($op, array('user insert', 'user delete'))) {
     
$op = str_replace(' ', '_', $op);
     
rules_invoke_event('og_'. $op, $uid, $gid);
    }
   
// Pending member was approved.
   
elseif ($op == 'user update' && $args['is_active']) {
     
rules_invoke_event('og_user_approved', $uid, $gid);
    }
  }
}
?>

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.

StatusFileSize
new6.92 KB

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.

StatusFileSize
new11.17 KB

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

StatusFileSize
new17.57 KB

New and improved patch, includes an action.

David

Issue tags:+bounty

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.

Subscribing - great work guys!

Subscribing - this is nice!

The patch on #33 worked fine except for og.module file. I couldnt apply the patch (using Tortoise SVN). I am using the latest RC3 version of OG. So I applied the patch to og.module by hand. Now it works just fine...

Thanks,

Sinan

Yes, it needs to be rerolled against RC3. My bad. Swamped at work, and too many social obligations during the summer on weekends. I need to be a better nerd and sit in the shade on a weekend in front of the LCD. (grin) This weekend isn't much better (wedding anniversary, company picnic), and a big work deadline looming up for tomorrow and Friday.

D5 version also coming, I've had a few testers for it with good results. time for some public eyeballs.

I publically promise to get at least some of my promised backlog of OG code reviewed and committed and/or posted this Sunday. maybe some other Drupal stuff too.

StatusFileSize
new23.82 KB
new1.05 KB

As the last patch stood, private groups clashed with invite functionality. The /og/subscribe callback required node_access perms on the group in question, but if that group was private, an invited user did not have sufficient perms to view the group or even to subscribe. Hence, a user invited to a private group invariably ran into an Access Denied error. Here are two beginnings to a solution.

The first patch, oginvite-privategroupfix.patch, is a quick and dirty fix that gives invited users an og_subscriber node grant on groups they're invited to so that node_access returns true. I'm pretty sure this is rolled against a clean CVS copy. But it's only a couple of lines, so doing it by hand if it fails against this thread's weird outgrowth of RC3 won't be hard.

The second patch, oginvitev3.patch, is more extensive. First, I've changed the access callback for /og/subscribe so that it gives invited users access to the subscribe functionality even if the group itself is private (before, a user would be invited to a private group and would then hit an access denied page when they tried to follow the subscribe link in the email). Second, it creates a new CCK field, og_private_preview (with a checkbox on the group's edit page), and a new node grant realm, also og_private_preview. If a private group has og_private_preview set, then an INVITED user attempting to view the group will be permitted to do so before joining (because some use cases might involve users who want to check the group out before actually subscribing). The user and the node are both given the private_preview grant, which only permits 'view' right now.

I rolled the second patch as a bundle of my changes and David's oginvitev2.patch changes, all against a clean 2.0-RC3. However, because CVS has changed, I had to roll it sort of ugly with plain ol' diff, so you'll probably have some trouble applying it. I'd be happy to upload a version that's rolled against RC3+David tomorrow so you can see more specifically what's going on in this patch alone. I'd love some feedback!

StatusFileSize
new21.59 KB

WAIT WAIT WAIT I take it all back. Here, after some decent sleep finally, is a copy of David's patch and my patch bundled together and rolled against CVS itself. No more ugly shell diff patches. I had to do some manual application of David's changes in og.module (as etcetera9 mentioned above). Install against CVS 2.0-dev and tell me what you think!

Places to look for new functionality and test for bugs:
1) Edit group page: new private preview checkbox beneath private checkbox (TODO: make it dim when private is not checked)
2) Check out the user flows when you invite someone to a private group -- both a pre-existing account and an email address without an account tied to it yet. The former should permit the user to access /og/subscribe, which wasn't the case before. It should also allow the user to wander around in the group if private_preview is checked.

The latter is basically unchanged, as far as the patch is concerned. Just make sure it still works how it should, I guess.

Also, another thing. Is your site set so that users aren't allowed to create new accounts at will? If so, I wrote the following hook_user for my current project, which may be of use to y'all.

<?php
function yourmodule_user($op, &$edit, &$account, $category = NULL) {
    if(
$op == 'validate') {
        if(
module_exists('og') and module_exists('og_access')) {
           
$mail = $edit['mail'];
           
$sql = "SELECT COUNT(*) FROM og_invite WHERE mail = '%s'";
           
$query = db_query($sql, $mail);
           
$cnt = db_result($query);
            if(
$cnt <= 0)
               
form_set_error('mail', "Nobody at the email address <em>'$mail'</em> has been invited to create an account.");
        }
    }
}
?>

Now just go into User Settings and allow users to create accounts at will again. With this snippet, only people with registering email addresses in the og_invite table will be allowed to make accounts. So the only ways to get an account are 1) be invited to an OG group or 2) seduce an admin. My current client is using OG for a very closed sort of group model, hence all of these little tweaks and changes. Hope it's useful to someone out there!

Bryn

StatusFileSize
new26.78 KB

...And here's another version of the patch. This one now includes some new Notifications templates for 1) invitations sent to people who don't have accounts yet and 2) invitations sent to people WITH accounts regarding PRIVATE groups with private_preview enabled. The language in these two cases may differ from the standard invitation email.

In the first case, you may want to express the fact that the user has to register first and will then be auto-added to the group. For example, my project's language is something like "click here to create an account with access to this group".

In the second case, you have access to a new token/variable called !preview_url which simply takes the logged-in, invited user to the group to browse around and check it out (if that group allows private-preview). My project's email gives two links, !group_url for subscribing immediately and !preview_url for poking around first.

So, it is a pretty radical idea, but what do folks think about actually creating a real, unconfirmed user account when a user is invited into an og. then we can put the user into the group as a pending member. we would have to be careful about emailing the invitee clear text about how to activate his account and participate in the group. we would include a link which would be like the one time login link you get when you forget your password ... not sure i like the idea but thought i would throw it out there.

i hope to review the patch here. probably next week. would be great if others had a look too.

@47:

This is exactly the type of functionality I need for a site - currently it is a D5 site. Of course I need by noon tomorrow - I'll post my work here once I complete it.

Could this be used to admins be able to actually read a list of all invited people?

-1 on the idea of making 'invited users' real users waiting for a confirmation/activation. There are some good legal reasons why you don't want to do this. Think spamming sites for one thing. "You've been 'invited' to our new amazing site... you are ALREADY a member, and you must join in order to leave!"

As an optional feature, perhaps, but seems like a bad idea waiting to happen in most cases.

@Seth - very true. You might want to help us find a good solution for core at http://drupal.org/node/355513

Anyone up for doing a flowchart or other diagram of the changes proposed here? Thats the only way to keep straight the use cases. Maybe use http://www.gliffy.com/ or iPlotz if you want to work online.

StatusFileSize
new26.78 KB

Quick update -- found a bug where someone forgot to wrap some strings in t() and thus was generating an error in bootstrap.inc when users already in a group were invited. Here's a new v4 patch.

As far as doing some flow charts, I can put together the two that my site is using later today or tomorrow, probably.

StatusFileSize
new26.78 KB

Damn, there was ANOTHER one. This ~should~ be all of them.

We are very much in need of this to be working, as we're launching our site within 2 weeks and OG invite/subscription flow has been the last big remaining issue for us - particularly, we need for a Moderated, Private group to actually allow someone who has been invited, to join (we get an access denied page when the private checkbox has been checked, which is incredibly confusing and counter-intuitive).

Does this most recent patch work against the current shipping 6.x-2.0?

thanks

In the same situation as you friolator. I have people beta testing my sight right now (with a strong caution not to use group functionality yet).

This patch doesn't work on 6.x-2.0; I think the last roll was against rc3.

Yeah, we need this functionality pretty desperately as well. That's why I cobbled together this patch in such a hurry. The client is really hesitant to keep the functionality if there's no upgrade path, though. Is there anyone who could be coerced into reviewing and committing this stuff?

Also FWIW at some point we really need to create a view that shows all pending invitations for a user. Right now, when you click a subscribe link in an invitation email but you're not logged in, the user flow is really rocky. You essentially have to login and then go back to your email. It'd take 30 minutes to code and test, but we should talk about how best to do it before rushing forward with it.

subscribe - you guys rock! - seriously

any word on this? we would really love to have this implemented before we go live with our current site. As it is now, we're probably going to have to hold off on including groups in our first version because this is a blocking issue for us.

thanks!

@brynbellomy: I would be happy to review and test the patch, if it was made available for the 2.0 version.

A new patch please! We'd also like to test it. Using the latest dev -version.

I'm working on similar integration for a site.

While I realize that the Public / Private / Moderated group settings add a bit of complexity, is there any reason not to build this functionality on top of the Invite module, and it's API?

In addition to inviting folks to group membership this would provide the framework to track invitations to the site as well. It seems like in most cases (where there's interest in tracking group invitation rates) it would also be useful to have site registration statistics. These would be skewed if we auto-join groups on invitations coming from og, but would be useful for sites that want to support general site invites.

#63: I think it is very good idea. If it is possible...

i think that's a great idea - as it is right now OG's invitation system is incredibly confusing. I'd love to see this simplified, and building it on Invite opens up some interesting possibilities. My only concern is that this might drag on for another two years ;-)

We may be willing to pay someone to get this working for us. Please respond if interested to destlund@txgifted.org.

I'll be working on this in the next day or so... Between work, play and H1N1 (aka the nerd ick), little time to spare, but it's on top of my todo list.
I'll reroll for latest D6, and I have a working D5 version I'll align up to the most recent code.

Thank you brynbellomy for the patch. It is exactly what my client needed! I wouid like to know if there will be a new release that includes it.

One slight problem/bug:
The listing on og/directory/all should list any invite-only groups that user has been invited to. Currently (after patch), they do not.

I will volunteer to do it myself if I can get some breathing room this week.

Title:Keep track of group invitationsFixed omission in oginvitev4.patch
StatusFileSize
new26.79 KB

oginvitev4.patch had a naked DB table reference on line 511 that needed to be surrounded with curly braces. On my box, this caused the following message:

Table 'lsiden_memcatch.og_invite' doesn't exist query: SELECT group_nid FROM og_invite WHERE mail='1' in /home/lsiden/public_html/memcatch/httpdocs/sites/all/modules/og/modules/og_access/og_access.module on line 280.

New patch attached.

Sorry but is this whole issue about: "Fixed omission in oginvitev4.patch" as the new title of it suggests? I don't think so...

Title:Fixed omission in oginvitev4.patchKeep track of group invitations

Fixing title.

On a personal note, life's been uncooperative, and too many projects/work/reallifeobligations, too little time.

I know I'll be at DrupalCamp Montreal, so if someone wants to meetup and discuss pending OG issues (BOF meeting?), let me know.

I have just finished a project regarding this issue. Thanks for all the inputs and efforts posted above, I was able to finish it before Thanksgiving and enjoy the holiday without worries. I would like to share my thoughts and experiences here.

The project I was doing for this client has the following requirements on the flow of user invitation on their OG groups:

1) The admin or member sends out an invitation e-mail to the invitee
2) The invitee sees the e-mail and following the link on it
3) After login or register, the invitee will be automatically shown the form to confirm the invitation if they was following the link
4) After the "Join" button on the form is pressed, the invitee joins into the group as a member

I did not use the patch posted about because I am a total noob on using patches. I made all the changes manually against the shipping version of OG 6.x-2.0 (yes, it is a dirty job).

The "og_invite" table I used has two more fields beside the "mail" and "group_id". The two fields are the "created" field, which records the time of the invitation, and the "creator" field, which records the person that sends out the invitation.

The client I worked with has a site that does not require e-mail confirmation on account creation. Hence, I think a little bit more security will be needed to authenticate the newly registered user on group invitation. I did this by modifying the e-mail template to send out invitation so that the time of invitation will be included in the e-mail as the "invitation key". I also make a small alter on the "invite to join" form to display a text field for user to enter the "invitation key" and the corresponding validation for it.

Another thing that I implemented is the invitation management, which provides an interface to display all pending invitations and enables the user to manage them. Through the invitation management, user can re-send or discard pending invitations. The "creator" field is needed here so that each member manages their own invitations and the admin can manage all of them.

The last thing I want to mention (and not sure whether it is covered by the previous efforts) is that I made the system to check whether a user has been invited when he use a link from an invitation e-mail. If the user is not invited, he will be denied on access.

Thanks again for the previous efforts on this great thread. I am looking forward to see the new release of OG that includes better invitation functions.

petefelix, can you post the work that you did to get this working? I am looking for this functionality as well so that I can list on a block invites and requests for joining og groups.

One other question- are these patches in the current dev snapshot yet, or are they still under consideration for being added?

subscribing

Priority:Critical» Normal
Status:Needs review» Closed (won't fix)

I'm setting it to won't fix because I think this functionality needs to live in contrib and not OG core.
The direction OG is taking is stripping functionality that isn't essential, *but* allowing implementing modules to use it's API - If there's something missing for that then patches are welcome :)

In the meantime, is there a better place to keep these patches? (also .. subscribing ..)

subscribing

I make an attempt to contribute a module for this here: http://drupal.org/node/803172

Would be cool to join forces and get something going.

Can we have access to the code or module?

Version:6.x-2.x-dev» 6.x-2.1
Category:feature» support
Priority:Normal» Critical
Status:Closed (won't fix)» Needs review
Issue tags:-bounty
StatusFileSize
new90.64 KB
new156.62 KB
new163.8 KB

Hello All,

I have been struggling with the invitations for a long time now. I think that the invitation mechanism is group-type centric instead of being user-centric. From group-type perspective, it works flawlessly. However, the user experience suffers due to this approach.

Can we model the invitations according to the user roles - Group Admins, Group Members, Authenticated and Unauthenticated users?

PFA the suggested flow for invitations. Suggestions are welcome.

Thanks,
Ishmeet

What's the status on this one? Seems like og_invite died before it was published? Invite only is still rather unusuable; it's almost indistinguishable from Closed AFAIK.

Subscribing in any case...my client kinda wants "invite only" and I have a CVS account, so maybe og_invite will happen...we'll see.

+1 subscribing

StatusFileSize
new691 bytes

I was sent to this extremely long issue from a direct link in the og.module code in og_block_detail() function.

Forgive me for not reading the entire thread, but taking baby steps here... how about something that is actually actionable today, instead of an entire rewrite:

Would it at least make sense to use the same logic for accessing the invite form/page in the MENU as for the LINK in the block as well?

StatusFileSize
new1.17 KB

Better yet, let's move the inline comment and reference to this node along to the right place...

Category:support» bug
Priority:Critical» Normal

Let's not pretend this is a critical support request, but that its a normal bug report; and maybe a module maintainer can jump back and take a look at this quick fix.

Subscribing....

Workflow from #81 seems the right way to do.
I hope this issue lives on...

Subscribing...

I applied patch suggested here #54 and so far, seems to be working as I expected, adding invited users by admin, automatically to groups without needing approval.

Subscribing

Assigned:sethcohn» Unassigned
Category:bug» feature
Status:Needs review» Closed (won't fix)

Although it does not address the entire scope of the original issue, jwilson3's patch #85 is worthwhile and should be applied. Just sayin'.