Port Of User Import to Drupal 6.x

For a project I needed user_import for drupal 6, so I made the port myself.

As you can see it's not only a port, but there are also some new features.

- Cron function is expanded to auto-import
- Added fields (language, delete, role)
possible to set Delete field yes / no
- Fixed update profile_values

The patch is against 5.x.2.x-dev.

Edit: attaching patch. :)

Cool, but, Am I crazy? I don't see the patch.

Where is the patch? This would be very helpful.

Great, there is the patch. Thanks, DenRaf

I don't have the ability to patch files on my server :(

Does anyone have a patched module they can send me - would be msot grateful!

Many, Many thanks,
Gareth

patch module

Marvellous - thank you so much!

Gareth

EDIT:

I've now used, and can confirm that it works fine - better than fine as it allowed me to split the load across different roles, great!

Two slight errors:
The version reported inside Drupal is still 5.2.
Saving the settings, and restoring them does not match all the fields with the same fields.

I will report these as separate issues later.

Many thanks again,
Gareth

any plans to commit this to HEAD or a new DRUPAL--6 branch?

Does this module remove the periods from user names? I'm importing user names that look like this in the csv:

Mr. Jones

but they end up looking like this:

Mr Jones

Any way to fix this?

Hello,

I notice a strange feature with this patch, as the Access Denied error is displayed and two copies of the Drupal site are printed on the User Import page. Has anyone else noticed this bug, and if so, is a patch for it being developed and likely to be released in the near future?

Thanks.

Hello,

The above reported error (double printing of the Drupal site) only occurs when the current user has not been given the associated permission, and the Access Denied page is displayed. Could a reason for that be given, as well as a pointer into where it actually occurs, so I could work to correct that myself.

Thanks.

Thanks, coupet, #6 worked great for me.

Michelle

This 6.x version works well for me and I am very thankful that there is a 6.x version, even if it experimental. I hope there will be a branch soon.
I'd like to report that I get a few error messages on cron runs:

* The selected file could not be copied, because no file by that name exists. Please check that you supplied the correct filename.
* warning: Invalid argument supplied for foreach() in /home/crkrmei/public_html/eliot/sites/default/modules/user_import/user_import.module on line 1717.
* warning: fgetcsv() expects parameter 1 to be resource, boolean given in /home/crkrmei/public_html/eliot/sites/default/modules/user_import/user_import.module on line 1357.
* warning: fclose(): supplied argument is not a valid stream resource in /home/crkrmei/public_html/eliot/sites/default/modules/user_import/user_import.module on line 1449.

The culprit is a missing user_import.csv that I have never seen. I go to the admin/user/user_import and delete the user_import.csv task and when I run cron, it comes back again. I don't understand what the module is doing with this file, which user_import_cron looks for:
$file = variable_get('user_import_file', 'user_import.csv');
this variable is never set elsewhere.

This patch module displays 5.x-2.x-dev, is that correct for use with drupal 6 ?

@darumaki - Yeah, the .info file is just wrong. It works fine.

Michelle

Here is a new patch. It updates the .info file and also fixes the cron job.

The hook_cron has now an extra feature of auto importing a specific file: user_import.csv.

This patch is against head.

I know this is simple, but I'm new at this so bear with me...

I'm having trouble running the 'user_import_6.x.1.patch' file. I don't have shell access on my site (shared hosting), so I'm patching locally using cygwin. I put the patchfile in a copy of the 'user_update' directory that I copied off my site and run 'patch -p0 < user_import_6.x.1.patch'. It always fails, saying it can't find the files specified (usually on line 9). I've tried omitting the '-p0', or using '-p1' etc. but it still fails.

What does 'this patch is against head' mean? I assume this would indicate I've got to put the patch file in a different place, or something like that... maybe?

Thanks for your help. It's painfully obvious that I'm trying to figure this out as I go along, but I'm learning a lot and everyone is very helpful.

Evan

I don't have the ability to patch files on my server either.

Does anyone have a patched module using the user_import_6.x.1.patch that they can post?

Thanks heaps,
Alex

Here is a tar package.

that tar package when downloaded is a file ? or is it suppose to be the patched module

