Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dev/core/454 rationalise activity case permissions & code #12995

Merged
merged 1 commit into from
Dec 19, 2018

Conversation

eileenmcnaughton
Copy link
Contributor

@eileenmcnaughton eileenmcnaughton commented Oct 24, 2018

Overview

Per https://lab.civicrm.org/dev/core/issues/454 I have made access activities associated with cases consistent between the UI & various other places - in practice making 'access my cases and activities' OR 'access all cases and activities' required to pass the CiviCase component check and removing the 'administer CiviCase' bypass that exists in some places but not others.

Before

Via api '' required for accessing case activities requires one of

  • administer CiviCase
  • access my cases and activities
  • access all cases and activities

UI requires one of

  • access my cases and activities
  • access all cases and activities

After

Via api '' required for accessing case activities requires one of

  • access my cases and activities
  • access all cases and activities

UI requires one of

  • access my cases and activities
  • access all cases and activities

Technical Details

This is a refactor step - not the final destination. I want to move from loading
all activities & then checking if each one can be accessed to determining a list
of activity types and then adding that filter to the sql query. 2 reasons

  • performance
  • because getcount actually hard fails when permissions are applied currently :-(

In this step I note the function activityComponents looks like it expected
the concept of showActivitiesInCore by components to take off but in
practice it is hard coded to 0 for CiviCase & CiviCase only. Oddly there is
acually handling for CiviCase in this function in a place unreachable
without the changes in this patch. In addition the few places that call this
function also do weird CiviCase handling. I've opted for relatively low
intervention since I think most places that call this function
are likely to change themselves in the short-medium term.

Comments

I think this would be easier to review if #12994 were merged first (it is incorporated in this but I would rebase it out if it were merged)

@civibot
Copy link

civibot bot commented Oct 24, 2018

(Standard links)

This is a refactor step - not the final destination. I want to move from loading
all activities & then checking if each one can be accessed to determining a list
of activity types and then adding that filter to the sql query. 2 reasons
- performance
- because getcount actually hard fails when permissions are applied currently :-(

In this step I note the function activityComponents looks like it expected
the concept of showActivitiesInCore by components to take off but in
practice it is hard coded to 0 for CiviCase & CiviCase only. Oddly there is
acually handling for CiviCase in this function in a place unreachable
without the changes in this patch. In addition the few places that call this
function also do weird CiviCase handling. I've opted for relatively low
intervention since I think most places that call this function
are likely to change themselves in the short-medium term.

note this implements https://lab.civicrm.org/dev/core/issues/454 which slightly downgrades the relevant permission
@eileenmcnaughton eileenmcnaughton force-pushed the activity_extract2 branch 2 times, most recently from 70920cf to c4937fe Compare October 24, 2018 02:57
@eileenmcnaughton
Copy link
Contributor Author

I've rebased this after @seamuslee001 merged the extraction PR

@aydun
Copy link
Contributor

aydun commented Dec 5, 2018

@eileenmcnaughton I tried to test this but could not reproduce the 'Before' scenario: I changed permissions for the 'demo' user on a buildkit instance and tested via API Explorer (logged in as demo).
'Access all case and activities' and 'Access my cases and activities' both work as expected without 'Administer CiviCase'.

Is the Description still correct?

@eileenmcnaughton
Copy link
Contributor Author

@aydun - this issue is primarily about cleaning up the code & rationalising inconsistencies in the code around permissions - per https://github.com/civicrm/civicrm-core/pull/12995/files#diff-a35044abd0f538e4af551c5ae039692dL2787 is mostly in the interests of consistency. I wonder if in fact this removes an ability to bypass case ACLs when Administer CiviCase permission is present & it's going the opposite way to what I thought?

@aydun
Copy link
Contributor

aydun commented Dec 13, 2018

@eileenmcnaughton As I read it, any one of the three permissions was sufficient to make isContactPermittedAccessToCaseActivity() return TRUE, and the change removes 'administer CiviCase' from that list.

I guess it comes down to what the 'administer' permission should provide: is it an overriding super-permission in the root tradition, or should it mean 'can configure the CiviCase component'?

I'm not sufficiently up to speed with the nuances of other 'administer' permissions, but by itself this seems a reasonable change since anyone needing to access all cases and activities can be granted the, erm, 'access all cases and activities' permission.

@eileenmcnaughton
Copy link
Contributor Author

@aydun going back to the original gitlab the description is more like what you hit in practice & I have updated the pr summary. @colemanw you approved the gitlab. @aydun has now reviewed - do you want to check if this is mergeable now?

@colemanw
Copy link
Member

Concept makes a lot of sense, the code looks good and tests are passing.

@colemanw colemanw merged commit 7a88e04 into civicrm:master Dec 19, 2018
@colemanw colemanw deleted the activity_extract2 branch December 19, 2018 01:57
@eileenmcnaughton
Copy link
Contributor Author

thanks @colemanw

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants