ACLs - team permissioning on individual Activities

[matth3wh]

First up - CiviCRM is a great package and a great achievement!  Core devs have done a wonderful job.
I'm wondering about our not-for-profit org sponsoring (/co-sponsoring) Permissioning / ACLs - particularly on individual Activities...  I noticed this feature is maybe mentioned in the Features Roadmap planned for CiviCRM 3.2...

Situation:
Our company is wanting to use CiviCRM as our contacts system...
We are looking at paying a developer to add some of these ACL features (preferably now-ish - before December 1 2009).
However, I would rather try to sponsor getting this sort of thing in to CiviCRM core and helping all (and us with upgrade path), rather than creating a broken-upgrade-path-but nice features release of CiviCRM ...

I'm wondering how many hours of work and $ costs to get something like this mentioned below in to core?
 a) the Roadmap  or  b)  Our use-case  ...?

Our Use-Case...
Our not-for-profit is wanting to provide private Activities permissions for each of our teams (groups in CiviCRM) so we can all use one system and also provide a reasonably high degree of privacy.
* That would mean ACLs on each individual activity and...
* Presentation / UI changes on all Activity related pages to allow this to happen...
* Filter SQL queries / results so that people without permissions do not see (and cannot get to) Activities they are not supposed to...
* New(or integrated) DB Table to store Permissions related to individual Activities...
* Activities by default are private to the [primary] (or only) group a person belongs to... with an option to allow / add another Team (group) to view/edit the specific Activity if needed.

Example: Our Leadership team write an Email Activity to someone, and due to privacy issues we only want the contents of this Activity available to members of the Leadership team itself.
Example: Our staff caring team only want their Phone / Meeting / Follow-Up Activities to appear on contacts to their own team (by default) or (rare) option to choose to allow another group to have view/edit permissions to this Activity.
How about an exception Example: Our recruitment team by default want their Activities viewable to all... but no doubt the option to set permissions for only their Team.

Some desired outcomes:  
* The Everyone's Activities page only shows the Activities people have permissions to see...
* Addition of (or replacement of the Everyone's Activities page with) a Team (group) Activities page...
* Individual contact's Activities TAB only displays Activities that the current logged in person has permissions to see...
* Individual Activities remain private to each team as desired to maximize privacy / legal compliance
* Default permission to members of Team (CiviCRM group)


Roadmap Features - REF - http://wiki.civicrm.org/confluence/display/CRM/CiviCRM+v3.2

Permissioning / ACLs
    * Move all permissioning to within CiviCRM (i.e. no longer use Drupal permissions, but this enables us to better support Joomla and other CMS' (like WebGUI)
    * User (constituent) - level control over sharing / visibility of their own (profile) data.
    * Task-level permissioning - control over 'actions' list (send email, mailing labels, delete contact, etc.)
    * Permissioned access to contact tabs which aren't component-related - Relationships, Activities, Groups, Notes, Tags (hide tabs that a user doesn't have permission for).
    * Extend the "permissioned relationship" concept implemented for Employee / Employer to cover any relationship type.

Some development options for us:
a)  Programmer to hack at CiviCRM 3.0x to deliver required features (most likely leading to broken upgrade path)
b)  Try to Sponsor features in to Core (??)
c)  Keep CiviCRM in tact (as is) and have paid Development (dashboards/templates) to pull CiviCRM contact info in to our Wiki framework for individual user profile pages...  (pluses and minuses - possibly working out of two different systems... private data kept in separate system but has fine grained ACLs already...

Any suggestions on which direction we should head would be greatly appreciated.   ;-)

Kind regards,

Matt

[Donald Lobo]

i suspect implementing acl's on activity types is WAY easier than implementing them on activities per se. There are quite a few auto generated activities (when an event/contribution/mailing transaction takes place) and the scope just increases significantly if u do it per activity. Note that contacts are permissioned via groups and not individual contacts.

Note that there are 3 sets of contacts associated with an activity: person who records it, the target contacts and the assigned contacts. So permissioning can potentially be done via one or more of them

Given your timeframe / schedule, i suspect option a (but without the hacking part) is probably your best bet. I think what might be easiest is to add a "activity hook" (or something like that), that allows the site to filter activities based on who's viewing the activities. I suspect this will need to be introduced in 1 - 3 places at the most (the code is quite modular). We'd be happy to extend core to add a hook like this to avoid the "hacks" while working with your developer (i.e. your developer does most of the work in the design/spec/thinking about the hook implementation)
lobo

[matth3wh]

Sorry, I'm only getting back to this post now...
By the way - Hope you had a good Christmas / New Year / holiday break away

I got the timeframe shoved back some distance - some breathing space seemed sensible...  

November got spent importing data and testing permissions... - and reading about permissions...
End Nov / early Dec - Data-cleansing; Raphy http://forum.civicrm.org/index.php?action=profile;u=11005;sa=showPosts and I went through bug hunting; presentation to stakeholders...
Dec - rest...
Jan - some user training/doc, remembering where everything is up too...  Arrgh almost 3 months have gone by!

Upon re-reading your post and talking with our various teams and seeing what would suit best the Activity hook and permissions on certain Activity Types seems like the best way forward
(and hopefully cleaner in terms of upgrade path, and more cost effective in the long run)

