We re-import users on a weekly basis to update their contact information, there is NO password mapping. When importing users from a csv, with replace existing checked, the data gets mapped correctly, but the passwords for existing users are mysteriously changed to something else.

I have no idea why it's changing them since the password field is not mapped or what it's changing the passwords to since they are encrypted.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kruser’s picture

Priority: Normal » Major
FileSize
1.5 KB

On a fresh install, I ran a test for updating existing users, mapping just the username and email address and it is still changing the passwords. Any idea how to stop it from changing the passwords?

kruser’s picture

Title: User import is replacing passwords » User import is incorrectly changing passwords

this is happening in alpha4 as well.

zarkinfrood’s picture

Is there a way to set the password on import to begin with?

This makes me think so, if the field is getting touched on the import

kruser’s picture

I believe you can import/map a password column for a user import, but in this case we're not mapping it and it's changing regardless.

foopang’s picture

Status: Active » Needs review
FileSize
508 bytes

I found that when there is no password mapping for existing users. Encrypted passwords for users will be loaded as the password mapping field, then the passwords will be encrypted again when saving.

I tried to patch this issue by removing the encrypted password with user_load() function when no password mapping is provided, so it won't get saved again.

kruser’s picture

Status: Needs review » Reviewed & tested by the community

Thanks for the patch! It definitely fixes the problem. I ran quite a few tests and can't reproduce the error any longer. Nice work!

franz’s picture

Status: Reviewed & tested by the community » Needs work
+++ b/plugins/FeedsUserProcessor.inc
@@ -40,7 +40,11 @@ class FeedsUserProcessor extends FeedsProcessor {
+    	unset($user->pass);

Please use soft tabs (spaces)

twistor’s picture

twistor’s picture

Version: 7.x-2.x-dev » 6.x-1.x-dev
Status: Fixed » Patch (to be ported)
franz’s picture

Status: Patch (to be ported) » Postponed (maintainer needs more info)

Does it really need to back-port? I checked the logic in user_save() and feeds passes only the keys that will be changed + uid,roles,status, going all through the array argument. We could use some testing, but I don't think the bug exist in D6.

bjorn2404’s picture

Version: 6.x-1.x-dev » 7.x-2.x-dev

Is this definitely fixed in 7.x-2.x-dev? I've been testing with some data on version 7.x-2.x-dev and the password always seems to change to something else on update.

franz’s picture

bjorn2404, would mind investigating then? People tested this earlier and reported it fixed the problem.

bjorn2404’s picture

Nevermind on the password - I inherited a site and missed some custom code that was messing that up. However, I did notice that if I have an additional role selected in the settings it is overwritten on update. For example, on first import the correct role is selected but on an update the additional role is gone.

franz’s picture

Version: 7.x-2.x-dev » 6.x-1.x-dev
Priority: Major » Normal
Status: Postponed (maintainer needs more info) » Patch (to be ported)

Going back to D6. Some manual testing should verify if any porting is really needed.

twistor’s picture

Component: Feeds Import » Code
Issue summary: View changes
Status: Patch (to be ported) » Closed (outdated)