1

There are a couple of posts, listed below, already on this topic - but I'd like to follow up:

SUMMARY

I can create an ACL role and limit access to a custom field group - which is seemingly wonderful. Data that should not be visible to everyone is not.

BUUUT any user (with the ability to edit a contact) can add users to an ACL group. I feel it renders ACL roles/restrictions pointless. (We have users who need to be able to edit a contact, to adjust contact information and such but shouldn't be privy to all the custom data in the system.)

How do I prevent a user from adding contacts to ACL groups?

Permissions, ACL and Groups

QUESTION Does anyone have feedback on the Group Protect extension? It looks very promising but the notes indicate it's a work in progress from early 2016. Or is anyone taking a different avenue to prevent users from adding themselves to ACL groups?

9
  • Do you have the CMS based permission to edit groups for those contacts? If you dont allow that, a restricted user can only add contacts to groups that they have an acl to view/edit. Aug 1, 2018 at 8:47
  • (Sorry, didn't say I was in Drupal). Yes, I do have the CMS permission for edit groups. I do see your point, if I don't allow them to edit their own contact they couldn't then add themselves to groups. That could work for some situations. For us, it doesn't solve the problem at large, for anyone they do have permission to edit they could add an ACL group. Also, there is a LOT wrapped up the edit contact capabilities (relationships, tags, signatures) that we still need.
    – RayWright
    Aug 2, 2018 at 13:27
  • Editing the own contact is fine. But if you were to revoke the cms permission to edit groups they can only add those groups, that they have the permission for. Aug 6, 2018 at 8:59
  • I may be misunderstanding you but the CMS permissions for CiviCRM: Edit Groups states: "Create new groups, edit group settings (e.g. group name, visibility...), delete groups" and has nothing to do with adding or removing contacts to groups. I have user with the CMS permission edit groups turned off (but edit contacts turned on) and no ACLs added at all. That user can add contacts to any group they desire. The ACLs for groups only controls the ability to edit contacts in that group not whether you can add/remove membership to that group.
    – RayWright
    Aug 6, 2018 at 20:04
  • 1
    Oh, that is correct. The ability to view every group is actually tied to the cms permissions "view all contacts" / "edit all contacts". If you disable those you can use civicrm acl rules to allow view / edit permissions of contacts within specific groups. As a consequence the user will only be able to see said groups and is not able to assign ACL groups even if the user has the permission to edit the contact. Aug 7, 2018 at 10:26

3 Answers 3

2

As you have noted, the big problem with the ACL group system is the lack of control around adding to groups. I've used the Group Protect extension previously and it does the job.

3
  • 1
    But this extension doesn't work for 5.4.1 - it resulted in a solid database error - I had to remove it get going again.
    – Andy Clark
    Sep 3, 2018 at 12:31
  • 1
    @AndyClark did you see that a few days ago Jon made a commit to the project. It might work in 5.x now! github.com/CiviCooP/org.civicoop.groupprotect/commit/… (I won't be able to test for another week or so.)
    – RayWright
    Dec 6, 2018 at 15:21
  • Ha - I just came across this question trying to answer another ACL question! Yes, I have Group Protect working with 5.7.2 after my latest changes. Dec 6, 2018 at 20:39
1

The ability to add groups to a contact depends on the visibility of groups for the user. The cms permissions "view all contacts" and "edit all contacts" grant visibility to all groups in the system.

You need to remove the cms permissions "view all contacts" and "edit all contacts" for this role and add an acl for each civicrm group that the contact should be able to view or edit. This way you can set permissions to edit/view contacts and restrict the visibility of groups.

1

We have found that limiting users in this way works well for access purposes, however, we have also found that users limited to groups in this way can create a contact that has no group. If they don't add a group, then they loose the ability to see or edit the contact they tried to add. Often, they then add the contact again. (and sometimes again).

Also, when adding a contact through Cases->New Case->New Organisation, it is not possible to add a group on that 'easy-add' screen.

It then takes an admin to login and add the group that the user forgot to add.

We can see no way of making the selection of a group compulsory (or a default) when a user adds a contact on the Contacts-->New Organisation screen.

We have treated this as a 'user coaching opportunity', emphasising that if they don't choose the right group, it's going to take extra time to get the data in, as they'll have to contact an admin to get the group added. At least all our users now know what to do if they forget to put a contact in the right group.

We also insist that a user creates an organisation before adding a case, so that the organisation is in the correct group.

Just thought I should mention these small issues we have found, and their work-rounds to hopefully save someone else the pain of working it out. Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.