Forum OpenACS Q&A: Registration Assessment

Posted by Iuri Sampaio on 02/01/06 09:49 PM

I'm working on the registration form to my oacs box.
and right now the information to fill in the form are:
first names, last name, email, username.
which i believe they are the default ones. Those come from the user's table, and it's an important table of the oacs core.

So don't want to change anything there, otherwise i stuck on my on hands and risks.
Then i was wondering why the form is so short, we could have a country info there, which in my view is important and good to have.

What do you think?

2: Re: Registration Assessment (response to 1)

Posted by Malte Sussdorff on 02/01/06 10:39 PM

Don't extend the existing users table.

Use contacts and write a callback to redirect a user through filling out contacts information. This has the huge benefit that you have the information entered by the user already in your CRM system

Alternatively use dotlrn-catalog along with the assessment package to create a registration assessment.

3: Re: Re: Registration Assessment (response to 2)

Posted by Iuri Sampaio on 02/01/06 10:44 PM

That's what i tought :
"Alternatively use dotlrn-catalog along with the assessment package to create a registration assessment."

But it seems to be a good sutff to do what you said before
"Use contacts and write a callback to redirect a user through filling out contacts information. This has the huge benefit that you have the information entered by the user already in your CRM system"

But i have no clue how or where to start =(

4: Re: Re: Registration Assessment (response to 2)

Posted by Malte Sussdorff on 02/02/06 08:30 AM

How can you extend the registration process by allowing users to fill out their own data in the contacts system, so you can have a callback to have them fill this information out upon registration:

First you need to get contacts from HEAD. It has a couple of dependencies, but Matthew is currently working on cleaning things up and getting rid of these dependencies, so I think you should be pretty save in installing it at the momen.
Then you need to ammend contact::groups with a "-no_permission_check" parameter, to override the default permission checking.
Modify contact-edit.tcl to override the permission checking in the contact::groups call if the user_id = party_id (meaning: the user can edit his own data).
The above change asks for a parameter so you could override this behaviour package wide (there are installations where you do not want users to read/edit the information you have about themselves). It might be interesting to create a new privilege "edit_own_data", so you can give permission to edit_own_data in the groups permissions. Which would get rid of the idea with overriding the permission checking.
Create a callback in acs-subsite/www/register/user-add.tcl to overwrite the standard return_url. This requires the callback definition in acs-subsite-callback-procs.tcl, the callback hook in user-add.tcl and the implementation in your custom package
The custom package implementation should use uplevel to overwrite the return_url usually set in user-add.tcl. Put a copy of your implementation into contacts, commented out, so others can take a look as well.

I hope this was detailed enough and others agree with this approach. Furthermore, this assumes you are happy with developing and understand some of the core concepts of OpenACS.