Forum OpenACS Q&A: Attributes for users, rather than groups?

In OpenACS 3.x, I could define an attribute for a group that would
effectively extend the users table, letting me add information about
individual users.

In OpenACS 4.5, at least, it looks like attributes are set on group
types and used to define groups.  That's very reasonable and good, but
is there any way to define attributes for the members of a group?

For example, I would like to have a "cellphone number" attribute
associated with users of one group, but not another.  How would I go
about doing this?  Or should I take the advice from the documentation,
creating a table whose primary key is inherited from "users", and put
my attributes there?

Collapse
Posted by Stephen . on
Sorry, OACS4 doesn't have the same groups functionality as ACS3, you'll have to program it yourself.
Collapse
Posted by C. R. Oldham on
We wrote a package called "group-data" that does sort of what the old ACS 3.x did.  I'm not sure if it's in a releaseable state.  Are you interested?
Collapse
Posted by Reuven Lerner on

Yes, I would be very interested in seeing this. And I have a feeling that I'm not alone. (And given that I've just started to work on custom registration systems for two OpenACS sites, your timing couldn't have been better.)

One of my favorite parts of OpenACS 3 is the fact that you can say that everyone in group X has the following attributes. Better yet, you define such attributes via the Web.

I can't promise that I'll use your code, but it would definitely be nice to see how it works. And if it's good, then I'll happily work with you to contribute it back to the community, unless something better (from dotLRN, perhaps?) is on the way.

Collapse
Posted by Brian Fenton on
I'd be interested in seeing this too.
Collapse
Posted by Brad Duell on
I added to new-file-storage our group-data package:

https://openacs.org/new-file-storage/one-file?file_id=403

And attribute package:

https://openacs.org/new-file-storage/one-file?file_id=404

This has helped us do what you've asked.  Group-data is for groups, and Attribute is for individual objects.  For instance, if you wanted to keep "cellphone number" data on one group, you'd create a group-data of "cellphone number" on that group, and the use the api to add/remove/view/etc that value.

Any comments or suggestions are appreciated.

Collapse
Posted by Reuven Lerner on
Hi, Brad.

First: Thanks!  I really appareciate your willingness to share, and expect to contribute back whatever functionality I can to the community.  Given that nearly every OpenACS project I'm working on needs this functionality, I can only assume that I'm doing something horribly wrong or that we should try to get a version of this folded into the main OpenACS system in the near future.

I've just spent about 2-3 hours playing with the "attributes" package, including porting it to PostgreSQL.  I hard-coded the changes in the Tcl,  and hope to move them out .xql files alongside the Oracle code in the near future, but I first wanted to play with the code to see how it worked.

I'm not sure how much I like the idea of using a single table for both attributes and their values, but (a) your generosity is appreciated and (b) what you've done is more than good enough for my current needs.  In particular, the Tcl API that lets me set and retrieve attributes is a godsend.

My biggest concern right now is that attributes are completely global.  I haven't looked through your Tcl code that much, but how difficult do you think it would be to get this working on a per-subsite basis, rather than a global one?  I expect that we would only need to add a context ID to the table, and then grab (and use) that context ID in the Tcl procs, but I'm not sure.

Collapse
Posted by Brad Duell on
Thanks for the Postgres porting time you've put in!.

Yes, I don't see a problem with using something like the context id (I don't know a lot about contexts) or the system name to use in the table naming.  In group-data, we could just make the change to gd_tablename function, and for attributes we could provide a similar attribute_tablename function to return the corresponding table.  We'd also have to make the correct changes to the create/delete sql statements for installing/enabling the package.

Thoughts?