User account update rule doesn't include Profile updates

indeed. It's intended - I don't think it's intuitive that a profile update on another tab is an update of a user?
To fix it, I'd suggest to add another event "Profile is updated" which only raises for categories != 'account' or even for all?

#304728: trigger an event when a user profile is updated marked as duplicate

could this be called using custom php? ui would be easier though

Actually the problem seems to be that there is no event trigger for this.

Fago, I agree "Profile is updated" would be great - the ability to choose categories would be even better.
What about a generic "Form has been submitted" trigger? I dunno.

In the meantime, I used a custom module to alter the user profile form's submit function. But it would be so much better to use Rules for this.

>What about a generic "Form has been submitted" trigger?
see #199210: forms support

>I agree "Profile is updated" would be great
I agree, but what about the 'account' page? Should the event trigger for it too? So it would trigger both "user has been updated" and "profile has been updated" ?

I'd also love to have this functionality. In the meantime, scottrigby - it would be great if you could post relevant parts of your custom module here.

I'm interested too.

I got what I was interested in working. I made a video of it, if that helps anyone else: http://cathytheys.blip.tv/file/2022133 There is likely a more elegant way, but this was good for my first try!

Yeah, I dont have time to rehearse and edit it down to a proper tutorial. :) And in my case, because I'm using the content profile module, my profiles are content...

the solution in the demo only kind of works. I noticed a problem:

#442476: "field has changed" condition evaluates to true even if the field has not changed (cck text field)

hi, so does your method work with the drupal core profile or only profile content ?
thanks for the tutorial :-)

I think only content profile.

I have another site where I use the built in custom profile, and I had to use triggers and actions (not rules) to get notification of changes, and even then, I cannot get notification of WHAT changed, just that something changed.

subscribing...
I need to give the users a role if the fill one simple profile text field (i.e: write your membership number -> role assigned).

Subscribing

