Forum OpenACS Development: Re: Group membership

Collapse
4: Re: Group membership (response to 1)
Posted by Dave Bauer on 06/26/07 02:58 AM
Offhand. since the model you are building on is the permissions model for members of the web site, it makes sense to use it the way it was designed.

There is nothing stopping the contacts package from modeling, for example, a company org chart hierarchy, and the "groups" within the company.

I created a custom application for this. I created a simple mapping table with a tree sortkey and was able to simply model the hierarchy.

I think you might want to see if contacts should rely so directly on the permissions data model for things that don't fit.

re: #
# Abandon group membership for organizations and persons because non person/user parties are not supported by the core group membership system and instead use some other mechanism to do this... and lose the ability to have contacts groups use the core permissions system (which is a not-insignificant loss).

You should be able to do both! There is no reason you can't subtype group and model your hierarchy outside the permissions data model while still using the permissions data model to define permissions.

Collapse
5: Re: Group membership (response to 4)
Posted by Malte Sussdorff on 06/26/07 09:01 AM
I think the issue here is not so much contacts, though that is where things come from, but for me asking the question why a thing (e.g. group membership) is designed in a certain way where it does not make much sense.

We already had at least one example where OpenACS arbitrarily restricts to users instead of parties. This is another example. My question is why?

We do have the concept of parties. Why do we still have so many foreign key constraints on users (where persons would do for natural persons, not all persons need to be users of the system, otherwise, why the distinction) or persons (where the assumption was made only a person would be able to do something where it actually is a party, permissions being a prime example for me).

Therefore, if we do the research into the toolkit we should be aware of the goals. And my goal is to make sure to only restrict to users / persons where it makes a lot of sense to only allow users / persons. Otherwise use parties.

Here is a small list only on acs-core after a quick look into the toolkit:

a) user_preferences table. Should be party_preferences as this definitely refers to a party with a locale, timezone, email_type and dont_spam_me flag. Remember a party can be any of "person" "organization" "group".

b) email_images. E-Mail belongs to a party! Why people are still limiting things related to e-mail to users is a total mystery to me. But I agree at that point in time I did not have enough experience to recognize the significance of it.

c) I would prefer party_portraits (after all an organization has a logo and a person has a portrait as well), but that is maybe only my taste

d) group membership on persons instead of parties (see above)

Again, there is absolutely no need to make this about contacts. For contacts we have 1) and if 1) is not enough we can just overwrite existing procedures (in contacts-init.tcl).