Mapper for user password

Is there an option for this in the works?

There isn't.

Postponing this issue. Feel free to set to active if you'd like to work on this.

would love to have this too. Is it somehow trickier than just the username or email field?

subscribe

See attached patch. Only works if pass is plain text.

Due to the way user module md5s ->pass no matter what, would be a little extra to do an additional update after insert to manually update an md5 encrypted pass.

If theres any demand for that ping me. For now all i need is plain text.

Awesome timing -- thanks!

Seems like this has not been ported to D7 version.

subscribing and +1 for d7

Patch from #5 updated for Feeds 7.x-2.0-alpha3
Same file, same code, different line numbers... seemed to work in my basic testing.

Don't Use This File, See Following Comment
Sorry folks, forgot I was on my own site git repository and not from the Feeds git. This file isn't Drupal standards compliant (although it should work if your site is in Git and Feeds is in sites/all/modules/contrib/feeds

Updated patch using the git 7.x-2.x branch of Feeds. Previous patch file was incorrectly generated.

Automated test failing because there's no feeds_test... seems like an issue with the automated tester and not this patch. Setting back to 'needs review' for actually reviewing and testing.

Edit:
For those who don't want to apply a patch, you could simply create a module with this code in the .module file:

function HOOK_feeds_processor_targets_alter(&$targets, $entity_type, $bundle_name) {
  if ($entity_type == 'user') {
    $targets['pass'] = array(
      'name' => t('Unencrypted Password'),
      'description' => t('The unencrypted user password.'),
    );
  } 
}

Where HOOK is the name of your module

@willieseabrook

Your patch in #5 works great, but I'm also quite interested in a solution for importing already md5'ed passwords. You seem to be hinting for a solution. Would you care sharing it?

Thanks.

Had a try at the problem myself and came with the following solution, wrapped in a small custom module.

<?php

function MODULENAME_feeds_processor_targets_alter(&$targets, $entity_type, $bundle_name) {
  if ($entity_type == 'user') {
    $targets['md5pass'] = array(
      'name' => t('MD5\'ed password'),
      'description' => t('The already MD5\'ed user password.'),
      'callback' => 'first_benefit_feeds_password_support_set_target',
    );
    $targets['pass'] = array(
      'name' => t('Plain text password'),
      'description' => t('Plain text password that will get encrypted by Drupal.'),
    );
  }  
}

function MODULENAME_set_target( $source, &$entity, $target, $password_hash){
  // Saving password hash in the entity
  if (empty($password_hash)) {
    return;
  }
  $entity->feeds_imported_md5_hash = $password_hash;
}

function MODULENAME_user_insert(&$edit, $account, $category) {
  // Force the saved MD5 hash to the user after the user has been inserted and the UID is known
  
  if( isset( $account->feeds_imported_md5_hash ) ) {
    require_once DRUPAL_ROOT . '/' . variable_get('password_inc', 'includes/password.inc');

    // Lower than DRUPAL_HASH_COUNT to make the update run at a reasonable speed.
    $hash_count_log2 = 11;

    $rehashed_hash = user_hash_password( $account->feeds_imported_md5_hash, $hash_count_log2 );

    if ($rehashed_hash) {
      // Indicate an updated password.
      $update_hash  = 'U' . $rehashed_hash;
      db_update('users')
        ->fields(array('pass' => $update_hash))
        ->condition('uid', $account->uid)
        ->execute();
    }
  }
}

The tricky part was to actually get the MD5'ed password converted to the new Drupal 7 hash.
That part of the code is based on the user_update_7000 code available here: http://api.drupal.org/api/drupal/modules--user--user.install/function/us...

This is not a patch for the module and it is not tested outside of my own requirements.
Hope this can become a base for a solution.
If the maintainers of the module would like me to try writing a patch, I don't mind trying (not much experience)

Subscribe. #12 look good to me; I'm planning on putting it through its paces on 1,700 users tonight, but it should be RTBC.

I used #12 on an import of 14000 users without any hiccups. I'd say RTBC as well

Worked like a charm.

This should probably add some kind of test to FeedsCSVtoUsersTest to ensure it works properly.

#21 passes locally, so committing to Git: http://drupalcode.org/project/feeds.git/commit/b9dd6a0

Committed and manually tested on 6.x-1.x: http://drupalcode.org/project/feeds.git/commit/5e9dedc