Escalation to target role fails

I tried this but my users are not getting the invite role assigned to them. Bummer

I needed a quick solution to this that didn't span to many lines while wait for this module to be updated with whatever solution works so I inserted this into the invite_user rigfht before 'insert' is finished (line 456ish):
$account = user_load($account->uid);
$edit['roles'] = $account->roles;

By the way shunshifu, it probably didn't work due to none of the helper functions called from invite_user are getting the $edit or $account objects as references (&$edit, $account). S/he didn't copy that part of the code into his/her comment.

#314347: Role escalation bug was marked duplicate.

I implemented a similar solution that changes less code in the the attached patch. This patch includes fixes for some other bugs too, so you may need to filter those out. I'll submit a clean patch later.

The solution I've implemented deprecates the need for

  // Notify other modules of changed user.
  $edit = array('roles' => $targets);
  user_module_invoke('update', $edit, $account);

in _invite_escalate_role() and removes it. This has the side effect of optimizing performance. However some other modules may depend on the change done this way. They will need to be updated to use hook_user('update') as well or instead of hook_user('insert').

A clean version of this patch is attached. Needs some testing and some input on the removal of the call to user_module_invoke()

works like a bloody charm, no end of hours of stupid stress have been caused by this issue, YAY for the invitee role!! thank you ever so much

Hi Bevan,

Also having problems as invitee does not receive assigned role.

Would you be so kind just to upload your invite.module as unfortunately I cannot perform patches.

Look forward to hearing from you, and thank you.
Lilian

Lili, I don't think it's a good idea to use a patched module if you don't know how to apply patches or keep up with the development of the patch/fix. That's when patching becomes forking. Patch files are actually relatively human readable. I suggest you take a look at it and have a go at applying it manually, by editing the source code of invite.module. This one isn't the simplest of patches, but it's also not too large for manual application. Once you have done it manually a couple of times you'll want a tool to automate it for you. See http://drupal.org/patch/apply. If that is all too complicated then you should contract a developer, or wait till this is fixed in a release of invite.module.

Looks like duplicate of #322748: Only administrator can send invitations on multilingual installation.

Escalation depends on settings which could be wrong on multilingual sites

Andypost; This issue occurs on mono-lingual sites which is where I came across it and created this patch.

This patch in #7 applies cleanly to a 6.x-2.0-alpha1 invite module. Successfully tested the proper setting of invitee's target role with this patch.

Nice,
Bart.

#137495: Other Modules not notifed of role change was the issue that required the addition of user_module_invoke(). Basically, other modules (User Badges in this case) want to get notified if a role change takes place, therefore we cannot remove it.

However, I've taken the patch from #7 to simplify the workflow a lot, the code responsible for processing an invitation has been consolidated into one function (former _invite_accept, now renamed to invite_process), while hook_user() takes care of the role escalation.

This *should* still work, but needs testing with both User Badges and Auto Assign Role modules.

I tested this patch in #14 with Auto Assign Role, LoginToboggan and Registration Role Keys modules - successfully. Thanks!

Committed, thanks all!

I don't believe that calling user_module_invoke('update', ...) in the hook invite_user with $op=insert is a good idea. This will start the update-procedures of the user hooks before all insert procedures have been finished.

Example: Let's say, module y has a higher weight in the system table than the invite module, so y_user() gets executed after invite_user(). The hook invite_user calls in the insert case the hook_user to perform the 'update' functionality. In this step drupal will call the hook y_user with $op='update'. After finishing the hook_user update-case (returning back to invite_user; still in the insert case) the until now not executed user_hooks like y_user will be called (with op='insert'; after their 'update' case). If the update case trusts on data set by the insert case it will probably have/cause some trouble.

Suggestion (not verified): why not use the 'submit' case to set (add) the account roles? In my eyes this means that there has never existed a account with other rules than the given ones (set by invite and maybe some other modules). So you don't have to change the rules and it's up to the other modules to recognize that the created account has some more roles.

I found that the overall settings for assigning roles to the newly invited member worked fine with patch #14 (thanks!). But assigning a specific role if the invitation was issued by a user with a specific role failed.

The problem appeared to be in function "invite_target_roles". It seemed necessary within the loop in that function to use the "$role" value (with spaces replaced by underscores) rather than the $rid value.

Patch with this change attached.

Hi bpirkle,

This sound really interesting and I want to help with testing (even though it seems no patches are being committed to invite module recently).

To confirm what this patch does:
1) choose the role added to invited users
2) choose the role added to invited user when invitee has role X

Therefore these scenarios should be possible?
1) if user1 with role A invites user2, then user2 receives role A
2) if user3 with role B invites user4, then user4 receives role B
3) if user5 with role C invites user6, then user6 receives role C and role D

Thank you!

@bpirkle
Your patch is against outdated module versions and contains changes that have long since been committed to the development version.

@yaz085
There is currently nothing that can be tested here. The only issue remaining is #19, finding a way to avoid calling hook_user('update') from within hook_user('insert'), which is indeed problematic but should be discussed in a separate issue.

Created a new issue: #870668: Calling hook_user() from within hook_user is error prone.

Thanks smk-ka! I will follow 870668. Awesome module!!

Edit: double-post.

Which version of this module works out of the box with this? I can't seem to get any version to work - no user roles are ever assigned to the invited user.

Has this problem been fixed in beta 3? The latest version of the module only applies the default role when they register and not the additional one base on the role of the person who sent the invite.