(this in response to #20)

Hi.

Thank you very much for your efforts and sharing this with us. I could not get the user_import from the tar package to work. The module is correcty recognized in Drupal and "loads", but the field matching selectors were empty and import options (options, role assign, group assign...) were not displayed. However, let me say that even though I'm running a pretty default installation and I'm (generally) not the stupidest newbie around, I am totally new to Drupal. So there might be a mistake on my part.

On the other hand... the downloaded module for Drupal 5 patched with coupet's patch from above seemingly worked beautifully (successfully imported from the included sample file)

regards,

Applied

I have upgraded from the d6 patched module (post #6) to the patched version posted in #20. The cron errors with 'user_import.csv' seem to be fixed.
However when I nav to admin/user/user_import there is a script that stalls or something, producing this error:

"A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
Script: http://www.nydac.org/beta/misc/jquery.js?O:13"

I have recently upgraded from PHP4 to PHP 5.2 if that is of any help.

Any ideas?

Thanks,
Evan

To the module maintainer -- what support/feedback do you need on this patch to either commit it, indicate specific areas for improvement, or reject it as unsatisfactory?

I'm glad to devote some resources into review/polish, but before we dedicate resources to this I want to be sure our work dovetails with your development plans.

So, anything specific you have in mind for this? How can we help?

Thanks,

Bill

The version from #20 worked fine for me after changing lines 44 and 45 in supported/user_import.inc to

'!login_uri' => url('user', array('absolute' => TRUE)),
'!edit_uri' => url('user/'. $account->uid .'/edit', array('absolute' => TRUE)),

I wish this version of the module for Drupal 6 could be put into CVS because then creating patches would be easier.

Thank you VERY much for this great import module for version 6.x - knowing that this is still a DEV version.

I am experiencing that the import module does not allow for special characters such as è, é, ü, ñ ... Is there a workaround this problem OTHER than editing all these users by hand ?

In addition I am experiencing that some of the imported users get a number 2 added to their names - an addition that I cannot seem to find the logic of. The number is not added due to double user names.

Agreeing with Gustav, I look forward with great anticipation to a clean non-patched user import module, as I am not able to work with patches.

Thanks,

Svend

I am facing problems similar to the ones in post #26. Underscores in usernames are converted into spaces and a digit (2 or 3) is added to certain usernames. All user names and email addresses are unique. Is there any work around for this? Any help/hint will be greatly appreciated.

Thanks,

Guess logic has been found...

It turned out in fact that my data DID contain twin user names. What happened subsequently was that the following users were added a digit-2 after their user names as well.

When I uniformed my data making sure that no records used the same user name combinations together with emails my user import worked fine as to NOT adding the digit-2 to the user names.

In short, if the user import finds twin data sets it simply adds a digit-2 to the record in question and keeps adding the digit-2 to remaining data sets.

---

Has anyone found a solution to adding record sets with special characters such as è, é, ü, ñ ?

when patching the user import, wuth 6.x.1 I have to delete the pach 6.x.0 or I leave it into folder?

I would agree with applied_micro on this one... I had used the patch on the drupal 5 version on a test installation and I was able to load a test csv file. However, when I came to upload from a production installation, I could not get it to work.

Now I've tried the Drupal 6 version from this tar package, but I get the same problems applied_micro had .... I get a full listing of the entire file (and last column is combined with first column of next entry); I get no field matching selections (and besides, why would I bother with this module given that I seemingly have to go down the entire list and do this....)

So, I'm not sure who's supporting this module but I would really love some help. This was a great module and I am in great need of getting it to work on my new Drupal 6 installations. In the meantime, I'll try to backtrack to see why it worked before and why it's failing now.

ADDITIONALLY, after a failed test, I received this warning:

warning: unlink(sites/all/modules/user_import/NAMEOF.csv) [function.unlink]: Permission denied in /var/www/vhosts/MYSITE/httpdocs/includes/file.inc on line 435.

UPDATE: So I went backwards.... I loaded back up the 5.2 version with the patch. I got it to work BUT I discovered several issues.... ONE, it is not clear that the csv file being uploaded HAS to be a windows.csv file. If you save your file as a windows csv file it works fine.
TWO, there is a mysterious number that appears at the end of the usernames after you load them. As near as I can figure out, the module is determining a match when there isn't one and is introducing a number to differentiate the new usernames... THIS is terrible. I have been unable to fix this.

Any thoughts out there?

thanks
gg

gg

Thank you, thank you, thank you! This module saved me some much time.

I'm getting no values in the Drupal fields dropdown. Anyone know why that might be?

I'm a newby when it comes to Drupal module hacking, but maybe someone with more experience can use this as a starting point...

I'm getting the same problem as sprugman (#32). Just poking around in user_import.module, I see that it's possible to force the Drupal fields dropdowns by inserting this code around line 1666:

$usertemp =  array(t('-------------'),t('name'),t('pass'),t('user-email'),t('firstname'),t('middlename'),t('lastname'),t('avatar'),t('volunteer'),t('fieldclass'),t('studioclass'),
t('member'),t('programs'));

(all the t('whatever') strings are fields I set up using Drupal's profile module)

And then, about 20 lines below that, swap out "usertemp" for "user_fields" in the following:

    $form['field_match'][$row]['field_match'] = array(
          '#type' => 'select',
          '#default_value' => ($import['field_match'][$row]['field_match']) ? $import['field_match'][$row]['field_match'] : $user_fields[0],
          '#options' => $usertemp,
      );

This causes the drop-downs to appear, but it still doesn't work past that point. I get an error message telling me that one of the fields has to provide the email address, but I can't get the right string (email, e-mail, user-mail, user-email), to get past that error message.

Any more experienced Drupaler have any suggestions?

Also, there's this suspicious-looking line around 1062:

      $user_fields["$type-$field_id"] = $label;

To my newby eyes, the stuff inside the square brackets looks suspicious... but I don't know how to fix it if it is.

Seems like the right status - could any one take charge here and get this to RTBC? Then we can bug Robert to finally commit it.

confirmed working:

use the version from comment #6: http://drupal.org/node/267761#comment-894895

( comment #20 doesn't work: http://drupal.org/node/267761#comment-959929 )

I too was affected by the appending of "2" to some usernames. I could not find a good explanation.
Splitting the imports into smaller chunks seemed to help, and I'm done with this for now.

I need this module to import some users into a Drupal 6 installation, but found that I had to combine imput from several comments to get what appears to be the current status of this DRUPAL6-compatible test-version.

I found a trivial typographical error and corrected "absulute" to "absolute".

For the benefit of the module maintainer, I have re-rolled a cumulative diff from the current HEAD checkout using the "cvs diff" command, as required by Drupal patch guidelines.

For the benefit of those who don't know the difference between "checkout" and "download", here is how to reproduce the patched module on your hosting server:

ssh $DRUPAL_HOSTING_SERVER
cd $DRUPAL_ROOT/sites/all/modules
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d user_import contributions/modules/user_import
wget http://drupal.org/files/issues/user_import-HEAD-to-v6.diff -O - | patch -d user_import

EDIT: okay, the "cvs diff" command doesn't generate new files, so I've cobbled together a patch that looks like "cvs diff" output, but actually includes the necessary new files and avoids changing the $Id strings.

Imported around 130 users with no apparent problem. Looks good. Changing issue title so it's more obvious that this is the Drupal-6 version.

Tarball and Zip created via instructions from #37 attached.

If just one other person tests this and it works, we should change status to RTBC and start bugging the maintainer.

Grrr!!! Patch doesn't create new files when given a "cvs diff" file, either.

Updated instructions for patching:

ssh $DRUPAL_HOSTING_SERVER
cd $DRUPAL_ROOT/sites/all/modules
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d user_import contributions/modules/user_import
wget http://drupal.org/files/issues/user_import-HEAD-to-v6_0.diff
cd user_import
touch $(grep 'Index:' ../user_import-HEAD-to-v6.diff | cut -f 2 -d ':')
patch < ../user_import-HEAD-to-v6.diff

Incorporated improvements from http://drupal.org/node/174196#comment-866688

Unable to match profile fields from #39 attached.

(Re: #40) -- Dunno; works for me. Could you be a little more specific as to what version of Drupal you are using, and what you did to install this, and what happened, and how that differed from what you expected to happen?

Ref: Drupal 6.4 & module user_import-6.x-dev.tar_.gz or user_import-6.x-dev.zip (Re:40)
Enable profile & User_import & created a few profile fields

During user import:
- csv column, All profile fields are listed ok
- Drupal fields, Only option available is '----' , there is no match? Expected to Match columns in CSV file to profile fields.

Install OK Config options OK.

same Only option available is '----'. Drupal 6.5
Modules from #39

re: #42, #43 -- Weird.

I'm using Drupal 6.x-dev (recent CVS checkout) and it just works. Are you getting any output in your error log? PHP notices? failed MySQL queries?

none on the error logs. Just error msg 'One column of the csv file must be set as the email address." stated in /admin/user/user_import/add/5

I did enabled profile module, and added one field, but nothing it not shown in the Drupal fields. I was using "Content Profile" but already uninstalled

tried fresh drupal 6.5 with clean URL. same result.

Yup. The tarball I uploaded differs from what I'm using. Darn! patch command semantics strike again!

Okay, here's a new set:

CORRECT Instructions for producing patched version from CVS source:

ssh $DRUPAL_HOSTING_SERVER
cd $DRUPAL_ROOT/sites/all/modules
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d user_import contributions/modules/user_import
wget http://drupal.org/files/issues/user_import.cvs.diff -O - | patch -d user_import -p0

re: 47

Parse error: syntax error, unexpected '=', expecting ')' in /home/www/www.drupal6x.com/htdocs/drupal-6t/sites/all/modules/user_import/supporte... on line 45

syntax error fix.

Tested #49 with profiles, works great!

Note:
Option to import picture name into user table not implemented? Extra!

Tested #49 with 6.6 - works fine, thank you.

BUT - works only with zipped file, not with tared. Strange.

Users imported; Profiles values not imported. Settings were saved before Import

* warning: Invalid argument supplied for foreach() in /usr/local/apache/htdocs/sitename.com/drupal-6.6/sites/all/modules/user_import/user_import.module on line 967.
* warning: ksort() expects parameter 1 to be array, null given in /usr/local/apache/htdocs/sitename.com/drupal-6.6/sites/all/modules/user_import/user_import.module on line 985.

few fixes:
- correctly get OG groups
- make sure the default value for OG groups checkboxes is array
- save custom profile fields correctly
- set the user default timezone to the site default timezone
- make contact setting option works

Re-rolled full patch and tarball:

To apply:

ssh $DRUPAL_HOSTING_SERVER
cd $DRUPAL_ROOT/sites/all/modules
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d user_import contributions/modules/user_import
wget http://drupal.org/files/issues/user_import_4.diff | patch -p0 -d user_import

I've used the patch version quite a bit and finally isolated the "2" problem...

If there is ANY duplicates, the module appends the duplicate with the "2" after it to avoid a duplicate. HOWEVER, it then adds the "2" to every subsequent user added. So, in layman's terms, which are the only terms I truly understand, the feature never shuts off.
So what I do now is do some jiggering in Excel say, and examine the user list manually (I alphabetize so it's not as grim as it sounds) and then look for any duplicates. If I find any, I deal with them. Then, when I have a clean list, use User_Import.

Just as a FYI, make sure there are no duplicates on users already on the site. Again, what I do is download a list of users, extract usernames, put in excel file, alphabetize and then look for dupes....

This is, of course, a pain. It would be great if this problem were rectified so that ONLY the actual dupes were given the "2" beside their name and the rest were clean. But as this module is one of those "it takes a village" modules, I'm not sure anyone has the urge to figure it out. I do appreciate, however, ALL the work that's gone on by folks in this thread to make this module pretty functional for 6 and it has saved me a world of time. THANKS

geoff gevalt

few more fixes for user_import.install
- change the data type for errors field in user_import_errors table to longtext as user_import_update_4()
- remove unneeded drupal_uninstall_schema('user_import_errors'); on uninstall

@ggevalt
try this one, it's in user_import.module (patch attached)

function _user_import_unique_username($username) {

  static $suffix = array();
  if (!isset($suffix[$username])) $suffix[$username] = 1;

  if ($suffix[$username] < 2) {
    $duplicate = db_result(db_query_range("SELECT uid from {users} where name = '%s'", $username, 0, 1));
  }
  else {
    $usern = $username .' '. $suffix[$username];
    $duplicate = db_result(db_query_range("SELECT uid from {users} where name = '%s'", $usern, 0, 1));
  }

  // loop until name is valid
  if (!empty($duplicate)) {
    $suffix[$username]++;
    _user_import_unique_username($username);
  }

  // add number at end of username if it already exists
  $username = ($suffix[$username] < 2) ? $username : "$username $suffix[$username]";
  return $username;
}

one more fix, this one for permission denied error when deleting file. That's because the file handle was still open.

This probably fixes #169602: User Import - Unable to delete csv file and #170413: Error while importing some users

@pillarsdotnet
my patch #55 has this

if (!module_exists('og')) return;

it's unnecessary, could you delete that.

Re-rolled patch and snapshots.

Deleted the commented-out section marked "Cruft?"

Changing status because I haven't tested any of this. Somebody please verify this works.

Again, (as if it mattered to anyone but the absentee maintainer), to apply:

ssh $DRUPAL_HOSTING_SERVER
cd $DRUPAL_ROOT/sites/all/modules
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d user_import contributions/modules/user_import
wget http://drupal.org/files/issues/user_import_5.diff | patch -p0 -d user_import

Come to think of it, shouldn't those user_import_update_1() ..4() functions really oughtta be named user_import_update_6001 ..6004() as per developer guidelines?

@pillarsdotnet
I'm not sure but I think we have to leave it like that for people upgrading from 5.x. But the next update should start with the new naming convention like devel module.

futher modification on my local copy
- replace most of drupal_goto() on form submit handler to $form_state['redirect']
- this one maybe need a separate issue:
calling drupal_access_denied() inside user_import_preconfigured function causes user_import page (not user/admin/user_import) rendered in bad state
I changed the logic a little bit by getting the default template_id from global var and just show a message if the default template_id is not set.
edit: I think this one fixes the problem mentioned on #11 above

Also from here http://drupal.org/node/144132#op, $form_values['op'] ($form_state['values']['op']) is deprecated. So maybe we need to seperate the submit and validate handler to separate functions for each op. But I don't know how to tell drupal_execute which op to execute without setting $form_state['values']['op'].

edit:
@pillarsdotnet shouldn't you generate the diff against 5.2 branch so the diff is smaller, just a thought.

@ariflukito -- Was (wrongfully) assuming that HEAD contains the latest code.

Regenerated combined patch against 5.2 branch. Diff is (slightly) smaller.

Again, somebody please test, then change status to RTBC.

ssh $DRUPAL_HOSTING_SERVER
cd $DRUPAL_ROOT/sites/all/modules
cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -r DRUPAL-5--2 -d user_import contributions/modules/user_import
wget http://drupal.org/files/issues/user_import_6.diff | patch -p0 -d user_import

Users are not imported into the Default Role Assign.

The role 'authenticated user' is assigned automatically.

I'm not sure what you mean or what you're quoting from. Could you please elaborate? I didn't even know it was possible to have users in Drupal who weren't members of the "authenticated user" role.

The module worked as a charm for me when importing 1000 users to a D6 site. (I didn't do anything fancy, though.)
Thank you so very much for saving me the work of adding all the users manually. :-)

Thank you VERY much for all your work on this great module - without this module I would still be adding new users to my site...

However, I have one question standing: back in #26 I had trouble with inserting users with special characters such as è, é, ü, ñ ... Does the latest module version take this into account? If so, can I update a current sites users with a new upload - where the user's records get updated with the new information WITHOUT disturbing them with alert system emails?

Changing the title back to the original --

Please do not hijack the thread; create a new issue for your question.

@ pillarsdotnet :

Users can be assigned to role during Import in two ways.
- Specify role in CSV file (Works)
- Default authenticated user (Not working)

Note: the quote is from the Role assign option under the matching fields.

Subscribing.

Subscribing.

@coupet --

So what you're telling me is that if your CSV file doesn't define any roles, your users get imported, but they don't receive the permissions assigned to the "authenticated user" role?

Weird. Like I said, I thought that wasn't possible. At least in my install, it is not possible (neither through the web interface nor by hacking the SQL tables) to revoke the "authenticated user" permissions from any of my users.

Can anyone else verify this behavior? When I did my import (admittedly a few revisions ago!) my CSV file didn't specify any roles, and I don't remember anything like the problem you're describing.

@pillarsdotnet

Reviewing SQL tables, new rows are added as follows:
Table: role
rid name
3 NULL (created by import when role is not specified)

Table: users_roles
uid rid
3 3
4 3
n 3

I think a blank role is created with rid 3 and imported users are assigned to that role.

subscribing

Thanks for all your work on this. It really made it easy to add members to our Drupal site that were being tracked via spreadsheet. The import into profile fields works flawlessly.

My only problem is that the notification emails don't seem to be going out. I created a test user via the regular administration page (admin/user/user/create), and the notification was sent correctly, but no notifications are going out to the imported users, even though I'm importing the Email Address and I have the Send Email option checked and I've filled in the Message Subject and Message fields. Any idea why it might be failing? Has anyone else run into this?

In case it helps, here are the details of the custom message fields.

Message Subject:
Account details for !username at AzLAF.org

Message:

Hello !username,

An account for you at AzLAF.org has been created. This login will be required to access member-only content on the site.

You may now log in by clicking on this link or copying and pasting it in your browser:

!login_url

This is a one-time login, so it can be used only once.

After logging in, you will be redirected to !edit_uri so you can change your password.

Once you have set your own password, you will be able to log in to !login_uri in the future using:

username: !username

--
Russell Keppner
AzLAF Web Administrator

some updates
- stop creating blank roles
- rewrite insert and update queries using drupal_write_record()
- don't reset import history numbers after saving history as template
- schema updated for drupal_write_record(), added new update function that rebuild schema
- more reliable check on user_import_field_match()
- edit info file to only include required info
- some minor fixes

@rkeppner
I don't think mail is working yet. If you see supported/user_import.inc line 61, the call that send the mail is commented out.

ariflukito -- Why don't you ask Drupal admins if you can take over this module? Clearly the module owner is not doing the job.

Unfortunately I don't really have time to maintain this module. I've spent too much time on this and I'm behind on my project now. Also I don't think I'm good enough, I'm still new and still learning. I'm just sharing what I did here and then it's up to the maintainer or anyone to accept it.

subscribing

@pillarsdotnet : thanks so much for producing tars and zips

@arifluketo : what does the patch in #79 get applied against?

thanks everyone!

oh sorry against pillarsdotnet's latest zip

Hi, just want to thank everyone who's put work into the upgrade process, and reassure people that I am working on this.

I released the User Import module in 2005, and have since maintained and updated it for Drupal 4.6, 4.7, 5, and there will be a Drupal 6 version.

User Import module is used on almost all of the sites I work on for clients, so it has sustainable financing for maintenance and updates. Unfortunately that has not worked out so well for the Drupal 6 upgrade, since none of our clients sites will be updated until there is a stable release of CCK and Views.

Note: I am in no way saying anything negative against the developers that have been working hard on CCK and Views, just explaining why development has taken longer than other releases.

I have been concentrating on two things for User Import...

1) adding features that will make it suitable for use by people who manage Organic Groups, so that they can import users into their OG.

2) writing tests so that when I do get to the stage of upgrading the module to Drupal 6 I can run tests to make sure it all works OK, thereby speeding up the upgrade process.

The tests are important for the long term future of this module and will be critical for adding new features and upgrading to Drupal 7 and beyond.

My plan is to finish adding new features to Drupal 5 this month, and get as much test coverage as possible. I'll then work on the Drupal 6 upgrade in December. Once the Drupal 6 version is out the Drupal 5 version will be frozen for anything except security fixes.

The patches provided will be useful as reference, although they may not apply to the 5 version I'll start the 6 upgrade from.

Thanks for the help and patience.

"none of our clients sites will be updated until there is a stable release of CCK and Views."

Huh? Both views and CCK have 2.1 releases for D6. How are you defining "stable"?

Michelle

Michelle: my definition is a final release that has been out for more than a month, specially for a module like Views which is complex and has been re-written from scratch.

The final release may be 100% stable on day one, but a month of widespread use will really kick the tires and confirm that.

The stability of the updated sites is the most important thing, so yes I do err on the side of caution.

Wow! Well, no one can accuse you of being reckless. LOL! Considering there was 22 THOUSAND people using D6 views a month ago, I'm willing to take my chances on my sites. ;)

Michelle

I'm with Robert on this. It makes sense to wait for major releases to bed in for a month before using them on live sites. I usually wait a couple of days even on security updates of Drupal core - I've seen 'final' updates that break the whole thing just a few too many times. Having said that, I'm going to have to do the same with User Import as well now!

Subscribing.

thx for the update Robert I'm very glad to hear that :)

All and @ivtinkle in #92

Here is a tar file with pillarsdotnet's #66 zip with ariflukito's #79 applied

Subscribing

Subscribing - happy to do whatever testing that I can; I'm currently building a new D6 site, and in the process importing a bunch of users from a hand-built PHP-coded legacy system...

I wonder if someone could confirm some things for me. I'm about to use this on a production site as I need help importing users on a daily basis (I'm no database expert).

I've run through all the options turning them on and off with a couple of sample files and have the following problems:

• Password - Even if you match it to the Drupal field it doesn't seem to import it. What's a little confusing is that the Drupal field for email address is 'E-mail address *' so I would expect the password field to be 'Password *' as per the registration form instead it's just 'Password'.
• Send Email - Doesn't send an email out (I expected this from comments above).
• Activate Accounts - Doesn't seem to do anything, the account always appears as blocked.

I'm getting round the above by manually unblocking the accounts which sends out the default email with a one-time login directing people to set their password.

None of the above is a criticism in anyway, I appreciate this is very much work in progress and am looking forward to the official module, but unfortunately I need to use it now so if someone could confirm that I'm not going mad and these things aren't currently working it would be much appreciated.

I'm only getting

-----------
Delete
Email Address *
Language
Password
Role

under Drupal Fields. I'd like to be able to transfer user names, first and last names, gender, phone, address, city, state, zip, country, and password if possible.

Does the fact that I don't have access to these options rely on the previous CMS, because the .csv file I'm importing has all this information and more.

Any help?

It's obvious to me now that I needed to create those fields before trying to import the file.

HOWEVER, is it possible to import Username and Password?

Yes, for username use username column (see attachment)

now with the attachment

Username: The Username will be built from CSV columns in the order selected.

What does this mean exactly? My usernames are under the 4th column of the CSV table, but does that mean that selecting 4 under this drop-down will import those usernames?

It seems suspicious because there are only 4 choices here and "selection order" means that other columns will be selected.

I'm a MySQL noob, so maybe I'm just being paranoid.

So let's assume you have columns user_name, first_name and last_name in your cvs file.
If you want to import usernames as they are choose 1 in the username column for the cvs user_name row. Leave the rest of the cvs fields to no in username column. See the attachment in #100

Now let's assume that you want to create a new Drupal username on import based on the cvs user_name and first_name field (user_name+first_name). You would choose 1 in username column for cvs user_name row and 2 for cvs first_name row. Leave the rest of cvs field rows to no in username column.

Does this make sense?

Yeah, I understand. It's sort of what I expected, just wondered why it was limited to only 4 columns. You'd have to edit the file to get the 5th column of usernames to work to work. No big deal.

Thanks!

Not sure if this is the right place to post this to or not, but after I install upload the module from #93 I receive the following errors:

- When I initially select a .csv file for importing and click the next button this message is generate.

*warning: Invalid argument supplied for foreach() in /mnt/target03/364491/366330/www.cpedatabase.com/web/content/sites/all/modules/user_import/user_impor... on line 1068.

- If I continue on after that I receive the next set of errors.

* Could not find the csv file ''
* Could not get data, the file '' is either empty or has incompatible line endings.
* warning: fclose(): supplied argument is not a valid stream resource in /mnt/target03/364491/366330/www.cpedatabase.com/web/content/sites/all/modules/user_import/user_impor... on line 1045.
* warning: Invalid argument supplied for foreach() in /mnt/target03/364491/366330/www.cpedatabase.com/web/content/sites/all/modules/user_import/user_impor... on line 1068.
* warning: Variable passed to each() is not an array or object in /mnt/target03/364491/366330/www.cpedatabase.com/web/content/sites/all/modules/user_import/user_impor... on line 480.
* One column of the csv file must be set as the email address.

Running Drupal 6.6, am I doing something wrong?

Don't change the title.

Changed it back.

subscribe

@104 I'm not sure what's wrong, maybe your csv file was not formatted correctly. Line 1045 should read if ($handle) fclose($handle); It will just hide the warning.

attached patch to #93
- delete entry from files table after moving file (the query could be better if we use fid for the WHERE clause)
- move watchdog call to supported/user_import.inc since there is no module called watchdog.inc so that file never get included.

double post

I see that there is a checkbox for Send Email which notifies imported members by email of the big move. However, the documentation and wording under the Email Message tab suggest that if nothing is entered into that textarea, a default message will be sent out.

I know this is super paranoid, but should I expect to have any of the members receive and email if "Send Email" is NOT checked? This is really just a test, and I don't want people spamblocking the site when the time comes to ACTUALLY import them.

Thanks!

*receive and email = to receive an email
(second P)

subscribing.
thanks!!!

Subscribing - thanks!

#107 worked fine with Drupal 6.8. Uploaded 2500+ users in one go with 19 profile fields.

One caveat: The CSV file created by Excel on Mac replaced CRLF with CR, I guess; this resulted in out of memory during import, even with upto 1GB max_memory in php.ini. Re-saving the csv file from Excel on Windows fixed this issue; I was then able to import users with the default memory.

Thanks for the great work here.

Can't get it to work here... I downloaded the #107 tar_.gz (should be renamed to tar.gz IMO) and the patch; I then decompressed the tar.gz in a temporary directory, which gave me a user_import/ directory; I put the patch there, so that an ls gave me

tmp $ ls
user_import/ user_import_5.patch

then I did patch -p0 < user_import_5.patch; I got these messages:

patching file user_import/supported/user_import.inc
Reversed (or previously applied) patch detected! Assume -R? [n] y
patching file user_import/user_import.module
Reversed (or previously applied) patch detected! Assume -R? [n] y

to which I answered y. Next I copied the resulting user_import/ to my server, and went to the Administration pages of drupal, and in modules I enabled user_import. The page refreshed and showed

user warning: Table 'm_delente.user_import' doesn't exist query: SELECT * FROM user_import WHERE setting <> 'template' ORDER BY started DESC in /mnt/103/sda/e/4/m.delente/modules/user_import/user_import.module on line 1322.

at the top. When I go to the 'Import users' page, selecting a csv file and clicking 'next' brings me back to the same page, with no further options.

What can I do to correct this? Thanks.

You need to extract the tarball --OR-- apply the patch to CVS sources.

Doing both and answering "y" to the "Assume Reversed?" question gets you back to the unpatched source.

Thanks for your help! However it didn't work... What I did:

I disabled User Import on the Modules page, then deleted the directory on the server. Next I reinstalled it on the server, went to the Modules page again, clicked on "update.php", and chose 6001 for the User Import version. The server told me that the installation was done. I then re-enabled User Import in the Modules page, and clicked the "Register the configuration" button.

But when I go to the "User Import" page, I still have the following messages:

* user warning: Table 'm_delente.user_import' doesn't exist query: SELECT * FROM user_import WHERE setting = 'template' in /mnt/103/sda/e/4/m.delente/modules/user_import/user_import.module on line 1322.
* user warning: Table 'm_delente.user_import' doesn't exist query: INSERT INTO user_import (name, filename, oldfilename, filepath, started, pointer, processed, valid, first_line_skip, contact, username_space, send_email, field_match, roles, options, setting) VALUES ('', 'sample.csv', 'sample.csv', 'sites/default/files/tmp/sample_1.csv', 1230622438, 0, 0, 0, 0, 0, 0, 0, 's:0:\"\";', 's:0:\"\";', 'a:13:{s:6:\"groups\";N;s:21:\"existing_og_subscribe\";N;s:19:\"existing_og_subject\";N;s:18:\"existing_og_markup\";N;s:19:\"existing_og_message\";N;s:15:\"existing_og_css\";N;s:7:\"subject\";N;s:7:\"message\";N;s:14:\"message_format\";N;s:11:\"message_css\";N;s:8:\"activate\";N;s:10:\"subscribed\";N;s:12:\"update_users\";N;}', 'file set') in /mnt/103/sda/e/4/m.delente/includes/common.inc on line 3418.
* user warning: Table 'm_delente.user_import' doesn't exist query: SELECT * FROM user_import WHERE setting = 'template' in /mnt/103/sda/e/4/m.delente/modules/user_import/user_import.module on line 1322.

Any further hints? Thanks!

I don't think you can update modules that aren't enabled.

This is the usual sequence:

• Leave module enabled
• Update code
• Run update.php

But in your case I would recommend a more drastic alternative:

• Disable module
• Uninstall module
• Update code
• Enable module
• (no need to run update.php)

subscribing.

I just imported 2180+ users with the latest listed patch. Time for the maintainer to take some action.

And some proof along with it. ;)

This is a follow-up to message #117.

I tried once again and still had no success.

> But in your case I would recommend a more drastic alternative:

> * Disable module
I went to the ?q=admin/build/modules on my site, and unticked User Import; then I clicked on the button to register the change. I went back to the login page and the « Import users » that used to be on the left side of the page had disappeared.

> * Uninstall module

I logged on to my server with an ftp client, and then removed the user_import directory that was in modules/. I then logged on again as the administrator on my site, and User Import had disappeared from the ?q=admin/build/modules page, so I guess it was uninstalled.

> * Update code

I suppose that means that I need to reinstall the module on the server, in the modules/ directory? At least that's what I did.

> * Enable module

Went back to ?q=admin/build/modules in my web browser; User Import had come back, so I ticked it back on, and clicked on the button to register the change.

Back to my homepage, I had again the « Import Users » link on the left of the page; I clicked on it, and got again this message:

Import Users
user warning: Table 'm_delente.user_import' doesn't exist query: SELECT COUNT(import_id) FROM user_import WHERE import_id = 0 AND setting = 'template' in /mnt/103/sda/e/4/m.delente/modules/user_import/user_import.module on line 582.
There is no default import template configured.

so I guess I still can't use User Import... Any further hints? Thanks!

By "Uninstall module" I didn't mean remove the code with an ftp client.

By "Uninstall module" I mean click on the "Uninstall" button from the module administration page.

@daouverson2 -- Yes, of course HEAD is not compatible with Drupal 6. That's why this issue (and the attached patches etc) exist. HEAD is Drupal 5 code. If HEAD were compatible with Drupal 6, then the issue wouldn't say "Port ... to Drupal 6.x". It would say something different.

#107 worked perfectly for importing 5,000 new users.

However, I've noticed that there's no way to update existing user accounts. Even when the "Update Existing Users" checkbox is checked, I still see the error "User exists and "Update account" is not enabled."

Follow up to #122.

I can't uninstall any modules on my server. Even though User Import appears installed in ?q=admin/build/modules (there is a checkbox just to the left of it in the list, and this chekbox is checked on), when I go to ?q=admin/build/modules/uninstall Drupal tells me that no module can be uninstalled. So I get User Imort was not installed correctly after all but how come?

nonononono. (sigh)

1. Disable the module
   (this prevents the module code from running)
   • Go to admin/build/modules
   • Uncheck the box next to the module to disable.
   • Click the [Save configuration] button at the bottom.
2. Uninstall the module
   (this removes any installed tables and configuration settings)
   • Go to admin/build/modules/uninstall
   • Check the box next to the module to uninstall.
   • Click on the [Uninstall] button at the bottom.
   • Confirm by clicking on the [Uninstall] button again.

Why is sending of mail (user_import.inc line 97) still commented out? And I think it should use "drupal_mail" insted "mail" function.

Hi,

Have tried User Import 6 (head) with :

http://drupal.org/project/content_profile

and will currently only import email, username and password ...

Any possibility of making this work with Content Profile please, as I think it is our main profile module (apart from core profile.module) for Drupal.

Desperately need to import over 14 000 users ...

Look forward to any replies, and thank you.
Lilian

You might look at node_import since content profile stores its profile info as nodes.

Thank you Moshe for your quick reply.

Actually I've posted this before and Robert (the wonderful developer of user_import) responded with the following:

I don't have any current plans to integrate Content Profile with User Import.

User Import is coded in a way that makes it possible to cleanly add integration with other modules, it provides hooks to do this for the user interface and the actual import. I put some time and effort into providing these hooks because there is no way I can keep up with requests to integrate User Import with module X, Y and Z.

This means you can either code that integration yourself or hire a developer to do it for you. The integration should be done in an include file in the user_import/supported directory, look at the other integration files in there to see examples.

Perhaps someone is interested to create the integration? .. I will be most happy to pay for this :) Please send me a quote via my contact form.

Look forward to any reply, and thank you.
Lilian

Looking at the Node Import page it seems that importing into CCK fields is not supported yet for the Drupal 6 version.

http://drupal.org/project/node_import

Lilian, if you have a budget to spend on this I would recommend directing it towards getting CCK fields supported in Node Import, which would then enable you to import Content nodes.

Thank you for your reply Robert!

What I think I'm going to do is import all the users with user_import and then import their details via the node_import, but select the username as 'authored by'. Do you think that will work? Or is there perhaps an easier way?

Look forward to your reply.
Lilian

Update: No, that won't work as cannot import the person's details. It does import taxonomy terms though :)

