If the "track" option for duplicate email addresses is set, then on initial import any incoming account with an email address already in Drupal's users table is pointed to that account, which is not changed. This is as intended.

However, when reimporting users (using --update, or highwater marks indicating changes), every previously-imported account obviously matches an email address already in the users table, and we go through the same logic, so any changes in the source data don't get propagated to Drupal even when they should.

The simplest answer to this would be to check $row->migrate_map_destid1 against $user_by_email->uid and if they match allow the record to be updated. More generally, however, I think the checking should be done in prepareRow() and the status returned as ignored (while still setting the destid appropriately), so we don't do a user_save() when we don't want anything to change - although the existing fields are copied so theoretically the same values are saved again, this feels fragile to me (not to mention the wasted time).

Comments

mikeryan’s picture

Priority: Normal » Major

And... The way matched user accounts are resaved in the current code blows away user passwords. We definitely need to do an IGNORE in the match case.