CiviCRM Community Forums (archive)

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

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

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.

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...

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?

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

Hi Lobo / Matt,

Did anything get implemented for ACLs on activities?

Dave J

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