So basically I'm back at:

This means you can either code that integration yourself or hire a developer to do it for you. The integration should be done in an include file in the user_import/supported directory, look at the other integration files in there to see examples.

Perhaps anyone interested in applying the integration please? Send a quote via my contact form.

Lilian

Lilian, I think the road block on what you are trying to do is that Node Import module for Drupal 6 does not yet import to CCK. fields.

@#10 (http://drupal.org/node/267761#comment-924815)
(Mr. Carpenter - July 16, 2008 - 21:40)

Special characters are removed by function _user_import_sanitise_username() in user_import.module line 1136:

/**
 *  conform to Drupal username rules
 */
function _user_import_sanitise_username($username) {

  // username cannot contain an illegal character
  $username = preg_replace('/[^a-zA-Z0-9@ ]/', ' ', $username);
  // username cannot contain multiple spaces in a row
  $username = preg_replace('/[ ]+/', ' ', $username);

  // username must be less than 56 characters
  $username = drupal_substr($username, 0, 56);

  // username cannot begin or end with a space
  $username = trim($username);
  return $username;
}

to import usernames as they are make sure your csv file is saved in utf8 and hack the funktion like this:

/**
 *  conform to Drupal username rules
 */
function _user_import_sanitise_username($username) {

  // username cannot contain an illegal character
  // $username = preg_replace('/[^a-zA-Z0-9@ ]/', ' ', $username);
  // username cannot contain multiple spaces in a row
  // $username = preg_replace('/[ ]+/', ' ', $username);

  // username must be less than 56 characters
  $username = drupal_substr($username, 0, 56);

  // username cannot begin or end with a space
  $username = trim($username);
  return $username;
}

