Forum OpenACS Q&A: auth::create_user authority_id issue with scheduled proc

I have a scheduled proc used for an integration with an HR system that creates users from a flat file. I use the following command to create the user:

array set creation_info [auth::create_user \
-user_id $user_id \
-username $user_id \
-email $email \
-first_names $nick_name \
-last_name $last_name \
-password $password \
-password_confirm $password_confirm]

The following is the error that returns when the scheduled proc fires:

[29/Mar/2005:03:00:29][2470.2051][-sched-] Error: auth::create_user: Error invoking account registration driver for authority_id = 9: no current connection
[29/Mar/2005:03:00:29][2470.2051][-sched-] Error: Transaction aborted: no current connection

Does anyone know what the "no current connection" means? If it happens to mean that I can not use auth::create_user due to the fact that a scheduled proc executes the code and there is no connected user generating the request, does anyone have suggestions for a work around?

Thanks in advance,
Chip

Why you don't use IMS Enterprise driver, it does everything you need and logs the actions for free.

/acs-admin/auth/

http://cvs.openacs.org/cvs/openacs-4/packages/ims-ent/

Yes, "no current connection" means you are calling code which only works in an AOLserver connection thread. Note that it's the scheduler thread reporting the error.
Andrew,

Do you know if there is a work around? I must use a sched proc to run this nightly import.

Thanks,
Chip

The question is why does auth::create_user need a conn in the first place? Quite possibly it doesn't really need one at all, the code is just (incorrectly) structured such that it assumes one. In which case your workaround could be to simply schedule a job outside AOLserver which hits a page to run that auth::create_user stuff. Then you will be running it in a conn thread and all will be well.

A better solution though, is to figure out what the problem really is. Note that plenty of other OpenACS users do create users non-interactively via various methods, and whatever they do apparently works. So maybe using auth::create_user isn't really the right thing at all. Or if it is the right thing, maybe it has a conn-dependency bug that it shouldn't have.

Thank you Andrew. I have a little extra time to figure this out now. I may end up trying your suggestion to have a cron job run the import script, but if I come up with a better solution by looking into the auth::create_user code, I will post it here.

Thanks again.

As Rocael suggested, you should look at the IMS batch sync stuff in the authentication package. I haven't looked at the code but it does what you want you apparently are looking to do.

Where is your user data coming from? If from LDAP, I have a couple of scripts that can generate IMS XML suitable for the batch sync process. I'm doing this myself currently.

Michael,

Thanks for the response. I am getting the data as a separated value flat file. The users are created as part of a pretty complex script that builds a tree grouping system for users, creates any new users, and maps the users to the group tree. I have not looked into the IMS batch, because I am assuming that my needs are too specific. I could be wrong about IMS batch; however, I haven't taken the time to look into it, because I thought this issue would be easier to work around than it has turned out to be.

Ok. Looks like you can trace the problem down to auth::local::registration::Register. The line is 436 of acs-authentication/tcl/local-procs.tcl, which is the following:

if { [empty_string_p $password] || [parameter::get -package_id [ad_conn subsite_id] -parameter RegistrationProvidesRandomPasswordP -default 0] } {

The ad_conn is throwing the error that disrupts the auth::create_user command. I am not sure if this is a bug or if auth::create_user is only intended to be used outside of scheduled procs.

I will probably comment the line out, since I don't use registration and generate my own random passwords in the import proc.

Anyway, thanks again for the responses. If anyone thinks that I should file a bug report, please let me know.

Thanks,
Chip

Final solution was to replace auth::create_user with the following:

# get authority
set authority_id [auth::get_register_authority]

# create acs user
set user_id [ad_user_new \
$email \
$nick_name \
$last_name \
$password \
{} \
{} \
{} \
t \
{} \
$user_id \
$user_id \
$authority_id]

# approve the member
acs_user::approve -user_id $user_id