'Has role' condition unavailable at account creation

For testing purposes, please try your rule without any conditions. If that doesn't work, try getting rules to send an email on another event.

I'm not sure how to fix this.. "Role has been added" event is currently in discussion here #521266: role/permission rules integration. In the meantime, you could use role_change_notify, though of course it would be much better if this feature came from rules.

@mitchell: Hm, this doesn't really relate to each other. This is about fixing existing stuff, not about adding new one.

@issue:
The cause is probably that the passed $account object doesn't include the rules yet. To fix this special case we might look into adding in the roles properly when invoking the event, probably they are already in $edit['roles'].

can confirm i also have this problem, the $user->roles array has not yet been fully populated with the added roles, so when rules_condition_user_hasrole() fires to check for additional roles it does not find any extra, even although you selected some via the admin interface to add to the user. therefore this condition does not work on account creation (it will only work on the authenticated user role type).

@fago: how would we go about patching this? need to add something to the 'insert' clause on rules_user() in rules.events.inc ??

Subscribing as experiencing the same issue.

patch supplied to add the user roles on to the $account object before the event is invoked so the has role condition works on any roles that have been added at account creation

You broke the existing code to add back new roles to $edit['roles'], which of course needs to run after the rules. Else it looks fine.

@fago is this the correction you mean -

function rules_user($op, &$edit, &$account, $category = NULL) {
  static $account_unchanged;

  // We don't support updates for other categories than 'account'
  if ($op == 'update' && $category == 'account') {
    // Save the unchanged account for the use with op after_update.
    $account_unchanged = drupal_clone($account);
  }
  else if ($op == 'after_update' && $category == 'account') {
    rules_invoke_event('user_update', array('account' => &$account, 'account_unchanged' => $account_unchanged));
  }
  else if (in_array($op, array('insert', 'login', 'logout', 'view', 'delete'))) {
    // Allow adding user roles during registration
    $account->roles += $edit['roles'];
    
    rules_invoke_event('user_'. $op, array('account' => &$account));
    //add back new roles to $edit['roles']
    if ($op == 'insert' && isset($account->roles)) {
      $edit += array('roles' => array());
      $edit['roles'] += $account->roles;
    }    
  }
}

does the $account->roles += $edit['roles'] have to be wrapped in an if $op == 'insert also?

Subscribing! This is an important feature

At account creation you have the assigned Role IDs available in the $edit array, not the Role names. The attached patch converts the IDs to the names and appends it to a copy of $account->roles. This only makes sense for the insert operation of hook_user() so it is limited to this operation. Is this a way we can achieve the missing Has role condition at account creation?

Two problems with my patch in #11:

- By using a cloned $account object it can not be modfied longer by Rules. I removed the cloning part.
- The Role ID must be used as key in the $account->roles array

The attached patch corrects this. It is for Rules 6.x-1.1 by the way.

>+ if (in_array($op, array('insert'))) {
Use a usual == comparison instead.

>+ // Only allow numbers, there is at least a value TRUE in the array
+ if (!is_numeric($role_id)) {
+ continue;
+ }
Just test with isset() whether there is an entry in $system_roles and if it is, assign it. That's much easier to read and understand.

Corrected patch attached.

One word to the "test and assign" approach: I usually try to first exclude the non-matching condition(s) and do the assigning after that. That avoids ugly cascades of many if's in case of many conditions. In the case of a single condition this is overhead of course. And finally - it's your code so your wish is my command :)

Patch applies now from within the Rules modules root directory and for 6.x-1.x-dev too.

Patch applied smoothly but there seems to be an issue with Negate option in the Condition.

IF condition User has role(s) works!
IF NOT condition User has role(s) does not work(!)
The rules action gets executed even if the user has the role set in this "if not role" condition.

Thanks for the great work and I look forward to helping with further testing.

Regards

+1 subscribing

after hours of frustration - i realized that this issue is a bug and found this post =)
the patch worked! in my case I am just checking If User Has Role and not If User Does Not Have Role

I realized I am in need of the condition "If NOT role x" so tested it with this patch and as reported above it does not yet work. Any development on this patch? Thanks

Hello fuerst,

I was wondering if you may have time to look into the issue regarding the "Negate" option for the "Has role" condition. Please let me know if more information is required. Thank you very much in advance.

Regards

I tried to test it by creating a Rule with condition User has role(s), Arguments configuration registered user, negated it and selected an available role. To check the Rule evaluation I added a Show a configurable message on the site action.

Now when adding a user without the role set above the message got displayed. When adding a user with the role the message got not displayed. That's what I would expect.

Since the patch is not related to the evaluation of conditions I doubt I can be helpful to your problems with negated "User has role(s)" conditions.

I attached the Rule used for testing. Modify the User has role(s) condition to meet your needs.

Hello fuerst,

Thank you for testing this. This is weird as I used your attached rule, selected the role type "non-authenticated", and when creating a new account the message "Rule action fired!" showed on the screen. Users are automatically given role "non-authenticated" via the LoginToboggan module upon creating an account, then later this role is removed after the user validates their account via a link sent to their email.

Could this be a problem with LoginToboggan module of adding the "non-authenticated" role? Maybe, in the order of things, it is added after the rule event is triggered and conditions are checked? If you think this may be the case I will open an issue with LoginToboggan to ask for more details. But from initial testing it just seemed that this "Has Role" condition at event "User account has been created" was not working properly.

I appreciate your kind support.

Interesting: The standard user creation routine puts the Role information as array(rid => rid) (means: key and value are the Role ID) into the User module's $edit array. The LoginToboggan module uses array(rid => TRUE). Since my patch used the value to get the Role ID it failed with the Role added by LoginToboggan.

The attached patch corrects that by using the array key instead of the value to get the Role ID. Please test and tell me if it works for you now.

hello fuerst,

I tested your new patch several times and it now detects the IF NOT has role at account creation.

Thank you very much for looking into my issue.
I really appreciate your hard work!

Nice, thanks for feedback! Please now set this issue status to reviewed & tested by the community to let the maintainer know about it.

setting the status to RTBC

thanks again for your support!

tested and works great! many thanks

Unsupported operand types in rules.events.inc on line 45 with phpbb integration module http://drupal.org/project/phpbbforum

when existed user in phpbb synced to drupal accounts and of course rules used
works ok

#29: You are obviously using an unpatched rules.events.inc. Line 45 there contains code which can trigger that kind of error. Please open a new bug for this since the error is not related to this issue.

Note: The line in question is $edit['roles'] += $account->roles. If $account->roles is not set or is not an array the error mentioned above will occur. It can be avoided by using typecasting like this: $edit['roles'] += (array) $account->roles

Is #29 a problem in committing this patch? If not, would it be possible to see this in the latest dev?
Thanks!

Committed patch from #24, thanks.

If NOT still does not work
I had to reverse the condition to make it working.

The exactly same conditions / action works without any problem with the account update event.

Please don't reopen year-old issues. Make a new issue and reference any related ones.