So an Activity Hook / custom PHP without breaking core sounds best...

Areas to change would be?

• Activities ..
• Contact/View
• DB

REF:

• http://svn.civicrm.org/hrd/trunk/drupal/hrd.module
• http://wiki.civicrm.org/confluence/display/CRMDOC/CiviCRM+hook+specification#CiviCRMhookspecification-hookcivicrmaclWhereClause
• Implementing a custom ACL system in CiviCRM - http://forum.civicrm.org/index.php/topic,3695.0.html

[Donald Lobo]

yes, u'll need to "acl"ify all the code that touches activities, so contact view / activity search etc

lobo

[mhonman]

We're also looking for something like this (not surprising as I'm Matt's opposite number in the UK  ).

However maybe we should be targeting the Case functionality (with a bit of collateral damage to Activities along the way...).

Then each team would maintain "their stuff" in a particular type of Case.

Activities seem to have originally been intended for "ephemeral" day-to-day contacts, so that if a team of mobilisers are working with a contact they can see what their colleagues have been telling them!

Here are some of the things we would like to do...

There is a team who organise short-term placements (gap-year like) for volunteers - something case-like is needed to track the progress of each application.

There is a member care team who look after the emotional well-being of our workers - cases also very useful to them, but their info needs to be walled off from the short-term team.

Placement history for our workers - could probably do with multi-record custom data groups, but we want to link to the organisational context of the placement - so case/activity records are an easy way to do this.

You'll see that in effect we are trying to add a bit of "HR" functionality to our CiviCRM setup.

[Dave Greenberg]

Check out this description of a 'limited access' option for CiviCase that we are implementing for 3.2 as part of the CiviCase Phase 3 project sponsored by Physician Health Project:

http://issues.civicrm.org/jira/browse/CRM-5666

I think it "might" be close to (or exactly) what you need.

[mhonman]

That's interesting... very clever and would work well in situations where someone outside the short-term placement team is drafted in to help with a particular short-termer.

However it seems that we would also need type-based ACLs on cases... so that different teams in the organisation can manage their particular types of case.

As I understand it the ACL mechanism provides for per-record permissions. If the target table "object table" has children then the permissions apply to records in the child table(s). Custom Groups are the classic example - ACLs on civicrm_custom_group actually apply to all custom data records with the corresponding group id.

With Cases, there is no simple "master" table of case types - they are a type of record in civicrm_option_value. This could be fudged by using a pseudo table name in civicrm_acl, for example "civicrm_case_bytype". That does rather violate the principle of least astonishment...

[Donald Lobo]

let us know if you are interested in developing or sponsoring "classic" ACL's for cases.

there are multiple options for permissioning there:

a. based on who created/opened the case (mostly via a hook)
b. based on who the case participants are / case client
c. based on case type (in which case u'll use the "pseudo table" concept)

I'd suspect this is a 40-80 hour project depending on the options above and cleaning things up etc

lobo

[mhonman]

On Fri we demonstrated the CiviCase functionality to one of the teams who would probably want to use it - and the answer is a resounding Yes... it's a long time since I've seen such happy users.

So I would definitely like to go the "classic ACL" route - i.e. pseudo table.

However this particular team often relies on an "outsider" from the regional team in the potential short-term worker's home area to interview them before the trip and debrief them afterwards.

So permissioning based on case participants (the CRM-5666 work mentioned by Dave) will also go down a treat although of lower priority.

The 40-80 hour estimate sounds about right; assuming I tackle it the total duration will be towards the high end of that range as there'll be a lot to learn. I've modified the ACL UI already, but the real challenge lies in applying the ACLs consistently and without breaking anything else. I'd suggest introducing a checkPermissions function to the Case BAO as has been done for events...

The question does arise, how do we avoid tripping over each other?

[matth3wh]

We're happy to contribute some AUD$$$$ + php time on this end to help get this thing up and running.

Classic ACLs and the CRM-5666 would be a great combination for the Case management area particularly..
It would be great to see this deliver some fine grained permissions. 

I'm surprised other bigger companies using Civi haven't already targeted this area. (??)

I'm guessing this gets spec'd out in the wiki?

[Donald Lobo]

i'd start by specing out the features and use cases on the wiki. between the two groups (and the BC CiviCase folks) we can figure out what we can/should implement and then decide who'll do it and who'll fund it

lobo

[Donald Lobo]

how about a chat on IRC so we can figure out what makes sense, what needs to be done etc.

i re-read the thread and seems like: permissioning on activity_type makes sense and then an acl hook where folks can permission on source_contact_id makes the most sense.

lobo

[davej]

Hi Lobo / Matt,

Did anything get implemented for ACLs on activities?

Dave J

[Donald Lobo]

dont think so (at least we did not receive any patches

lobo

[davej]

Hi Lobo,

That's a shame. We've been asked about a requirement to mark some activities as "Private" (only visible to members of an ACL group that the source contact belongs to) and others as "Personal" (only visible to the source contact). I think it might be preferable to do this with custom fields rather than activity types, so we can have e.g. private or personal meetings, phone calls, emails etc without having to replicate activity types (personal phone call, private phone call etc) but activity types would be OK too. I guess we just need activity searches/views etc to trigger & respect ACL hooks. Could you give us a rough idea how much work that would be?

Thanks,

Dave J