Maybe the replacement could be turned into a setting.

Or it could be made "conform to Drupal username rules" by directly using the core function user_validate_name()

http://api.drupal.org/api/function/user_validate_name/6

+1

i don't understand why work so much on users_import patch for drupal 6.x when the module http://drupal.org/project/node_import for drupal is just doing the same and much more..

couple reasons

you can't do the following with node import

automatically add users to roles
allow the import to generate a user name
and most importantly import into profile fields

Please, would anyone be so kind as to point me in the direction where a working and already patched file is? Is #107 working?

@daouverson2

really?

I totally missed that then, where in the process?

tx

Following on from #10 & #135

If you want to keep the current sanitisation settings but just want to search/replace certain characters, it's pretty easy.

To keep underscore (_) characters
Modify this line
$username = preg_replace('/[^a-zA-Z0-9@ ]/', ' ', $username);
to
$username = preg_replace('/[^a-zA-Z0-9@_ ]/', ' ', $username);

To keep period (.) AND underscore characters like i needed to in my project.
use
$username = preg_replace('/[^a-zA-Z0-9@\._ ]/', ' ', $username);

@107 post

I created user_import module in drupal 6.x using import.tar patch from http://drupal.org/node/267761#comment-1144165 in comment 107 I am able to enable module and upload csv file in the module but i am not getting any fields name in Drupal fields column but when i click import/test button it is firing any error i.e "One column of the csv file must be set as the email address." .

