CiviCRM Community Forums (archive)

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
 

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

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

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

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

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.

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. 

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?