After discussion with core team members, mainly Dave Greenberg, there has been some discussion in the past about how to use the primary_contact_id field within organization contact type. I would like to revisit this after having about a year's time with CiviCRM and putting it into production use. Please chime in with any thoughts or other use cases that you see this field being used for.
Defined use as the "primary contact id" as the primary person responsible for maintaining and updating associated records with the organization. Not sure if this could be applied to all contact types as well allowing for more granularity in permission. This would also be the person who would be contacted when addressing items related to a particular organization such as mailings.
My use case is pretty straight forward: I use the primary contact to for membership renewal notices, emails, updating of other related contacts to the organization and is typically the holder of the relationship permission to view/update the organizational record. Use for the primary contact id would hold the individual contact type id value to grant permissions to add and remove members and so forth as if it were the organization itself. Furthermore, the primary contact could inherit the relationship rights since currently there is not a transitive relationship between the two. This could also be a way for transitive trusts between any contact type as well and could lead to a more self-sufficient member-driven solution.
I know this combines two items a bit but I think that the use case for both system information dissemination such as emails/invoices/etc. along with security rights transitive relationships as well provides a good approach to better member management when it comes to organizational level memberships and communication.
Comments
We definitely see that same use case - to employer one individual to manage a company's membership.
With transitive permissions however, it seems that there is a case for more than one person to have them -as long as you assume that they only ever go from organisations to people - ie. if I have a permissioned relationship to your company which has a permissioned relationship to you then I can edit your details - but not your kids details. There is no other logic I can see for organisations having permissioned relationships
Hi,
Not sure I understand what's the difference with permissioned relationships. Isn't it the same feature?
Thank you for your comments. I see the potential for say a parent company of a branch (the household relationship) being the same as a parent to child as well. My understanding is that permissioned relationships are NOT transitive in nature. Meaning that Joe Smith is permissioned for business AAA and business AAA is permissioned for Susie Queen that does not mean Joe Smith is permissioned for Susie Queen. Rather I see establishing transitive trusts is very useful, please corrent me if I am wrong about the transitive trusts as I asked Dave this very question in San Fran about 60 days ago and he said no transitive trusts.
If this is the case then I retract my statement about being combined and would say that primary_contact_id value would be in terms of contact/communication purposes only. Meaning emails about renewals, mailings to organizations and so forth would be directed to that particular person.
I think it is better to have a relationship based approach to this too, so that you can have more than one (or different) "Mailing contact", "Billing Contact" or "Membership Contact" for an organisation.
We also these kind of relationships at the Case level with CiviCase, because the "Client contact" can be different for different cases, while the "Billing Contact" may be the same for each (the accounts person).
We've written a large application that implements transitive permissions based on relationships using a rules engine that is organisation specific, so I'd agree with Eileen that there are use cases for more than one person to have certain permissions on another contact which has permissions on another contact. Adding transitive permissions to relationships would provide this broader flexibility (and can apply to relationships between all contact types), while a primary_contact_id has a more limited use.
Thanks again for the comments. Any chance that you might be willing to share some of that code with the core team to help develop this functionality out. I think we can all agree that a transitive relationship approach would be served best solve this problem and that the use of primary_contact_id might still sit idle as it does not provide a flexibile or scalable approach. A rules engine could then be one where we could map the rules allowing the greatest flexibility in relationships. I think this is great MIH item as it would help to close the door on use for primary_contact_id field (unless used in a rules based approach in some fashion) and open one for flexibility in relationships and permissions and might even expand use cases for group and OG sync within Drupal, WordPress and Joomla.
Any other comments, willingness to contribute and so forth would be great.
The most basic use case is to be able to email the membership renewal reminders to a designated contact, and that all tokens are correctly filled out (ie. Dear Mr Smith rather than Dear ACME Sporting Goods, Inc.). Will the permissioned relationship enable this?
I think it would because the "rules engine" could be enabled such that the primary contact rule could be enabled and thus allow to be set to any contact_id where it substitutes the contact info, or least that is what I was thinking with regards to the "rules engine". The rules engine could be very diverse in overriding permissions based on exemptions that are needed, making it very flexible in what it could do. If there was a significant time table to dev out a rules engine I might suggest that the primary contact id be a field that could be set with any contact id where the lookup for contact info was redirected to the primary contact's values rather than the current contact values. Let me know if I am not thinking this through right.