Export users

You can try:
http://drupal.org/project/backup_migrate
and choose only users table.
Check:
http://drupal.org/project/user_import
for importing
http://drupal.org/project/views_bonus
for exporting

See as well:
http://drupal.org/project/uuid_features

Exporting user information is tricky because it needs to be done in a super secure way. In general, it's not great practice to commit things like passwords (even hashed ones) to version control, so I'm tempted to "won't fix" this feature in favor of other solutions.

If somebody have access to filesystem, probably this person has access to database as well and can read all the passwords.
Even if this person has no access to database, but only to file system, it's easy to add to index.php: db_query("SELECT * FROM {users}"); to get the same data which is exported.
So I don't see here any non-secure method of exporting.

when using user_save() you can't pass a hashed password in and *not* have that hash get hashed, so including password really can't happen w/o some technical work-arounds.

that being said, it does make a lot of sense to have an exported list of users that get recreated to do things like sanitize data from another environment, or ensure that certain developer accounts exist only on certain environments.

attached is a patch that adds user-uuid exportable support.

hope this helps!
-Chris

note that due to a bug in UUID's ability to save new users with a uuid, in order for the patch in #5 to function you must use the 6.x-1.x version of uuid and not the 6.x-1.0beta release.

-Chris

I don't think exporting passwords is a great idea. They aren't really portable across sites as of Drupal 7, and may not be portable in Drupal 6 depending on what password hash mechanism is used.

I suggest that this module not try to handle the password nor data column. The data column can contain a bucket of things that might be sensitive.

OR, this patch could have an option to handle passwords and the data column, but turn that off by default. Then during import it could check for this and, if they don't exist, insert a new random password.

@greggles, I totally agree, the patch should already be excluding both password and data fields. beyond your reasons for the data field containing sensitive info, it contains very non-static information that would cause the feature to essentially always be marked as overridden; not a desired thing to have happen.

I like the idea of adding a setting for allowing for random passwording or something to that effect. I feel that this functionality would most likely be applied to dev/testing/qa env's where password security after sanitization is relatively a non-issue, so even allowing the password to be set to a fixed value is probably ok as long as the user can specify it.

Here is a patch for the 7.x-1.x version of the module from the BADCamp 2012 Commons sprint for exporting users.
It seems to be working quite well but does need testing to ensure the majority of use cases are covered.
It does work with exporting existing users and updating their information if it has changed from the last time.
Roles also work when imported if they exist already.

Please take a look and let me know how it works for you.

One thing that needs a bit of work is some logic on determining an existing user. Using the UUID only results in potential unique conflicts on the name and mail fields. I was testing with a fresh install and the UUID on the admin account was different than my first export, highlighting the issue.

I have been thinking about potential workarounds and testing on all three using a first match principal.

1. UUID Match = update existing user
2. name Match = update exiting user
3. mail Match = update existing user
4. None of the above match = insert user account

The potential for importing users where a name/mail already exists is pretty high. This could mean overwriting a real account and at the very least causing some confusion. User accounts in this way are quite a lot different than content as the only unique fields on nodes is the nid.

Thoughts?

In the next patch I am going to be removing the $user->data field from being exported as well, let me know if there are any others that need pruning.

Cheers,
Gord Christmas, Acquia Technical Account Manager

Thanks, codexmas!

I exported a test feature with some content and a user, and it appears to error out because it is trying to save the already existing user:

Notice : Undefined property: stdClass :: $ uid
PDOException : SQLSTATE [23000]: Integrity constraint violation: 1062 Duplicate entry 'bob' for key 'name': INSERT INTO {users} (uid, name, pass, mail, theme, signature, signature_format, created, access, login, status , timezone, language, picture, init, data, uuid) VALUES (: db_insert_placeholder_0,: db_insert_placeholder_1,: db_insert_placeholder_2,: db_insert_placeholder_3,: db_insert_placeholder_4,: db_insert_placeholder_5,: db_insert_placeholder_6,: db_insert_placeholder_7,: db_insert_placeholder_8,: db_insert_placeholder_9,: db_insert_placeholder_10,: db_insert_placeholder_11 ,: db_insert_placeholder_12,: db_insert_placeholder_13,: db_insert_placeholder_14,: db_insert_placeholder_15,: db_insert_placeholder_16); Array ([: db_insert_placeholder_0] => 70 [: db_insert_placeholder_1] => bob [: db_insert_placeholder_2] => $ S $ DYgK9vatZnDNWlflUnVAYDd.myXkAXsptfWz.TpLQfk1srKfaHGY [: db_insert_placeholder_3 ] => bob@example.com [: db_insert_placeholder_4] => [: db_insert_placeholder_5] => [: db_insert_placeholder_6] => filtered_html [: db_insert_placeholder_7] => 1351117016 [: db_insert_placeholder_8] => 1351556449 [: db_insert_placeholder_9] => 1351522827 [: db_insert_placeholder_10] => 1 [: db_insert_placeholder_11] => America / New_York [: db_insert_placeholder_12] => [: db_insert_placeholder_13] => 0 [: db_insert_placeholder_14] => bob@example.com [: db_insert_placeholder_15] => b: 0; [: db_insert_placeholder_16] => 0fa2aeb3-2ab7-419c-8f46-a0f224a9f9d3)

Bumping to the 7.x branch.

On a site without the content or user, I tested the feature I created in #11 and get this error at admin/structure/features;

EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7565 of /Users/ezra/Developer/htdocs/dev/acquia/commons_nightly/commons/nightly-3/includes/common.inc).

Here's the test feature I created.

Ezra, this appears to be an issue with how OgBehaviorHandler.class.php function og_group on line 1656:

if (is_object($gid)) {
    $group = $gid;

  }
  else {
    $group = entity_load_single($group_type, $gid);
  }

It isn't testing that an actual entity is loaded and ends up passing:

list($gid,, $group_bundle) = entity_extract_ids($group_type, $group);

Where $group_type = 'node';
and $group = FALSE;

The group has not been imported yet, so it appears this is partly an order of operations issue as well as Og assuming an entity is being loaded and not enough tests being performed.

I have tested patch #9 and it works ok on clean installation of drupal

+++ b/includes/uuid_user.features.incundefined
@@ -0,0 +1,134 @@
+    // Load the existing user, with a fresh cache.
+    $node = node_load($uid, TRUE);

this probably should be $user = user_load();

Other than this I don't see any problems.

Here is rerolled patch.

Here's the rerolled patch that addresses #16. My IDE also found problem where $user should be $account.

I used patch from #18 against the latest 1.x-dev and got this error after a cache clear:

Parse error: syntax error, unexpected '<' in /Users/t/Sites/local-site/sites/all/modules/contrib/uuid_features/includes/uuid_user.features.inc on line 135

@PL_Ron, The re-roll in #18 is in the wrong format. It will need to be re-rolled. @danithica, could you try to re-roll using the p1 format?

Isn't this issue already solved by https://www.drupal.org/node/1973770 ?