ACLs - team permissioning on individual Activities

[Donald Lobo]

hey dave:

dont think this is a trivial project. For ACL's to be effective, you need to be able to group objects together in a easy way. For activities you can do it via source contact id / assignee contact id / target contact id / acitivty type ec . I suspect different orgs might want to set it up differently

bottom line, i think its at least a 40-80 hour project (estimate below). maybe more depending on final specs

An easier short term option might be to do this ONLY via a hook (similar to how we do events). In this case it gets a lot easier since the hook can then send in additional clauses to the query

However i do think that restructuring the activities table so that all the contacts are stored in one ActivityContact table will make the above easier and more efficient

lobo
 

[davej]

Thanks Lobo,

What would you estimate for allowing Activity ACL via hooks only?

Dave J

[Donald Lobo]

i think adding the hook is quite easy (10-20 hours of work or so)

you might want to look at the queries and see if you can modify them to emulate an ACL hook. I'm also not sure if/how this will affect search/report which use its own queries.

Basically the query needs to answer: "What class of activities can this contactID see". you might want to go thru that exercise with your use case

lobo

[gastrit]

Hi!

I want a simple permissioning structure for Cases (and the activities in the cases) based on case type. I want to have one case type that you require additional permission to see/edit and that every other case types can be viewed/edited by everyone. So one group that can se/edit all case types. And all other users can se/edit all case type but one "special" type.

You mentions the "pseudo table" concept but I did not get what that is about. Is there any way I can do this fast (i have php and mysql skills). It does not have to be a nice, good looking solution.

// Jonas

[Donald Lobo]

I think the easiest way might be to see how event implements permissioning and then do so in a similar manner.

Event exposes a hook that allows another module to modify the query, and i suspect you could do the same with cases

lobo

[petednz]

Do we know if anyone has implemented an ACL control on a particular Activity Type via a hook?

[davej]

Hi Lobo / Pete / anyone interested in Activity ACL,

Do we know if anyone has implemented an ACL control on a particular Activity Type via a hook?

Not to my knowledge, but we've just had an enquiry about this: the requirement is to restrict a certain set of users to only being able to view, search, edit or create activities of a specified type.

This doesn't need to be configured through the UI, a hook would be fine. We'd like to do it in a nice non-core-hacking benefiting-the-community way if feasible.

Lobo, you suggested looking at the ACL implementation for events. CRM_Event_BAO_Event::checkPermission() gets a list of all events and builds an array of all permitted events from that. I'm wondering whether that's a good idea for activities, in terms of resource usage and scalability, given that some sites have tens or hundreds of thousands of activities. It seems profligate to load a list of all activities on every request where we need to know if a particular activity may be viewed.

What would be a good approach to implementing this requirement? I think the client might potentially be open to sponsoring/co-sponsoring the needed changes to core, depending on cost, if those could more efficiently be done by the core team.

Dave J

[petednz]

Dave did this materialise or 'ether'ise (disappear in to the ether)?

[davej]

Hi Pete,

I think it's a case where the client didn't get back to us - I'm trying to confirm that.

Cheers,

Dave

[davej]

I think it's a case where the client didn't get back to us - I'm trying to confirm that.

Confirming that was more difficult than you'd think! :-) The upshot was that after initially making encouraging noises about getting this spec'd as a chunk of core development, the client told us to put it on hold.

Dave J

[pmoz]

Old issue I know, but we'd be interested in helping to fund any development around implementing ACLs and Activities.

Overall, it would be nice if the ACLs could work with Cases and Activities.

[Donald Lobo]

Can you give more specifics on how granular u'd like the permissions to be and other details.

Both activities and cases have multiple contacts involved which make it a bit more complex. Do u permission on all involved contacts or only one or some subset?

If i had to guess, this is at least a 50-100 hour project. If your org can help fund it, that would be great addition to civi

lobo

[pmoz]

We are a pretty large non-profit that works in many different areas of human services.
MH, homelessness, elderly, children, etc.

We are using Civi as our only database for all of our programs and for example, would like to be able to hide Mental Health Activities and Cases from other departments that don't collect health related information. 

However, we would still like for all staff to see the contacts if they are in the system. 

We also would like for all staff members of the Mental Health program to be able to edit cases that they did not create but are of the same case type.

On another board, someone mentioned a CiviCase UI, which we are also interested in as well as tying relationships into profiles.

That's a lot...one thing at a time.

I don't know what the per hour rate is, but we would be glad to help with some funding. 

[Donald Lobo]

Consulting contract and rates here:

http://wiki.civicrm.org/confluence/display/CRM/Consulting+Services+Agreement

If your org has the budget to fund the below (i.e. USD 5-10K), we'd be happy to take the next steps and get more details and specifics.

lobo

[pmoz]

You are prompt Lobo!
After developed, would this be available for everyone?

We could definitely kick in a fair chunk of that.
Would we be in it alone or is this a Kickstart kind of thing?