Skip to end of metadata
Go to start of metadata

This Make it Happen aims at more granular security for individual Activities and Cases.

  • ACL control over individual Activities.
  • ACL control over individual Cases.
  • UI to implement ACLs for Activities and Cases.

This Make it Happen could potentially lead to more organisations using CiviCRM as implementation in a more secure environment would be much easier.

The Need

Currently, all CiviCRM users with "View Cases" permission are able to see all Cases, Activities and related data.

Sensitive data related to individual Cases or Activities is exposed to any user with appropriate permissions.

Functionality

The new functionality would enable Civi users to:

  • Limit Case accessibility through ACLs, including view, edit, create and delete.
  • Limit Activities accessibility through ACLs, including view, edit, create and delete.
  • UI to implement Case and Activity security.

Use Case

As a large human service agency with many different program areas, we need to limit who can see sensitive data related to Cases and Activities.

  • Users in our Food Pantry need to be able to view and edit Food Pantry Cases, but should not see other Case types that contain medical data.
  • Supervisors in our programs need access to Staff Disciplinary Activities that entry level staff should not have access to.

The Nitty Gritty

  • Add ACL support for cases via a hook and ensure it works across all screens
  • Add ACL support for activities via a hook and ensure it works across all screens
  • Add UI support for using the above hooks for "Case and Activity types" only. i.e. a group of users can only see the following "Case types" and/or the following "Activity types"

Making it Happen

This project has been quoted at 100 hours at $125 per hour for a total cost of $12,500.

If this functionality sounds like something your organization could utilize, please consider contributing to the Make it Happen campaign.

If you would like to discuss further, please drop me a line at pmosey@chscorp.org.

Related Forum Discussions

ACLs - team permissioning on individual Activities

Permission to See Cases without Permission to See Activities?

Labels
  • None
  1. Oct 12, 2014

    Thanks for getting this project going! I would love to see ACLs for activities and cases as part of CiviCRM core. 

    I have some custom code for controlling access to individual activities. The way it works is that there is a custom data field called "Privacy" ( in a data set that is "used for" all activities) which currently has 2 options (and could easily be expanded to more options): "Anyone" or "confidential".  If the user creating or editing the activity choses "confidential" then only people in a certain CiviCRM group can access that activity. (This is done by hacking the Activity BAO class to enforce access.) I will put this code on GitHub so perhaps it can be of use.

    Your architecture of limiting access to activities based on the Activity Type seems very limiting. For example: I have custom field sets that are "used for" specific activity types.  If ACLs are tied to activity type, I would have to practically double the number of activity types, such as "meeting" and also "confidential meeting", "phone call" and "confidential phone call".    Personally I like how authorities with "Notes" work because the end-user creating the note knows exactly who will have access to that specific note. 

    Just curious - Is the CiviHR team involved in this effort? Seems like many or most CiviHR activities and cases would need ACLs too.

  2. Oct 11, 2014

    Hey Sarah,

    Interesting thoughts.

    I love the way notes are handled with the extra privacy option, but notes are tied to the contact, not the case as far as I can tell.   We need all of our case managers for example, to enter any updates (case notes) attached to the case not the profile.  I also am not comfortable relying on the end-user to remember to ensure private information remains private.  We have many end-users, most are case managers and should only have access to activities associated with their cases.  If the permissions to cases and activities are set up, then all of this could be taken out of the end-users hands.

    I'm not sure I follow your thought on having to create duplicate activity types.  This will add many more ACLs in our situation because we have over thirty case types and fifty activity types.  There could be many ACLs for one case type to cover all of our situations, but it wouldn't require me to create duplicate activity types.

    Along those lines, I'm not certain if I would prefer the permissions in the ACL area or on the activity and case screens.  The ACL setup is not very intuitive and does require many entries.  It seems that when creating or editing a case, it would be very intuitive to select the groups that have access to it on that page.

    To my knowledge, the CiviHR team is not yet involved.

    Thanks for sharing your code!  I'm anxious to take a look at it and see if we can implement it in our situation.

  3. Oct 11, 2014

    The more I think about controlling ACLs via activity type (and not have to worry about the end-user remembering to check a box) the more I think this can work for my situation.  Question: How would "author only" style permissions work? for example, only the person creating the activity should have authority to see it.   

  4. Oct 12, 2014

    The reason I was thinking I would have a lot more activity types than I have now is because some phone calls are confidential, and some are not. Some meetings are confidential, and some are not, and so on for my various activity types. 

    A partial list of my current activity types: phone call, meeting, visit

    After this Make-It-Happen project, I an thinking my list of activity types will need to expanded to be:

    phone call, private phone call, meeting, private meeting, visit, private visit  

  5. Oct 12, 2014

    It may depend on how you use cases.  In our situation, we use cases extensively.

    My thinking is that activity types associated with a case type that you don't have permission to would be hidden, while the same activity associated to a case type that you do have permission for would display.

    Example:

    Activity type "Meeting" is associated with Case type A and Case type B.

    I have permission for Case A, so when I go to the activities tab on a profile, I would only see the activities associated with Case A, the Case B activities would be hidden

  6. Oct 16, 2014

    Great idea (I need it ...), some thoughts...

    Having ACLs to view cases will be a lot better than having to add people to a case so they can see it!

    For activities, I presume that limiting the ability to "create" and "view" activities means that they wouldn't appear in the Activity selector/drop-down.  This is a great benefit, shortening the list of possible activities to just those that a role/group needs.

    Second... this is a bit of a stretch ... any chance of nesting activities, as groups can be?  Then instead of having to have an ACL for each restricted activity the relevant parent activity and all children could be restricted?

  7. Oct 16, 2014

    Hmmm.  

    Nesting activities is something I hadn't considered.  But I'm certain that could be very useful.

    However, I am imagining "nesting" activities in cases.

    Any ideas of how to go about nesting activities?

  8. Nov 03, 2014

    We've been thinking about something similar, because our use of CiviCase takes things in a different direction - we have refactored cases to represent enrollments into research studies. Currently we're only supporting a small number of research studies run by a single team, but we would like to be able to use CiviCRM to monitor all recruitment into research projects across our organisation. One of the limitations currently is that we wouldn't be able to mask participant's enrollment into a study from staff who do not work on that study. We had scoped a number of possible access levels, probably more than the standard view, edit own, edit all ACLs for each case type, because we'd also like an access level that enables the user to see the case exists (and maybe the status) but not access any of the details of it (i.e. not see the timeline of activities, or the case roles). We've even discussed a possible use case which would require the case type itself to be hidden - so the user would know there was an active case, but wouldn't know what case type it related to. Are any of those refinements of interest?

  9. Feb 16, 2015

    I'm with Sarah in that I think that there should be an ACL that says, "I can view my own activities" and "I can edit my own activities" are helpful in addition to "Users in X group can view/edit activities".  I'll see if my client is up for any funding toward this.


Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.