try this (It worked fine for me -- I'm using the D6 dev version of rules, it might work with the current as well.)

make a module or put this into an existing custom module (named "mymodule" in the example below):

/**
* Implementation of hook_rules_event_info().
* @ingroup rules
*/
function mymodule_rules_event_info() {
  return array(
    'profile_update' => array(
      'label' => t('User updates profile'),
      'module' => 'Profile',
      'arguments' => array(
		'user' => array (
			'type' => 'user',
			'label' => 'acting user',
		),
		'form_state' => array (
			'type' => 'form state',
			'label' => 'profile form',
		),
	  ),
    ),
  );
}

/**
* Implementation of hook_form_alter().
*/
function mymodule_form_alter(&$form, &$form_state, $form_id) {
	if($form_id == 'user_profile_form') {
		rules_invoke_event('profile_update', user_load($GLOBALS['user']->uid), $form_state);
	}
}

Then I check for a save operation or a modal submission with POST vars (we're using modal as a keyword in our AJAX profile tabs) - you can do this in the rule condition (see attachment) and/or in the hook_form_alter function (above). I'm also checking for a custom role (id=5) for this particular rule.

Since you have access to the POST vars (like which profile tab), you can include them in whatever action you use (simple watchdog log in the attached example). If you need details from the full form object, you can change form_state to form or add it as an additional argument to the hook_rules_event_info function. (Similar with the user object if you need account info also/instead.)

I'm not sure if this is the best way, but it works for us in a case where the AJAX particularly was a problem -- e.g., the new rules form support didn't seem to pick it up when AJAX was used.

Also note - this is for the core (optional) profile module, not the CCK version. @YesCT - you could (and I might if I get time) also call a function that checks to see which fields were updated and report ones of import to you. In my example, however, it would be easy to simply include any of the POST data.

actually, use this attachment, I realized that the form Op is actually "Save" not "save", this one will work either way...

Thanks, I'll have to take a closer look at this. :) -YesCT

Subscribing.

subscribing

subscribing

+1 for a separate "User updates profile" event. However the wording should make clear whether the update already happened or not.

An other way to work around this problem, for simple projects, is to use the "One page profile" module :
account and profile are on the same form and then when you alter profile, you save both the profile and the account, and the "user account details have been updated" rule is called.

Subscribing.

@#17: Please create a patch and see also #23.

Here is a module that sends out notifications when users register AND when they update their profile. Spits out all the profile fields in an e-mail:

User registration notification

Attached is a patch for this. Adds a "User profile details have been updated" event.

subscribe

Created new patches, tested and verified working with 6.x-1.4

lets try these

These patches do work but I'd strongly suggest they be rolled into the Drupal standard as suggested by http://drupal.org/patch/create - It took me quite a bit of fiddling with the patch format to find success.

That said, awesome work. Does exactly what it says.

Great patch! It works good.

I was wondering how i can check only if one profile field is updated. My intention is to send an e-mail to the user if he updates one particular profile field. I tried with 'Textual comparison' and 'Custom PHP code' but that didn't exclude the update of the other profile fields.

Can someone help?

-> FIXED <- with 'Custom PHP code' and some scripting

$werksituatieOud = '';
$werksituatieNieuw = '';
$werksituatieOud = $account_unchanged->profile_werksituatie;
$werksituatieNieuw = $user->profile_werksituatie;

if (($werksituatieOud == 'Ik zoek een job!') && ($werksituatieOud != 'Ik ben niet (meer) op zoek'))
{
if (($werksituatieNieuw == 'Ik ben niet (meer) op zoek') && ($werksituatieNieuw != 'Ik zoek een job!'))  { return TRUE; }
}
else { return FALSE; }

Greets,
Gunther

I tried #31, and they work great!
One slight modification for rules.events.patch is to remove the following line:
\ No newline at end of file

#36 takes this feature to the next level by allowing per profile field update notifications - which would help solve #1050232: Only display updated fields in mail

I've successfully patched with #31 by rjdjohnston and combined the two separate patches to one using diff and finally git. Hopefully this version of the patch will pass the test.

I have a rule that should be fired when user updates his account details.
It is not fired if only profile fields are modified.
Tested the patch #39 but nothing changed.

Sorry, I didn't noticed you introduced a new trigger event specific for profile updates.
Using this, the rule is fired correctly! Thanks!

This thread only covers a trigger for submission of the profile form, it would be nice to see it include conditions on changes to a single profile field or any profile field. This was the code from a custom module that supplied the event trigger and the conditional to check for any change to any field in the profile category. I couldn't seem to get the category to be passed to the actions, so I had a static cache function to record this.

/**
 * Implementation of hook_rules_event_info().
 *
 * Also see plpt_user() 'update' and 'after_update' operations for the code to
 * trigger this event.
 */
function plpt_rules_event_info() {
  return array(
    'plpt_user_update_profile' => array(
      'label' => t('User profile account details have been updated'),
      'module' => 'PLPT',
      'arguments' => rules_events_hook_user_arguments(t('updated user')) + array(
        'account_unchanged' => array('type' => 'user', 'label' => t('unchanged user')),
      ),
    ),
  );
}

/**
 * Implementation of hook_rules_condition_info().
 */
function plpt_rules_condition_info() {
  return array(
    'plpt_condition_user_category_comparison' => array(
      'label' => t('Compare two users profile fields'),
      'arguments' => array(
        'user1' => array('type' => 'user', 'label' => t('User account 1')),
        'user2' => array('type' => 'user', 'label' => t('User account 2')),
      ),
      'help' => t('Evaluates to TRUE, if both given user accounts are the same for the given category.'),
      'module' => 'PLPT',
    ),
  );
}

function plpt_condition_user_category_comparison($user1, $user2) {
  $result = _profile_get_fields(_plpt_user_category());
  while ($field = db_fetch_object($result)) {
    $key = $field->name;
    $str1 = (string) $user1->$key;
    $str2 = (string) $user2->$key;
    if (strcmp($str1, $str2) != 0) {
      return FALSE;
    }
  }
  return TRUE;
}

/**
 * Stores the editable category
 */
function _plpt_user_category($cat = NULL) {
  static $_cat = NULL;
  if (isset($cat)) {
    $_cat = $cat;
  }
  return $_cat;
}

/**
 * Implements hook_user().
 */
function plpt_user($op, &$edit, &$account, $category = NULL) {
  static $account_unchanged;

  switch ($op) {
    case 'update':
      $account_unchanged = clone $account;
      profile_load_profile($account_unchanged);
      break;

    case 'after_update':
      if ($category != 'account' && function_exists('rules_invoke_event')) {
        _plpt_user_category($category);
        rules_invoke_event('plpt_user_update_profile', array(
          'account' => &$account,
          'account_unchanged' => $account_unchanged,
        ));
      }
      break;
  }
}

Since Profile is optional, I would suggest that this code best lives as a submodule that has the profile module as a dependency. This way, you do not need any function checks on any of the profile related function calls. However, an generic user update (aka submission) event that includes the category would be best left in the core rules module.

Cheers
Alan

Hello,

The patch in #39 works well for me. I had a look at the code and it makes sense.

While I agree with the approach of #44, it is not consistent with the way the rest of the rules user events system works ; so unless we want to do a re-write, I think #39 is what makes most sense.

The reason it fails the test is because it cannot detect for sure that the patch applies to the root of the module ? I'm a bit unsure why that is, as the error message does not explain how it works - anyone knows how to fix the patch so it goes through the test ?

Thanks,
Alice

Patch needs a re-roll the patch so the test bot can ran.

Also, in the meanwhile development moved to 7.x-2.x. When adding a new feature like that, we need to make sure it works for 7.x first. Then we can backport it to 6.x.

The patch of #39 works. Thank you!

What's the status of this issue?

If the Rules maintainers want this functionality to exist as a separate module, I will create a new project using the code from http://drupal.org/node/658504#comment-3241944

Attached patch is for 6.x-1.4

I used patch from #39 and added a profile field condition to check for value changes. This makes the event more useful.

I moved the event into 'Profile' section. The conditions are in separate files profile.rules.inc and profile.rules_forms.inc

By installing the token_profile module you can also compare profile field values using the rules text/boolean/numeric compare condition.

In checking for date values as #658504: Profile fields conditions and actions implemented I reported (token_profile) #1488574: token_profile does not explode profile date field into year, month, day parts.

Patch from #49 lacked test for unset values for ie the unchanged user profile values. Patch fixes for that omission.

clemens.tolboom, the patch should be for 7.x-2.x according to fago's comment in #46.

#39: rules-profile-event.patch queued for re-testing.

sorry did'nt intend to change anything!! my mistake.

Is it possible for this patch to be ported to drupal 6 easily?

50: rules-profile-field-change-363682-50-6.x-1.4.patch queued for re-testing.

Not sure how this got marked rtbc, it doesn't seem to be ready?

Wow 1.5 years further. It was for D6 ... should it now be bumped to D7 or D8

Drupal 6 end-of-life was more than two years ago - there will be no new feature in D6 Rules, and D6 Rules is no longer supported.

That said, this could go into Rules for D7 or D8 if someone is willing to contribute code or fund the development of this feature.

Maybe a Won't fix if bumped up to 7.x? Profile module is hidden from new D7 installs from memory isn't it?

Right, in D7 the core "Profile" functionality is just being able to add fields to the user entity, so all the normal core Rules events are available for changes to that entity.

@fago seemed to think it was a good idea to differentiate between changes to the user account and changes to the profile fields, but maybe that's just because they were separate things in the D6 UI. I don't know.

While going through the Rules issue queue, I left this open because a lot of work had been done and it's not clear to me that this issue is irrelevant for D7. I hesitate to close issues unless I'm certain the issue has been resolved or is outdated, and I'm not certain here. But it definitely is not going to be fixed for D6, so I just moved it to D7.

Since you've participated in the issue and have a better grasp of the problem it's trying to solve, I leave it to you to decide whether this should be "Closed (outdated)", or "Closed (won't fix)", or whether there's still something in here that would be useful for D7.