1

The organisation I'm setting up Civi for does not assign activities to individual people but works in teams.

For example a client might be referred to the housing team to see if they qualify for housing. This activity would be created by a caseworker and edited / completed by a (any) member of the housing team.

This is just one example, there are also other cross-team activities.

The only way I have been able to make this work is by giving all caseworkers edit access to all other caseworkers.

This has not gone down at all well with the caseworkers who do not want their contact details viewable - and editable! - by so many people.

Any advice on how I could make it possible for A to edit an unassigned activity created by B, without giving A the ability to see or edit B's contact information?

Improve this question

2 Answers 2

Reset to default
1

The National Urban League funded work to add ACLs to cases, which laid the groundwork for adding ACLs to activities. See here: https://civicrm.stackexchange.com/a/8005/12. So one option would be to develop (or fund the development) of applying ACLs to activities. I'm guessing the core team would be willing to take that on as a Paid Issue Queue item, since they did the groundwork. This would be the most flexible arrangement.

Additionally, CiviDesk has implemented a hook that allows extension authors to escalate permissions via an extension with a new hook, hook_civicrm_permission_check. This code has been written but at this time has not yet merged into upstream CiviCRM. See CRM-19256 to see if that's still true now. If you're able to QA this patch, please update the Jira ticket to say so.

The second approach is much less work to get into everyone's hands, but the first approach would allow non-coders to define their own activity permissions.

Improve this answer
2
  • Thanks, I'll try the hook. Quick == good, right now, as some users are being very vocal indeed about the possible catastrophic effects of trusted, confidentiality-sworn volunteers seeing each others' phone numbers. (If I seem flippant it's only because I sat and watched so many of this impressively security-conscious minority writing their passwords down).
    – naomi
    Commented Dec 14, 2016 at 21:39
  • 1
    Well the hook seems absolutely great. I've mentioned on Jira that I'm (ahem) "testing" it and will keep them posted. Thanks, ass saved!
    – naomi
    Commented Dec 15, 2016 at 14:13
1

Another option might be to look at using Related Permissions extension. User A is a member of Team B, and has a permissioned relationship over the Team and therefore could (maybe) edit Activities that are assigned to the Team, without having access to the other people who have a relationship to the Team.

Improve this answer
1
  • Thanks, I might come back to this but it would mean adding in the notion of assigning to teams whereas the way I've set it up we don't assign them, we just use dashboard reports to alert members of the relevant team when certain activities are scheduled. Also some activities need to be visible by multiple teams. It would mean coding anyway in order to add default team assignments to activity types... I'm hoping the hook will be sufficient!
    – naomi
    Commented Dec 14, 2016 at 21:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.