Forum OpenACS Development: User contact information

Collapse
Posted by Lars Pind on
I have a concrete need to add contact info to users.

I can of course hack something up, but this seems to basic that we'll want it in core. Something like:

- street addres, postal code, etc.
- IM names
- phone numbers

I know vaguely about Griffin's stuff, and I know that we're a global community, but I also know that we tend to make general solutions for really simple things, so ...

What should we do here?

1. Add the relevant columns to the users table, ignoring the complexities of the issue, and just providing a place to store the info. E.g. just provide enough fields that anybody anywhere in the world will be able to fit in their address somehow. Add IM columns for Y!M, AIM, ICQ, MSN, and Jabber, and don't try for the generic service-contract-based approach.

2. Build a generic 'Interface' mechanism a' la other OO tools, so you can make the 'user' object type 'implement' this 'contact info 'interface. This could be made arbitrarily complex.

3. Fork and do whatever the hell I want to, so long as I don't commit it to OpenACS.

I'd be inclined towards 1, just because it's so obviously useful and simple to do.

Thoughts?

/Lars

Collapse
Posted by Dave Bauer on
Lars,

The datamodel to do this already exists in OpenACS. Telecom-number, postal-address packages.

Collapse
Posted by Randy O'Meara on
Lars,

The generic approach would be very useful. I recall several threads discussing the need for something like this. In fact, there's another thread (https://openacs.org/forums/message-view?message_id=168157) started today that could be related.

Randy

Collapse
Posted by Walter McGinnis on
The data model is already there for almost everything, except maybe IM addresses.  Actually, I take that back.  The last major piece of the data model is something like an addresses table that would be similar in concept to the data model in the telecom-numbers package.  I think the best approach is add that and then to add specific template widgets for telephone numbers, countries, state/province, and postal_codes, etc.

What is your timeframe like?  We need this for a client project and would be willing to coordinate effort in order to get this done faster.

Collapse
Posted by Malte Sussdorff on
Go for 1) but don't use the users table but create a seperate table. Fill it up with as many columns you can think of are useful for storing user information.

Now you can either write up a small package to store the values in there, or create a predefined "database question" with "complex survey" for each of the values in the database and make a custom survey out of it, which has the benefit of being able to ask some people more questions than others and do branching (e.g. you can only show the IM contact information if the user answered to the question "Do you use instant messaging" with yes).

For obvious reasons you might want to add a link to the response of the survey for the user to edit on the /pvt/home page.

Collapse
Posted by Dave Bauer on
Walter,

There is the postal-address package for addresses. The idea of adding widgets for telecom numbers etc is great.

Collapse
Posted by Jon Griffin on
postal-address has all you need. There is also an old version of my contacts-lite package on my site. I stress old, as in it is a good start, but probably isn't even working with 5.0.
http://jongriffin.com/static/openacs/packages/contacts-lite-0.2.1d.apm
Collapse
Posted by Jade Rubick on
I'm not as experienced in the core as many other people here, but if I was implementing this from scratch, the first thing I would think of is to create a separate table, like Malte suggests, and then create an admin UI which allows admins to dynamically add and remove columns from this table.

This actually wouldn't be too hard to do. In project-manager, I use this to add custom fields to the projects table:

select content_type__create_attribute(
        'pm_project',
        'customer_id',
        'integer',
        'Customer',
        'Customers',
        null,
        null,
        'integer constraint pm_project_customer_fk references organizations'
);

This associates a customer with every project.

You could create a UI to allow admins to add in columns dynamically.

Then, you could have a reference to telecom-number, postal-address, or any other UI. The downside is that it's not user friendly at all, but is mostly geared towards developers.

Which is actually big enough of a disadvantage that I'd consider doing something else.

Just a thought.

Collapse
Posted by Andrew Piskorski on
Jade, a web-based admin UI which directly adds and drop columns from tables?? Generally speaking, yuck!

An interactive UI like that means that nothing is repeatable, nothing is scriptable. My Dev, Staging, and Production data models may all end up slightly different and I won't even know it without specifically digging through the live schemas looking for discrepencies. Rolling out a new site update from Staging to Production will mean manual instructions - "Go here, type this, click on that" - interspersed with running the upgrade scripts. Sometimes you end up stuck with that sort of thing, but it's to be avoided, not preferred.

Now, if you instead want a web UI to collect and record specifications or other info with is then dumped to a file and used to drive an automatic script, that I could see! When it comes to DDL (stuff that changes your database schema), IMNSHO any web UI should, at most, help the human user define what needs to be done, never directly change stuff itself.

I have probably oversimplified and overstated the case, but that's definitely the gist of my experience.

Collapse
Posted by Tom Jackson on

I agree, but doesn't this happen with groups admin UI, and what is invisioned for CR/CMS? Nothing substitutes for a file which contains the datamodel, pl code, triggers, etc. so you can inspect them.

Collapse
Posted by Walter McGinnis on
Great to hear about the postal-address package.  So the last big chunk of work is creating template widgets.  Since these require a number data model packages as dependencies, we may want to make this a separate package that extends the acs-templating package functionality, rather than commit to acs-templating directly.

As far as addresses types, there is a postal_types table for keeping track of things like mailing vs street address, etc.  So app packages could use a mapping table for one (party_id) to many (street, mailing, etc) address relationship mapping.  However, I'm wondering if a more general solution is to use acs_rels.  Mark Aufflick is working on a UI for acs_rels right now.

Collapse
Posted by Tom Ayles on
I started some work towards a generic telecom number widget. I built a set of Tcl accessors for telecom number (new/update/get) that worked with an array representation, then built a templating widget to allow editing. The widget only handles subscriber/extension numbers right now, but the way its implemented should be easy to extend. I was planning on releasing it to the community at the end of the project I'm working on, but if anyone wants to get hold of it now to have a look, please feel free to contact me directly.
Collapse
Posted by Walter McGinnis on
Hey Tom,

That sounds great.  I would love to see the stuff you've written.  I tried contacting you via email, but got a "does not like recipient" message.

Feel free to email me directly.

Thanks,

Walter

Collapse
Posted by Tilmann Singer on
Of course out of scope for a first time quick implementation, but it would be nice if it'd at least considered somehow a later addition of privacy control of these fields, so that the user can control who will be able to see the data s/he entered. Maybe something resembling the old priv_xxx method.