Forum OpenACS Improvement Proposals (TIPs): TIP #105: Callbacks for user registration

Nearly every site I have been looking at reworked the user registration. This was done using a multitude of techniques, the most pleasant one was using a "next_url" to point the user to the next_url instead of the normal account_message, where additional information was collected. The more usual approach was to just edit /acs-subsite/lib/user-new.tcl

This TIP proposes to tackle this situation by adding three callbacks to /asc-subsite/lib/user-new.tcl

===

ad_proc -public -callback user::new::form {
-subsite_id
-form
} {
Used to provide additional form fields during the registration process

@param subsite_id Package ID of the subsite used upon registration (using ad_conn package_id)
@param form Name of the form to extend
} -

====

ad_proc -public -callback user::new::form_save {
-subsite_id
-form
} {
Used to save additional form fields during the registration process.
Can be used to manipulate values after submission as well (e.g. you might want to set the next_url)
It is called within the db_transaction, so all db saves will be rolled back if the creation fails

@param subsite_id Package ID of the subsite used upon registration (using ad_conn package_id)
@param form Name of the form to extend
} -

=====

ad_proc -public -callback user::new::after_submit {
-subsite_id
-user_id
{-password ""}
{-account_message ""}
} {
Callback executed after the user has been successfully registered.

@param subsite_id Package ID of the subsite used upon registration (using ad_conn package_id)
@param user_id New user_id of the user
@param password Password of the user
@param account_message Message given during the account creation.
} -

=======

The first two callbacks are for extension of the default form (register) the third callback is for additional after creation actions (e.g. sending out e-mails, adding to a community).

The whole code has been written and tested, so once approved I will commit it. If alterations are requested I can arrange them too.

Implementations can look like this:

ad_proc -public -callback user::new::form -impl cognovis {
{-subsite_id:required}
{-form:required}
} {
add eabis elements to the registration
} {

ad_form -extend -name $form -form {
{organization:text
{label "Organization"}
{html "size 30"}
}
}
}

ad_proc -public -callback user::new::form_save -impl cognovis {
{-subsite_id:required}
{-form:required}
} {
save eabis elements to the registration
} {

uplevel {
# Insert cognvis user information
db_dml cognovis_user_info_insert "insert into cognovis_user_info (organization) values (:organization)"
}
}

ad_proc -public -callback user::new::after_submit -impl cognovis {
{-subsite_id:required}
{-user_id:required}
{-password ""}
{-account_message ""}
} {
Enter the user into the public dotlrn community. Send an e-mail
} {

upvar return_url return_url

# Register the user in .LRN
dotlrn::user_add -user_id "$user_id" -type "student" -can_browse
dotlrn_privacy::set_user_guest_p -user_id "$user_id" -value f
ad_user_login $user_id
set return_url "/dotlrn/register?community_id=161436&return_url=$return_url"
}

Collapse
Posted by Malte Sussdorff on
As part of this TIP I would like to get rid of all the assessment specific parameters in acs-subsite like "RegImplNamet" or RegistrationId and so on. In my opinion this was very badly designed...

I have no clue though how best to incorporate this assessment based change into the new design and I'm not entirely sure I want to :). Especially as the assessment registration part should be a custom package callback and not something which resides in acs-subsite!

Collapse
Posted by Malte Sussdorff on
The removal of the assessment procs will take more time and thorough investigation, therefore I withdraw this ammendment to the TIP.