Relationships - automatic conferring of 'can update' rights

[petednz]

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?

[Donald Lobo]

1. the relationship type does not have this feature, but chris should be able to implement it with the "civicrm_post" relationship object hook (on create or edit). should be a fairly easy hook implementation

2. u need to stop dreaming about civicrm

lobo

[petednz]

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??

[petednz]

Hey lobo - it wasn't a dream. What I want for Employer/Employee is currently available via Household AFAI can see.

Person A + B are in Household (but no other direct relationship)

Person A dashboard can see Household, and Household has permission to change Person B - so Person A can change Person B's details.

SO households seems to offer the 'right' in both directions

    Can view and update information for 'Davis and Potaka Household'
 
    'Davis and Potaka Household' can view and update information for this contact

But Employer (and other relationships) don't seem to.

Am I missing something?

When we create a new Relationship I think we need to be able to specify that the 'rights' can be allocated one-way or both-ways. Comments?

[petednz]

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)

[petednz]

Just verified am not seeing 2-way on demo site. Just to be really clear  - see images, one for 2.1 shows two way 'rights', other from 2.2 shows only one way rights

[Dave Greenberg]

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.

[petednz]

Thanks for engaging Dave. The logic I am trying to apply, which I think you are appreciating, is that while a Company is not a User, it is a valid way of creating Relationships and for using those Relationships to give an 'authorised' individual access to the records of their colleagues.

I think the case Brian might have been making is the depending which end of the relationship you are at, you should only have the option to give the rights in that direction
ie on the Org record you can say 'the org has rights to update the individual'
on the Indiv record you can say 'the indivi has rights to update the Org'

But when I read the description in Jira I get confused

In other words --
If the relationship is being built from the individual's record, (A) only the option stating this individual can view/update info for the parent employer. If the relationship is being built from the org's record, only the option stating the individual (B) can view/update the org data.

So I wonder if the confusion has been generated by both sides of the argument refer to 'the individual' have the rights. Cause it sounds like the same thing to me.

Whatever, it really makes sense to me to allow Person A to have access to update Org B and that if Org B has rights to update Person C, then Person A effectively gets to do the same.

In 2.1 this certainly was great for Households as it meant that one member could update the records for the whole Household.

[Dave Greenberg]

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.

[petednz]

Dave - I am not sure why ACLs or anything else would explain the above Picture48 v Picture49 

[petednz]

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.

[Donald Lobo]

after some overnight thinking, i realized that you can apply transitive rules via ACL hooks, since all that code goes via the ACL system also.

internally  we are debating whether it makes sense to enable this permission on household/organizations (since they dont have logins)

I think your use case is a strong argument in favor of

lobo

[petednz]

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

[lcdweb]

...jumping in here

Peter, your use case is very convincing. My original thinking did not account for this use case -- I was thinking that the Indiv <--> Org relationship *could* only have one meaningful relationship authorization direction, viz. a logged in Indiv could manage an Org's data. And my rationale was largely based on the idea that an Org doesn't have a user login, and therefore would have no way to manage other contacts.

What I hear you saying is that you can effectively achieve a tiered authorization effect (which could be very useful):

Indiv A --> authorized to edit Org A
Org A --> authorized to edit Indiv B and Indiv C
therefore -->
Indiv A --> authorized to edit Indiv B and Indiv C

If this does indeed work, maybe we just need to clean up the relationship interface and provide some reference to this (advanced) use case, as it would not necessarily be intuitive from what is there now.

[Donald Lobo]

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