Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#5 | user_import_no_password_mapping-1567508-5.patch | 508 bytes | foopang |
#1 | userimportest.txt | 1.5 KB | kruser |
Comments
Comment #1
kruser CreditAttribution: kruser commentedOn 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?
Comment #2
kruser CreditAttribution: kruser commentedthis is happening in alpha4 as well.
Comment #3
zarkinfrood CreditAttribution: zarkinfrood commentedIs 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
Comment #4
kruser CreditAttribution: kruser commentedI 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.
Comment #5
foopang CreditAttribution: foopang commentedI 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.
Comment #6
kruser CreditAttribution: kruser commentedThanks for the patch! It definitely fixes the problem. I ran quite a few tests and can't reproduce the error any longer. Nice work!
Comment #7
franzPlease use soft tabs (spaces)
Comment #8
twistor CreditAttribution: twistor commentedhttp://drupalcode.org/project/feeds.git/commit/db50dc5
Comment #9
twistor CreditAttribution: twistor commentedComment #10
franzDoes 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.
Comment #11
bjorn2404 CreditAttribution: bjorn2404 commentedIs 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.
Comment #12
franzbjorn2404, would mind investigating then? People tested this earlier and reported it fixed the problem.
Comment #13
bjorn2404 CreditAttribution: bjorn2404 commentedNevermind 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.
Comment #14
franzGoing back to D6. Some manual testing should verify if any porting is really needed.
Comment #15
twistor CreditAttribution: twistor as a volunteer commented