I am attaching png image .sorry i am unable to upload image so please check it in http://drupal.org/node/267761#comment-1144165 in comment 100 where field name are visible in Drupal fields in image but for me it not getting any field only '-------' values

Please suggest any solution

Thanks.
Test_drupal.

Got the tar.gz from #107 installed, and the "Configure" tab has, under it, "Performance" and "Check Existing Usernames" but nothing there to configure. Known?

What's the expected format of the CSV, or do we sort that out after starting the upload?

Any luck on getting this to email the users? Seems like there should be a logical reason for the line //mail($account->mail, $subject, $body, $header); to be commented out (which seems to be the culprit of emails not going out), but I'm a php newbie and I can't really see how to help fix this.

Thanks everyone for their efforts and for sharing with the community.

Hello,

I've found the User Import tool to be a great foundation to import users.

I'm also using Organic Groups and would like to assign the group of users to their respective groups. I already have the groups created and notice the Group Assign menu. However, I don't see any groups to assign and don't want to assign all of my users to one group.

Does this functionality already exist and if so what am I missing?

I'm using Drupal 6.8 with PHP 5.2.1 on FreeBSD 6.3 and have no user_import module installed. So let me see if I got this right. I take import_module.tar_.gz from #107, install per the instructions in the contained README.txt, and I'm in Fat City like #113 and #118. Right?

