Contacts currently uses the acs-core groups mechanism to group person and organization objects, via a acs_rels workaround in the membership_rels table. This is not a clean solution and I'd like advice on the correct way to proceed with this problem. Or, is my assumptions that parties other than person/users objects should be able to grouped together flawed?
Here are some possible solutions:
- Keep contacts as is using the work around in the contacts tcl api to "cheat" the model of groups set up by core (i.e. to directly insert organization relationships into the database without using the tcl api). This has the advantaged that it works flawlessly (and has for two years) though it does not fit the overarching model well set up in OpenACS well at all.
- Change the membership_rels object_type to enforce group -> party relationships, which would enable organizations to have group membership. This however has the problem that it would allow groups and other non person/organization objects to be members of groups which could easily wreak havoc with permissions (not sure about other potential implications?)
- Enable group membership for organizations by some other means, like creating a shell "person" for that organization to hold group membership (which defeats the whole point of having various object subtypes of parties in the first place).
- 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).
