Answers.Body: <p>If you are using groups as the criteria for your ACLs, this extension might help to make the process more intuitive: <a href="https://civicrm.org/extensions/autogroup-helper-for-group-based-acl-environments" rel="nofollow noreferrer">https://civicrm.org/extensions/autogroup-helper-for-group-based-acl-environments</a></p>
  <p>I tend to use either custom fields for the ACL criteria, or addresses, and then use ACL hooks to programmatically implement the ACLs (if you have more than a dozen 'groups', then managing the ACLs using the admin interface is a lot of clicking to setup).</p>
  <p>Although if you use custom fields or addresses for ACLs, then you also have to make sure that group/regional-admins cannot change those values so that they can access other groups (ex: using a 'post' hook that will throw an error if an invalid update is attempted, and monitoring changes to those values).</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-05-23T13:21:54.770Z
Answers.LastActivityDate: 2024-05-23T13:21:54.770Z
Answers.UserDisplayName: bgm
Body: <p>I have observed the following behaviour during testing an ACL-Setup. Could anyone let me know if this is the expected behaviour and if there are any more or less particular plans to change that in the future?</p>
  <p>A user is only granted access (via ACL) to a limited group of contacts - that seems to work fine. The user will also be able to create groups via the CiviCRM UI - that makes sense too.</p>
  <p>However the user won't be able to add contacts visible to them to the group they just created unless an administrator creates another ACL Permission explicitly for that group.</p>
  <p>For me the expected result would have been that the user can add visible contacts to any CiviCRM Group (unless maybe it is an acl-group). I think that was also the behaviour in earlier CiviCRM Versions (I am currently testing on 5.51.1). I suspect that something was changed in CiviCRM Core because users used to be able to add themselves to ACL-groups thus escalating privileges.</p>
  <p>In short I would be happy to get some feedback on:</p>
  <ul>
  <li>Is this a bug or a feature?</li>
  <li>Is there any documentation /
  information on the (changed) behaviour described here? Such as adding CMS-permissions to add contacts to regular groups, ACL groups etc...</li>
  <li>Are there
  any plans to further change / adapt / extend the behaviour of ACLs in
  CiviCRM?</li>
  </ul>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-11-10T14:12:47.363Z
Comments.Text: maybe/probably related thread: https://civicrm.stackexchange.com/questions/28909/staff-restricted-by-acls-cannot-use-see-any-other-groups?rq=1
Comments.UserDisplayName: Fabian
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-11-10T14:13:12.860Z
Comments.Text: Potentially related Issue in CiviCRM: https://lab.civicrm.org/dev/core/-/issues/430
Comments.UserDisplayName: Fabian
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-12-01T13:44:28.457Z
Comments.Text: I get the feeling that either on the CMS or on ACL-level we are missing permissions for adding or removing contacts from groups (ideally differentiating between regular, reserved and permissioning groups).
Comments.UserDisplayName: Fabian
Tags: <groups><acl><core>
Title: What is the expected behaviour of ACL in regard to group management (and are there changes planned for the future)?
ThreadText: # What is the expected behaviour of ACL in regard to group management (and are there changes planned for the future)?
  
  (Asked by: username_0 on 2022-11-10)
  
  I have observed the following behaviour during testing an ACL-Setup. Could anyone let me know if this is the expected behaviour and if there are any more or less particular plans to change that in the future?
  
  A user is only granted access (via ACL) to a limited group of contacts - that seems to work fine. The user will also be able to create groups via the CiviCRM UI - that makes sense too.
  
  However the user won't be able to add contacts visible to them to the group they just created unless an administrator creates another ACL Permission explicitly for that group.
  
  For me the expected result would have been that the user can add visible contacts to any CiviCRM Group (unless maybe it is an acl-group). I think that was also the behaviour in earlier CiviCRM Versions (I am currently testing on 5.51.1). I suspect that something was changed in CiviCRM Core because users used to be able to add themselves to ACL-groups thus escalating privileges.
  
  In short I would be happy to get some feedback on:
  
  * Is this a bug or a feature?
  * Is there any documentation /
    information on the (changed) behaviour described here? Such as adding CMS-permissions to add contacts to regular groups, ACL groups etc...
  * Are there
    any plans to further change / adapt / extend the behaviour of ACLs in
    CiviCRM?
  
  **Tags:** groups, acl, core
  
  > **Comments:**
  > **username_0**: maybe/probably related thread: https://civicrm.stackexchange.com/questions/28909/staff-restricted-by-acls-cannot-use-see-any-other-groups?rq=1  
  > **username_0**: Potentially related Issue in CiviCRM: https://lab.civicrm.org/dev/core/-/issues/430  
  > **username_0**: I get the feeling that either on the CMS or on ACL-level we are missing permissions for adding or removing contacts from groups (ideally differentiating between regular, reserved and permissioning groups).  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2024-05-23. Score: 0
  
  If you are using groups as the criteria for your ACLs, this extension might help to make the process more intuitive: <https://civicrm.org/extensions/autogroup-helper-for-group-based-acl-environments>
  
  I tend to use either custom fields for the ACL criteria, or addresses, and then use ACL hooks to programmatically implement the ACLs (if you have more than a dozen 'groups', then managing the ACLs using the admin interface is a lot of clicking to setup).
  
  Although if you use custom fields or addresses for ACLs, then you also have to make sure that group/regional-admins cannot change those values so that they can access other groups (ex: using a 'post' hook that will throw an error if an invalid update is attempted, and monitoring changes to those values).
  
  
  ---
  
  