Problem/Motivation

Sometimes, there is a need to import a large number of users, but not activate their accounts.

The current version has a checkbox ("Activate Users" – unchecked by default). Leaving it unchecked does not prevent users from being "activated" in the way this is usually understood in a Drupal context.

Checking it simulates an initial user login. It currently carries the following description:

User accounts will not be visible to other users until their owner logs in. Select this option to make all imported user accounts visible. Note - one time login links in welcome emails will no longer work if this option is enabled.

Proposed resolution

Rename the current "Activate Users" checkbox: "Simulate initial user login". Keep its description as it seems to accurately describe its behaviour.

Introduce a new settings checkbox with the title "Activate Users" that is checked by default (this is the legacy default behavour of the module). If this new box is unchecked, imported users should not be activated.

Remaining tasks

  1. Rename existing "Activate Users" checkbox to "Make all imported users visible".
  2. Create new "Activate Users" checkbox under "Options".
  3. Reroll patch in #14 to take this new checkbox into account.

User interface changes

One existing options checkbox will change name to better match its actual behaviour.

A new checkbox to control whether imported users are activated are added to the options.

Release notes snippet

Fixed users always acticated.

CommentFileSizeAuthor
#14 738158.user_import.activate.patch463 bytes_wdm_
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tinker’s picture

Yes I noticed this too. I think it is caused by the drupal core user_save() function. In this function I see the following code

if (empty($array['access']) && user_access('administer users')) {
      $array['access'] = time();
    }

User import does not define $array['access'], unless "mark user as active" is checked, so it is empty and user_access('administer users') returned true for me since I was using the super admin account. So the current time is always added.

Unfortunately I don't see an easy way around this. The field in the database that stores the last access time is called "access" and requires a numeric not null value. That means that $array['access'] must be 0 but that evaluates to being empty.

I guess you could create a role that cannot "administer user" but can "import users". If you login with a user account with this role and run the import it may work properly. I have not tested it.

The easiest way for me was to just update the records afterwards with a SQL query resetting the field "access" to 0 for all accounts created in a certain time.

tinker’s picture

OK I found made a fix for this problem. You have to modify user_import/supported/user.inc

Original code around line 142

function user_user_import_after_save($settings, $account, $password, $fields, $updated, $update_setting_per_module) {
  /**
   * @todo change hook_user_import_after_save() so that all changes to data are returned and saved in one hit
   */

  user_user_import_after_save_role($account, $settings['roles_new'], $account->roles, $fields['user']['roles']);
	
  return;
}

New Code

function user_user_import_after_save($settings, $account, $password, $fields, $updated, $update_setting_per_module) {
  /**
   * @todo change hook_user_import_after_save() so that all changes to data are returned and saved in one hit
   */

  user_user_import_after_save_role($account, $settings['roles_new'], $account->roles, $fields['user']['roles']);
  // fix users always activated 
  if (empty($settings['options']['activate'])) {
    // by default drupal activates a user when account is created by admin
    // if not activated preference then reset access time and login count
    db_query("UPDATE {users} SET access = 0, login = 0 WHERE uid = %d", $account->uid);
  }
  //  fix users always activated
	
  return;
}

By default Drupal will activate a user account when it is added by an admin. This code resets the last access time and login count to 0. This makes the user not activated.

mstrelan’s picture

@tinker - does this cause problems if the user already exists and is activated before the import? Would this just disable a whole bunch of accounts?

tinker’s picture

@mstrelan Yep you are correct. The code would reset all accounts. You could try the updated code below, where I have added a additional check to see if the account existed before, in which case $updated will be TRUE and the account will not be reset:

function user_user_import_after_save($settings, $account, $password, $fields, $updated, $update_setting_per_module) {
  /**
   * @todo change hook_user_import_after_save() so that all changes to data are returned and saved in one hit
   */

  user_user_import_after_save_role($account, $settings['roles_new'], $account->roles, $fields['user']['roles']);
  // fix users always activated 
  if (empty($settings['options']['activate']) && $updated==FALSE) {
    // by default drupal activates a user when account is created by admin
    // if not activated preference then reset access time and login count
    db_query("UPDATE {users} SET access = 0, login = 0 WHERE uid = %d", $account->uid);
  }
  //  fix users always activated

  return;
}

Please let me know if this works for you.

Stoob’s picture

I have confirmed this bug on my system. Although all users are set to "active" the email url_login is still sent properly.

What is the status of this module? Is the owner active? Last update, almost one year ago (Oct-2009)? Can another owner be given, to commit changes?

Robert Castelo’s picture

I'm scheduling some time in October to clear out the issue queue for User Import module, will make this one a high priority.

higherform’s picture

We have a patch in progress to set a 0 / 1 column to control active versus blocked for new and updated users via import. Will release after some more use testing.

FatherShawn’s picture

Subscribing. Looking forward to having this fixed.

Robert Castelo’s picture

Priority: Normal » Major

higherform how did the testing on the patch go?

I've re-set the priority on this bug to Major, as it's an important feature that should work properly.

osde8info’s picture

Issue tags: +activate, +blocked

sql patch should read

UPDATE {users} SET access=0, login=0, status=0 ...

if you just want user import users without activation and you want to activate them via the administrator account

InfoStarJot’s picture

Component: Code » Documentation
Status: Active » Fixed

The best way to do on Drupal 6 is:

Open file modules/user_import/supported/user.inc

then go to line 119 and change code $account_add['status'] = 1; to $account_add['status'] = 0;

0: Blocked
1: Active

this basically blocks the new users upon the importing of users by Import users. Hope this helps instead of using a patch!!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

ordually’s picture

Component: Documentation » Code
Status: Closed (fixed) » Active

I can confirm the code change in #11 works.

However, #11 also changed the ticket to resolved, which it's not since the code is not in the module. It appears that it will honor both settings of the "Activate" selection.

_wdm_’s picture

Issue summary: View changes
FileSize
463 bytes

This is still a problem in 7.3, patch attached for 7.3.

gisle’s picture

Version: 6.x-2.3 » 7.x-3.x-dev
Status: Active » Needs review

Changing status and version.

gisle’s picture

Issue summary: View changes
Status: Needs review » Needs work

The rerolled patch in #14 applies cleanly against latest 7.x-3.x-dev snapshot and will prevent users from being activated.

However, I've rewritten the issue summary to better reflect this issue and what is required to fully resolve this, and this patch does not reflect the revised issue summary. Setting back to "Needs work".

gisle’s picture

Issue summary: View changes

Revised summary.