CiviCRM Community Forums (archive)

can't spot this question elsewhere.

 is it possible to set a Relationship so that it always confers "can view and update information for" ie I want 'Company Admin" to always confer 'can update' rights over the Company, and "Employer of" to always confer 'can update' for the Employees

that way we don't have to configure the relationship for each individual

ALSO

must have a blindspot but I am sure that I had seen the following (and thought I had even used it)

Person A and B are Employee of

Person A has 'view and update' on the Company.

Company has 'view and update' on Person B.

Therefore Person A can use their rights to go to Company Dashboard and have access to Person B's details to update.

Did i dream it?

So to achieve the following

Person A is the Company Admin and should have the Company AND all the Company's Employees on their Dashboard and be able to Edit their detail.

I will have to do the following

Give Person A update rights over Company B via Relationship with that Company

Also give Person A update rights over Company B's other Employees by having an 'update' right Relationship with each of those people individually??

What I am missing is that this function for was available for Households and Employers in 2.1 but is not in 2.2 (our site). Will verify on Sandbox.

Is it meant to be missing, or is it a bug (hopefully the latter and easily fixed)

Peter - It looks like this was a "deliberate" change based on feedback from Brian Shaughnessy - http://issues.civicrm.org/jira/browse/CRM-3549

I'm not sure if the "concept" of that change was good or not - altho it's true that "organizations are not CMS users" is a principle we adopted.

That said, I did some testing of the current implementation at it's buggy. I've sent email to Deepak and Lobo to investigate (text copied below) - but regardless of the bug fixes - if you can explain why your use case is valid and important - that would be good to hear....

--------------------
The current code seems buggy.

EXAMPLE:
Create Spouse relationship between Melinda Adams and Purvi Adams and check "selected contact(s) can view and update information for 'Ms Melinda L Adams Jr'".

The inserted relationship record has Melinda as contact_a and Purvi as contact-b and  is_permissioned_a_b = 1, is_permissioned_b_a = 0. This is the correct behavior but is the opposite of that the message above indicates.

When you go back and edit the relationship, you see the correct info:

  'Ms Melinda L Adams Jr' can view and update information for 'Adams, Purvi' (e.g. is_permissioned_a_b)

AND if you EDIT that relationship from the contact B side (e.g from Purvi Adam's relationship tab) - you get the opposite (incorrect) message:

   'Mr Purvi Z Adams Sr' can view and update information for 'Adams, Melinda'

... but viewing the relationship from Purvi Adam's side gives the correct message (contact/view/rel?action=view&reset=1&cid=15&id=152&rtype=a_b&selectedChild=rel)

   'Adams, Melinda' can view and update information for 'Mr Purvi Z Adams Sr'

Looking at Fisheye - all references to is_permissioned_b_a seem to have been just removed which seems wrong. Maybe we should just revert that change? Altho Brian's point about "organizations are not CMS user's" is accurate - it may be too limiting in this case.

Peter - Discussed this further with lobo today. Looking at the 2.1 and 2.2 code - we're pretty sure that the only way the use case you described below would have worked in 2.1 was if you were logged in as an administrator who already had edit permissions on everyone (either via drupal perms or ACLs).

If you retest your theory on 2.1 and determine that we are WRONG in this - then we'll revisit, since we don't want to remove functionality. Otherwise, our position at least for 2.2 is:

* permissioned relationships are between two contact records - are not transitive across relationships (i.e. person A -> Household A -> person B)

* permissioned relationships allow a known (logged in) contact to view / update another contact record - and since Households and Orgs can not log in (they are not users) it doesn't make sense to say "Household A can view and update information for Person A"

I just read the related discussion / post by Michael McAndrew on adding support for "on behalf of" and clearly there's more thinking and potentially coding to support more use cases in a good way for 2.3 and beyond.

More testing done.

So I guess you aren't arguing that i can see the relationship being offered in both directions in 2.1 and not 2.2 - you are doubting that having the Org or Household having 2-way option allows Person A to amend Person B's details due to both having 'secondhand' rights via an Org or Household.

You are correct if an Authenticated User only has the following permissions

- access Contact Dashboard

I think the reason I observed it before was not because I had more permissions (though that would also cause it), but because i may have had a contact that also had a 'first-hand' relationship to that person as well.

But I still think the logic of being able to permit this 'secondhand' permission is valuable if it isn't not technically difficult.

Of course I can provide a 'first-hand' relationship to achieve what I want. The beauty of being able to do it via a 'second-hand' right is that
- a single person has the 'permission to update' set to the organisation/company they have a responsibility for
- all other people with the correct relationship to the organisation (which can be achieved at via Membership) can then also be 'updated' without having to set up another relationship (thought the 'update' persmission would have to be 'okayed' for each but potentially this could also be hard-coded for a particular type of relationship.

I'll assume I will need to progress this via a 'first-hand' relationship - and will probably then figure that there are issues of not having access to the persons Custom Data or Groups that may bring this to a stop anyhow.

 
Overnight thinking? I thought it was you telling me to stop dreaming about civicrm 

the code has been fixed so we have the same behavior as 2.1. i.e. permissions can be in either direction of a relationship irrespective of contact_type

tiered authorization was not a feature in 2.1 and is not part of 2.2 either. The best way to do that would be via the acl hook system (for now)

lobo