As the title suggests, I'd like to take on enhanced compatibility with the Invite module. The attached patch specifically deals with logintoboggan_user_register_submit(), which has been changed to act more like user_register_submit(). The difference between LT and D is, that LT largely acts on (static) variable values, whereas D takes the (dynamic) result of user_save() as its base for decisions.

These changes need to be explained, so I'd like to go more into detail:

* The first two changes replace the check for variable_get('user_register', 1) == 1 with $account->status. This is possible as the status is earlier set based on the very same variable value, but it allows Invite to modify the status in hook_user($op = 'insert'). That's a requirement as Invite defines another user_register mode (registration "by invite only") and thus needs to be able to change the status.

* The 3rd changed line makes LT send an email even when Invite is in "invite only" mode, or more generally: when an account is blocked, it (trivially) needs to be approved. Thus we can remove the variable_get('user_register', 1) == 2 check.

These modifications change the logic but not the behavior, ie. they should be compatible.

CommentFileSizeAuthor
#10 invite_lt.patch2.82 KBsmk-ka
logintoboggan_submit.patch1.81 KBsmk-ka
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hunmonk’s picture

have you tested this with all combinations of registration settings (as detailed at admin/user/settings) and registration workflows (user can create password/immediate login, system generated password).

i recall it taking quite a while to get that code to behave correctly, especially for admin approval stuff, so i'm not going to make changes lightly :)

hunmonk’s picture

Status: Needs review » Postponed (maintainer needs more info)
jcruz’s picture

Any updates on this patch?

hunmonk’s picture

Status: Postponed (maintainer needs more info) » Needs work

patch no longer applies.

Boris Mann’s picture

Looking at this now, and we think we're seeing an interaction between LT and invite -- when user reg is set to invite only, once a successfull invite happens and the user is registered, then a confirmation email is sent...and that confirm email ends up being blank.

More info as we debug.

Crimson’s picture

I'm seeing this exact bug. Verification emails are blank for users that register through an invite, that is a non-workable situation. I need the invite module and I think the LoginToboggan module can also work with it. Can somebody make a hot-fix patch this?

Crimson’s picture

Ho ho ho! I just manually applied this patch and it works great! No more blank verification emails for users that register through an invite and the user has the unverified role applied to it, definitely the correct behavior! Thanks! I guess somebody should create an updated patch for the current LoginToboggan version and the code can be committed.

Crimson’s picture

Dang it! The verification email doesn't do anything! It doesn't switch the user's role to authenticated user. How do you request another verification email? Request new password? I tried that too and the link that it sends does let me access the account but the user role is unchanged, still the unverified user role.

hunmonk’s picture

is anybody still working on this issue? i don't really have any interest in it, but will look at patches.

smk-ka’s picture

Title: Enhanced compatibility /w Invite » Enhanced compatibility /w LoginToboggan
Project: LoginToboggan » Invite
Category: support » bug
Status: Needs work » Needs review
FileSize
2.82 KB

Ok, based on Crimson's reports it seems this can't or shouldn't be fixed in LT - but it can in invite. The culprit is invite assigning a value of 'inviteonly' to the variable user_register, whereas Drupal core and LT expect a number from 0 to 2. Without invite-specific changes to LT this can't be solved.

For invite, the trick that seems to do it is to make use of PHP's on-the-fly type conversion and prepend the desired numeric value to the string. Changing 'inviteonly' to '1inviteonly' results in ('1inviteonly' == 1) returning TRUE. This allows an application like LT to rely on standard tests (like variable_get('user_register', 1) == 1), whereas invite can make use of the strict equality operator to determine the real value (ie. variable_get('user_register', 1) === '1inviteonly').

Moving the issue back to Invite. Anybody willing to help please check out the attached patch.

asak’s picture

smk-ka: I can confirm this patch partly works. When an invited user registers, they now properly receive an email with their username & password. They don't, however, get assigned the roles they should be (as specified in the invite.module settings page) - not even 'authenticated'.

I'll gladly test & feedback if you've get an idea...

UPDATE: when setting LT to 'Set password & Immediate login' and using a pre-authenticated role, the user does get that specific pre-authentication role - but doesn't get an email to authenticate & get the 'real' role.

vanvemden’s picture

Running into the same problem. Somebody has a solution for this? Need to use LT and Invite for production site. Thanks,
Marco

adam_b’s picture

Version: 5.x-1.x-dev » 7.x-2.1-beta2

Four years and two core versions later, I'm having exactly the same problem - the Invite (v7.x-2.1-beta2) confirmation email is empty unless I turn off LoginToboggan (v7.x-1.3). Has any progress happened elsewhere?

Seph’s picture

I am having the same problem. Is there any work around for this or is there any work being done on this at all? I need to use this for a production site as well.

matt.rad’s picture

Issue summary: View changes

I would also like LT & Invite to work well together. Currently, if a user responds to an invite and registers, nothing appears to happen on the registration form (just reloads). A registration mail for validation is not sent either. However, the user account is created.

Is it a case of having to choose one or the other module here?

ckng’s picture

Version: 7.x-2.1-beta2 » 7.x-4.x-dev
Assigned: smk-ka » Unassigned
Category: Bug report » Feature request
Status: Needs review » Needs work

This is not working/complete based on user reports.