Ok then. I'm about to implement the following wrt relations
in the contacts package.
For relations between contacts & organisations:
- Turn "organizations" into oacs groups (currently they are just parties)
- Contacts are parties already, no changes needed
- Add ui for adding contacts to organizations etc.
Question (mostly for John): is it ok for me to turn organizations into groups? (or why are they currently just parties?)
As a side note - I'd like to strip the 'organization_type' stuff out of the organizations package. The same functionality can also be had by using categories - that's more generic and ui for adding/modifying/etc. category trees is already available. UI for doing those same things to org types is not (they are currently hard-coded)
How to go about with relations between contacts, I'm not sure yet. The issue is that there are two types of relations in that case:
- hierarchical (manager/assistent)
- peers (e.g. two contacts, perhaps even in different orgs can have some sort of functional relationship)
Also in some cases one contact could have multiple supervisors.
The easy way to model this is by simply mappings using acs_rels, basically ending up with a adjacency list model in case of hierarchies. The downside isthat one potentially has to do recursive queries to e.g. find all subordinates for a given manager. But I guess that would a rare issue?
Also, as acs_rels are objects, it is possible to annotate relations using general comments - right? Might be a nifty feature.
Keeping the KISS principle in mind, unless someone comes up with a brilliant idea in the next 2 days, I implement it in the simplistic way using simple mappings based on acs_rels.
