Forum OpenACS Q&A: Re: Registration Assessment

Collapse
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.

Collapse
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 =(

Collapse
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.