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.

Comments

Priority:Normal» Major
StatusFileSize
new1.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?

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

this is happening in alpha4 as well.

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

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.

Status:Active» Needs review
StatusFileSize
new508 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.

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!

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)

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

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.

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.

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

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.

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.