Rationalise Activity api ACLs
authoreileen <emcnaughton@wikimedia.org>
Wed, 16 Jan 2019 00:02:37 +0000 (13:02 +1300)
committereileen <emcnaughton@wikimedia.org>
Fri, 22 Feb 2019 07:42:38 +0000 (20:42 +1300)
commitcdacd6abc09054bef3ff9fb3717a5f7914c88386
tree0a825d39fdb5ba32b26d54b57f3f5b01ca56f22a
parentfec6098a316500c2e29a625c5dadc960bf25b7b7
Rationalise Activity api ACLs

We have a lot of inconsistency about how (and if) activity ACLs are applied. Note that permissions only apply
when the api is being called with check_permissions = TRUE - e.g from the js layer.

This PR changes the logic used for the activity.get api to be consistent with the report logic
which
a) is the most performant variant
b) is the one with the least code complexity
c) is more consistent with CiviCase
d) allows hooks to modify the permissions applies
e) creates consistency between api v3 & v4
f) is consistent with some site user expectations but not others - the presence of all this inconsistency
is an indicator not everyone wants the same thing but given that choosing a performant &
maintainable option for core seems like a good criteria.

After this patch
1) the 'view all activities' permission will no longer by-pass all other ACLs. One could argue that's exactly
what it means - but it doesn't do that in the UI which seems like the standard elsewhere.
2) a user will be able to view an activity via the api if they have permission to view  ANY contact linked to it (before it was ALL contacts via the api)
3) a user will not see the names of any contacts they do not have permission over when requesting activity contact details in return parameters
4) getcount will no longer by-pass the api
5) performance is improved

Places where permissioning applies to activities
- activities listing on contact - shows actitivies & related contact names regardless of permission to view the contacts
- activity search results -- shows actitivies & related contact names regardless of permission to view the contacts
- activity view page - links to view the activity exist on the above 2 screens but will give access denied unless they
can see ALL related contacts
- activity reports - shows activities if ANY related contacts are permitted, suppresses names of unpermitted contacts

Potential follow on steps
1) make the activity tab listing consistent by switching from the unperformant deprecatedGetActivities fn
to the performance getActivities fn - there are no remaining blockers to that.
2) align the activity view screen & add in hook call there too
3) align activity search results screen, address performance issues there too....
CRM/Activity/BAO/Activity.php
CRM/Core/Permission.php
api/v3/Activity.php
tests/phpunit/CRMTraits/ACL/PermissionTrait.php
tests/phpunit/api/v3/ACLPermissionTest.php