Link to subscribe to group doesn't work if member not logged in.

Unfortunately, yo can get to this situtation without having followed an email link. I think we need to find some code fix so that the user can register/login and join in one step. It is a bit of a project, so thats why it isn't done yet.

Going back to the original issue - yes there is a way of adding the destination to the login url - see the patch for 6.x below.

The tricky bit is propagating the destination url and group node id to the create new account page. This patch is a bit of a hack in that it adds url query strings to the local task urls via a theme override for theme('menu_item_link'). This will work as long as you're not using a theme or module that's trying to override the same. There must be a better way of doing this but I can't find it.

Besides the caveat above the patch is very effective and improves the user experience considerably.

Beyond this there is scope for encoding more information in the subscription url - e.g. a single use join token that will dispense with the need to approve an invited user in a moderated group.

Andy

wouldn't this be just a little simpler...

this patch uses drupal_get_destination() to return them to the previous page. It changes the message to give them links to the login and register pages. The user should know if they have an account on the site so they can click the appropriate link.

A little simpler yes, but it's not a complete solution. You're asking the user to ignore both the login form and local task tabs presented to them, and click on less visible links in the message instead. Also the query string for user/register needs a gids parameter for the group checkboxes to appear.

Here's version 2 of my patch which includes support for unique joining urls that dispense with the need to approve an invited user in a moderated group.

Perhaps this kind of functionality is beyond the original scope of this issue but it addresses the extremely irksome invitation workflow of moderated groups where the invite conversation goes something like this:

group admin: "Hello user please join our group"
user: "OK"
group admin: "What? You want to join my group? Fair enough, but first if you're not logged in you need to login (or create an account, then login), then click on the link I sent you"
user: "OK, done that - now can I join your group?"
group admin: "What? You want to join my group? But I don't know who you are - I'll need to approve you first."
user: "But you asked me to join!"
group admin: "So I did - there you go"

It works in a similar fashion to one time login urls but uses a hash key to limit the url to a single group and email. The email address is the one that the invite is sent to. There's an edge case where the user registers with or is already registered with a different e-mail. In this case the workflow silently defaults to the usual approval route.

It still uses the theme hack for altering the links on the new account tab - (more) suggestions welcome.

Final (?) version that uses the session variable introduced in version 2 to maintain the og joining context on user login and registration pages rather than the theme hack mentioned above.

Looked at code really quickly.

1. 'destination='.$_GET['q'] is usually done with drupal_get_destination()
2. Please use sentence case for comments. Start with a capital letter and end with period. OG itself is not consistent here but we want to get better not worse. See the coding standards.
3. Please concatenate with a space before and after the period like Drupal7 does.
4. Fewer abbreviations please. t, h, and friends would rather be time and hash written out.
5. Not sure how relevant it is, but we need to use session vars as little as possible for anonnymous users. They are poison for proxy caches. This really amounts to unsetting session vars as soon as you are done with them.

I will give a more substantial review soon. Thanks for working on this.

@moshe Thanks for looking at it!

I've re-rolled incorporating your suggestions as follows:

1. Where I've used $_GET['q'] it's to avoid getting the query string which drupal_get_destination appends.
2. Comments - done.
3. Period spacing - I assume you mean the string concatenation operator - in which case done.
4. I've kept the h and t parameter names for the e-mailed join url but otherwise used more descriptive names in the code.
5. I would have preferred not to use session vars but I can't see any other way to do it. Besides, the vars are only set when users invited to join a moderated group with a coded url follow the link, and are unset when they actually join.

I found a bug where the personalised message is included as part of the clickable link in the invite email which effectively invalidates the hash key. This may be limited to my email client/configuration and only seems to happen where the url has a query part. I took the precaution of adding an extra "\n" in the message template.

I've just had a couple of thoughts on this:

1. The patch currently allows any group member to send out invites with coded urls. The group admin should be able to set whether group members can do this.
2. The hash in the url should include a private key to prevent spoofing.
3. It should be possible to use coded urls to subscribe to private groups (I have this ready to roll).

Any comments before I roll another patch?

I took another look and this code is just too complicated/convoluted. There has to be a simpler approach. Perhaps we show suck in the login and registration forms onto the og/subscribe page when an anon arrives at a moderated group. We then can handle the whole form submission in one spot.

I appreciate that you worked hard on this. I'm grasping around looking for a simpler way.

Really, I haven't worked hard on this - in fact I thought I'd get lambasted for taking too simplistic an approach. The patch re-uses all the existing joining and pre-selected-group-checkbox-on-registration-form functionality. The only thing it really does is create the url - validate the url, and manage the session variable. This patch makes the invite workflow work as you'd expect it to - as it should do. I can't see that introducing a whole new UI (join + login + register) is simpler or indeed desirable. Perhaps it's my coding style or is it that it uses the session variable...

The other (better?) approach which avoids session variables is to store e-mail addresses of invitees in the database. This would be much more involved (I'm thinking management of pending invitations here) but would still require urls of the form proposed to avoid spoofing. Perhaps this patch will do as a stop-gap and a better solution can be implemented under the covers?

This needs some fresh thinking from some inspired soul out there. We need to consider all the subscription models for groups, and admin vs. end user invitations.

Sorry I can't offer the fresh thinking - but can offer a large beer to whoever fixes it ;-)

#170332: Keep track of group invitations

backport to Drupal 5, also includes additional fix to allow the og_subscribe links with hash tokens to work for private moderated groups.

Patch re-roll which uses drupal_get_destination() instead, which is needed to preserve the t and h GET params in the URL.

Maybe I'm missing something here, but my solution is attached.

The workflow is a bit clunky still but it's not bad for a one-liner!

Rimu's "patch" worked for me! ;)

I haven't looked through the older patches but still, this reminds me of a home movie I made as a kid, whereupon the hero went through all this craziness to get to the other side of an obstacle, and then the hero's buddy finds a door and walks right through. Kind of a comedy cliche, but hey, we were kids.

Seriously, though in what cases wouldn't Rimu's patch work?

rimu's comment #20 solution works great. Super simple.

This patch in #20 fixes the issue of landing users on the right destination after they have logged into the site after clicking an invitation link in an email. I think the extra seven characters get a lot of bang for the buck. I have tested it on one implementation, other users have also tested it. I'm resubmitting an updated patch only because the line number changes have shifted since this patch last year. Please take a look and consider it for a dev version.

Crap.

Please reroll patch with git. Also, the solution should be more like:

drupal_goto('user', array('query' => $dest));

#23: 20120320_D6.patch queued for re-testing.

Any thoughts....still it is a blocker to me..............same issue am facing

This version of Drupal is not supported anymore. If this is still an issue in the 8.x-1.x branch, please open a new up-to-date ticket. Closing.