Published
2009-06-16 13:17
In my last blog post about multi-org, I made the case for merging groups and relationships as an elegant solution to the multi-organization data modeling requirements. My thinking boiled down to:
- Groups represent a relationship between "you" (i.e. one of the owner organizations of that Civi instance) and a contact (i.e. a member, newsletter subscriber, media contact, alumni, etc.).
- Relationships represent a relationship between 2 external contacts.
- CRM-4609 - Create a new permission called "Administer multiple organizations"
- CRM-4610 - Allow connecting Organization contacts to Groups for multi-org support
- CRM-4611 - Sites in multi-site need the ability to specify the org/group pair that they represent
- CRM-4612 - Create a lookup function that returns which group/org pairs a user is responsible for
- CRM-4613 - Add a new requirement that all new contacts must be added to a group
- CRM-4614 - Add a new requirement that all new groups must have a parent group
- CRM-4615 - Add multi-org token resolution features to CiviMail
Comments
Thinking about this from the perspective of political parties, it might be worthwhile to be able to have no orphans as a constraint for more than one level of organization. So, all voters must be assigned to a riding/district for federal offices as well as for provincial offices. There can be no orphans at either level.
My concern is less with CiviMail than with delegating permissions to those responsible for a province/state or for a riding/district. Everything you write seems compatible with that, but I'm unclear if there are hidden issues or interactions.
Cheers,
Joe
Is that you can "type" the relation between two contacts (eg this one is the president of that org, this one is a member), but the relationship between a group and a contact is a boolean (either you belong or you don't, but you can't specify that one belong as a board member while the other is a volunter.
X+
To extend this idea a bit, a common use case for multi-level orgs is that the sub-orgs may have boards/staff, who have replicated roles/permissions similiar to what has been worked out for the NS Greens. For example, all local groups have someone responsible for memberships, another responsible for money, another responsible for volunteers, another responsible for events, another for newsletters & communications.
And being able to search/filter on relationships as easily as it's done on the groups today, and hiding the group away and keep them for technical stuff ?
2.x ? ;)
X+
While it is true that the current design is such that relationships specify a type and group membership does not, it seems unreasonable to maintain this constraint. To overcome this constraint we will have to merge the concepts of Groups and Organizations. This is the next logical step and one that we are experiencing demand for.
We've been doing quite a bit of work around multi-org recently, in particular where there is a Country broken down into States and the States have a range of Branches, which members can transfer between from time to time, but with only one paid annual membership for the Country.
We have run headlong into the challenge of where to use memberships, groups and relationships and ultimately the binary nature of groups, their lack of connection to a target contact and the requirement to have a separate Membership Type for each organisation that people or branches could become a true "Member" of, meant that we have moved away from memberships (except for Country level) and groups, and used relationships because:
(a) One "Relationship Type" can be used to create a "Member of" relationship between individuals and different Branches, with another to create a "Branch of" relationship between many branches and different States;
(b) You can also have a "President of", "Treasurer of", "Secretary of" relationship between individuals and many different Branches and/or States rather than just "in" or "out" of a group;
(c) You can set a start and end date for relationships (while groups store this based on the date you add/remove, but from recollection you can't change it through the GUI)
HOWEVER, we really miss the fact that relationships aren't hierarchical so while we might say a person has a relationship of "Member of" a branch, each branch has a relationship "Branch of" to a State, and each State has a relationship of "Branch of" to the Country, we can't find all the people with a particular relationship to the Branches in a State like we could if we used Memberships to create the link between the Branch and the State (with a separate Membership Type for each State and a "Member of" Relationship Type inheriting membership) or hierarchical groups (with each State being a sub-group of Country, each Branch being a sub-group of a State and each branch member being in the Branch sub-group, but with no way to identify who is "President of" the branch)
The above sounds like it could help with some of these issues, but it would also help if:
(a) You could create a single Membership Type like "Ordinary Member" that, like a Relationship, can operate between individuals and multiple organisations that have a particular relationship or are in a particular group (such as Branches); and
(b) on an unrelated topic, you could create sets of membership periods and fees for each Membership Type, like 1 year $100, 2 years $190 or 3 years $270