Forum OpenACS Q&A: Address book package

Collapse
1: Address book package
Posted by Matthew Coupe on 06/26/06 11:44 AM
Hi,

I'm looking at extending the user information to include a custom field which is a uniqe identifier for all of our users (used in a CRM).

We ideally want to allow our users to change their username to something they can remember (this will be done in LDAP through a seperate interface.) However by changing their username to something else this will leave us the problem of tracking the users (potentially 10,000+)

I have read various threads on this subject and have decided against changing the core user tables and adding a custom table referencing the user table. Would using and extending the address-book package be a sensible choice for this sort of functionality? Would we be able to use LDAP to map these attributes when a new account is created or would this be quite a difficult thing to do? We have scope for adding plenty more fields but this one will do for starters.

I'm interested to hear how other people have extended the user information table. We're currently running OpenACS 5.1.5 and dotLRN 2.1.1.

Thanks in advance,
Matthew

Collapse
2: Re: Address book package (response to 1)
Posted by Malte Sussdorff on 06/27/06 09:11 AM
I usually would say that you should use the contacts package which superceeds address book, but with your current setup that does not make sense. Callbacks don't work either, so I am not sure why you don't just go ahead and extend the table. Or use the screenname to store this value.
Collapse
3: Re: Address book package (response to 1)
Posted by Matthew Coupe on 06/27/06 09:32 AM
I'm a bit concerned that changing the core database could prove to be problematic when it comes to upgrading? Would using the screen name as an id number not change how people's forum posts are named etc. to something a little inpersonal?

On the upgrade topic, to upgrade from dotLRN 2.1.1 (to 2.1.3) and OpenACS 5.1.5 (to 5.2?) the current stable releases, where can I find some documentation? This seems to be an area which perhaps isn't covered by a 'best practice'.

Matthew