CiviCRM Community Forums (archive)

I've been looking/trying for several hours now, and a fairly simple ACL setup is proving to be nearly impossible for CiviCRM 2.0

The Case:
Private drupal intranet
civicrm used for cross-organization and program specific contacts
most contacts can be viewed/edited by staff
some contacts can only be viewed/edited by certain program staff.

Example:
By default contacts are "public" (any staff member can view/edit)
If a contact is added to group "Program X" only members of the group "View/Edit Program X" can view and edit those contacts.

Seems simple? Maybe I'm missing something.

First roadblock - Automatically adding 'staff' members to the 'staff' group:
 - Cannot use Smart Groups for ACLs
 - Drupal syncing only goes civimember -> drupal role and not drupal role -> civigroup

Second Roadblock - unrelated ACLs essentially limit any contacts without a group
 - contacts without groups should not change how they are affected by adding an ACL for contacts with a particular group.
 - this functionality necessitates the following:

Third roadblock - Adding contacts to a group by default
 - only necessary because adding the first ACL essentially limits all contacts (ex. no ACLs - all contacts show fine ||| add an ACL for group 'Program X' and now any contact without a group cannot be viewed.)
 - Even if smart groups could be used for ACL - cannot use negative logic (all contacts NOT part of 'Program XYZ')
---------------------

Besides doing everything manually, which making sure the staff knows that every contacts must be added to a particular group (eg, public or program specific), is there a way to do the following in a more automated manor:

1. Restrict access to contacts within a particular group
2. while allowing the rest of the contacts to remain unrestricted

What am I missing? It can't be this limited.

Thanks for the reply,

I was really hoping for a "omg it's so easy - you missed XYZ".

Unfortunately, I can't upgrade to 2.1 until I can go to Drupal 6 (come on Panels2!)
-----------------------

I also saw this post: http://issues.civicrm.org/jira/browse/CRM-3007 , and I cannot agree more. In addition to ACLs not meeting simple requirements, certain design choices are truly baffling (drupal group to civicrm group to civicrm role to civicrm acl why on earth is this necessary).

Also the mixing of content groups and administrative groups merely adds confusion with zero functionality.

I'm sorry for the rant - but this is a surprisingly unintuitive access system. Hopefully this has been fixed in 2.1 (I haven't tested yet), and documentation (or commented code!) seems sparse.

Lobo - I am wondering if the ACL-work around that we implemented would be useful to others. It has been covered in both the Forum and the Wiki - but is this something I should try and lean on Chris to add to the documentation - or is there still some addition to the core that has to be done.

It certainly seems like it would answer the needs of http://issues.civicrm.org/jira/browse/CRM-3007

I can't believe how easy this version of 'access control' that we have is.

Cool - but guess I am still unclear if the route we took is well covered in the documentation so people know there is another route they could consider.

Yep - was just about to add but saw you had edited.