Hi fago,

After about 1h30 of research for a bug in my code, I finally figured it out!

The Drupal user_save() function will call the 'insert' operator BEFORE saving the $data. That way, you have a chance to modify the $edit variable which may include more data by the time the invoke() returns.

You do handle a special case for the user roles.

This is great, but it won't work for other type of data. I'm working on TACL integration and I need to add stuff to the $edit so it gets saved in the data field of a newly created user.

I propose to pass both variables: $account and $edit as follow:

rules_invoke_event('user_'. $op, array('account' => &$account, 'edit' => &$edit));

At this time, you only offer $account. The $edit is used by the 'insert', 'update', and 'after_update'. In all cases it should be editable.

Then maybe we could fix the special handling of the role, although that's not so bad the way it is.

The another way would be to allow users to define $account->data and copy that in the $edit variable on return. Much simpler since that works without having to add a new variable all over the place. The following is what I added in function rules_user(). I tested and it works great. (I put it after the test for the roles, maybe before would be better?)

    if ($op == 'insert' && is_array($account->data)) {
      foreach ($account->data as $k => $v) {
        $edit[$k] = $v;
      }
      unset($account->data);
    }

Thank you.
Alexis Wilke

Comments

fago’s picture

Component: Rules Core » Rules Engine
Status: Active » Closed (won't fix)

hm, the problem is how user data is saved - this is really cumbersome. So actions that want so save users, have to do it on their own. The fix with the roles is there, as else the roles would be overwritten, probably it behaves the same way with the data. However as there is no useful action for it, I don't think we should add such another hack to rules itself. I'd not suggest to use these "data" field either. I think it got removed in d7 (I'm not sure though).