subscribing

#146 -- User_Import probably won't deal with Organic Groups, or any other situation where some of the fields in the "user" object are references to other objects.

#147 -- Backup your database. Yeah, it has worked for some; your mileage may vary. Usual caveats apply. "This module will eat your babies," etc.

Here's a tarball and cumulative patch (against CVS HEAD) which re-enables the e-mail notification feature.

Please test and then mark RTBC so this can get released officially.

Yes, please do release something officially so this issue can die. I commented last July that what was there worked for me and haven't had a need for it since and yet this thing has popped up in my tracker 137 times since then.

Michelle

jalama wrote (#138):
> (...)
> you can't do the following with node import
> (...)
> and most importantly import into profile fields

It was a very significant advantage of User Import for its specialized task, however they seem to be adding that feature for the next Node Import RC4 for D6. See the NI issue Profile fields support.

Just a quick question, hopefully someone here can answer it!

When I import users they are automatically set as blocked. This means that when the email gets sent to them, the !login_url doesn't work on it (until I manually activate them). Is there anyway that when they're imported they're instantly activated? I've tried checking/unchecking the activate accounts box - doesn't seem to do anything.

I'm using the tar from #150 on a drupal 6.9 site.

It won't save the password and ignores the activate account option, everything else seems to work fine.

Some info on what I'm working on at the moment for User Import, after which I'll switch all further development to the Drupal 6 version.

http://www.codepositive.com/user-import-module-updating-existing-users

Hi,
I've added support to import Addresses module fields for user import.
I publish it in this thread because Addresses module is only for Drupal version 6.

The file is addresses.inc.
Only has to be copied at "supported" folder in "user_import" module folder and it works.

I could be included at the 6.x version of the module.

Oriol Prat
CriptOS Enginyeria SLNE

re. #155 -- It's nice that you're sneeking up on it chief. Between you and whoever 'documents' content_profile, the rest of us are at sea with respect to porting apps with serious user db requirements to Drupal 6. When I started on this endeavor, I figured that v6.8 (with v7 in the works) would be a safe bet -- silly me for reading the glossies. The fact that this site is just now porting to the version that's been promoted as production for a year is astonishing. I appreciate that it's Open Source, and I'd like to contribute, but I can't even get out of the starting blocks with this mess.

I just tested the tar from #150 on a drupal 6.9 site.

everything seemed to work just fine, as far as i can tell... except that ignores the activate account option (ie: it activated them even though i specified not to), as reported already in #154. i wasn't importing a password field, so i guess it sets them to random strings then? it certain put something in that field, and due to one-way encryption, i can't tell you exactly what :-)

thanks so much to all who have worked on this, so many hours of my time saved. Drupal rocks.

I am using this module (#150), it works fine , but when it insert into the table it creates one empty role and it assigned it to the uid ,and it assignd checked role also

how to avoid empty role insertion

help me

Matt's version works, but needs to allow for periods in a username (drupal allows periods in usernames).

I found this as well. It removes the .'s in the user name validation function. Add the . back in to the grep statement - bang! works great!

Hi, i use
user_import.matt2000.tar_.gz in comment #150.
But the account created are not active and the roles not affected to the new user.
I'm looking in the code and i see that activation and role are under condition.
You must update a account. Not for a new one.
For me the problem is in supported/user.inc on line 93

Yto

I've made a final released of User Import for Drupal 5 which fixes numerous bugs and adds a whole new architecture for how existing users are updated. This release also splits out Organic Groups integration into a separate module called User Import Organic Groups.

The new release is also a starting point for updating the module, and I've used it to also create a Drupal 6 branch. At the moment no work has been done to make it compatible with Drupal 6, if anyone wants to create a patch that would be very welcome, otherwise I'll get cracking on doing the upgrade myself next week.

Please note - update patches should only include code to update the module - no new features should be added!

This also marks the end of development for the Drupal 5 branch, no new features will be added (unless commissioned). There will be some more work on the User Import Organic Groups module before it's ported to Drupal 6, and I'll post more about that in future.

Nested commenting is borked - ignore this and the other blank comment above.

Criptos

Could you create a new feature request for this and add your patch there please.

Thanks!

I am using this (#150) to import bulk user , it imported fine ,
now i am using sms frame work to send sms to user who are registered , in this they gave mobile setting (mobile no, country)

how can i import mobile no and country to these fields

please help me

ashok

ashokkumarc please create a separate issue for your feature request, your post has nothing to do with porting User Import to Drupal 6.

I have been using the Drupal 6 version of User Import but just upgraded to the 23rd February dev release and there is no menu entry in System Administration where I can use the module. I got the following error during the DB Update

Missing argument 1 for user_import_menu() in /home/pobfsjv/public_html/harlequins/sites/all/modules/user_import/user_import.module on line 38.

Help appreciated.

Regards
Martin Fuggle

One small adjustment to #150 to get profile fields working in the generated emails:

user_import.inc, line 62:

$variables['!'. $field_name] = $profile['profile'][$fid][0];

Also, agree with #160.

Sorry for not rolling a proper patch.

I am having the same problem as #169.

warning: Missing argument 1 for user_import_menu() in C:\wamp\www\drupal3\sites\all\modules\user_import\user_import.module on line 38. and no menu entry.

Thanks,

ez

I am having the same problem as #169. Is there any patch or release to fix that problem ?

Just committed work on the official release of User Import for Drupal 6:

http://drupal.org/node/395198

Completed so far:

- .info file done
- .install file done
- menu done
- Form API updates started
- updated validation and submit functions
- started dealing with changes in 'op' variable no longer being used, more work on this needed

This is a development release, it doesn't actually function yet, and is intended only for developers to work on.

Still a lot more work needed to get it to a beta stage, so please don't start testing it or submitting bug reports - that would just add noise that would slow down development.

Installed as directed.

I Press the 'browse' button to select a file to import, or select a file already added through FTP.

Click on Next.

Get this:

Fatal error: Call to undefined function file_check_upload() in /home/content/93/3948193/html/modules/user_import/user_import.module on line 893

Another note on #150:

I had problems when trying to use the "continue processing" feature. Accounts were created, profiles populated, all successfully. When emails were to be sent, they went out blank, and then OG assignments failed to fire.

The first batch of users went fine.

This is just a heads up to anyone using the code in #150 while the supported D6 version is being worked on.

A fix for the issue noted in #175:

If you test the import before running it, _user_import_initialise_import($import) has a call to _user_import_settings_save($import) under the 'test' case. However, by the time $import gets here, its options have already been flattened, so when _user_import_settings_save($import) tries to flatten them again, they all get blanked out.

I added a $flatten_options argument to _user_import_settings_save, defaulted to TRUE, and wrapped the code that flattens the options in a check for it. In the call in _user_import_initialise_import I set it to FALSE.

So now I can test imports and still have them run properly.

I'll try to post a proper patch later.

One other note on #150: I had a few uploads where some batches ran fine except that profile fields were not available in the email body. strtr left the tokens in and we sent out some emails that started "Dear !profile_first !profile_last". Always fun. I haven't yet figured out what caused these batches to behave this way.

Latest release of User Import (6.x-0.4) includes all the updates that are specified in the Updating Modules section of the handbook.

I haven't had time to test many of the functions, so I'm hesitant to call it a BETA yet - too many people would rush of to hose their live site with it if I did.

Please do tests this on a development site, and If you find any bugs please create a new issue.

I'll do a bit more testing myself and then roll out the first BETA later this week.

I tested 6.x-0.4 and it worked as I expected, allowing me to match fields in my CSV file to user and profile fields and creating usernames of first initial last name (APerson). I did not try the email functionality. Seems ready to be beta.

I tested this for updates to existing user's roles using the email address as the update key. Role updates work perfectly except when trying to remove all roles. In other words, you must specify at least one role for the update to apply. For example, if you promote five users to Administrator using the update feature everything works well. Then you decide to change those users to Moderators, update works again and the five users are removed from the Administrators role and put in the Moderators role. Now you decide that they don't belong in any (custom) role and you do another update with no roles selected, this won't work and they'll be left in the Moderator role.

I believe the expected behavior is for the users to be removed from the Moderator role because the update to roles specified no role, and this should drop the users back down to the Authenticated role.

Thanks mtapman, well spotted!

I've fixed the bug in the BETA I'm getting ready to release this weekend.

Any other bug reports for the official upgrade please create a new issue so I can track separately.

Marking this as 'fixed' as there is a BETA release available, and would prefer any bug reports to be submitted as new issues.

there is a BETA release available

Thank you very much!

User Import official Drupal 6 version now available.

Enjoy!

that's awesome Robert! this is gonna make lots of people happy. thanks for all your hard work on this.

cheers
Fish
http://goatvirus.com