Answers.Body: <p>Yes, this is a shortcoming in the current acl system.</p>
  
  <p>One possible workaround for this might be to implement the post hook on the civicrm_group object. The post hook can take the contactID of the person creating the group and add an ACL giving this person access to the group.</p>
  
  <p>You can implement the above hook in an extension. Probably worth considering including this in core need on a setting</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-23T21:46:31.530Z
Answers.Text: Thank Donald.  I looked at the group object and none of the fields appeared to offer any permissions control more than what was on the create group form, so I think this is a dead end.
Answers.UserDisplayName: bdombro
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-25T03:26:45.287Z
Answers.Text: You will need to use the post hook to create the relevant ACLs for that group. The group object does not have any permissioning fields.
Answers.UserDisplayName: Donald Lobo
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-26T07:28:41.257Z
Answers.Text: Ohhhhh, I see what you are saying:  create a new ACL for every new group.  The downside is the the # of ACLs could go up quickly it there are a lot of groups, but good idea!
Answers.UserDisplayName: bdombro
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-22T15:34:00.463Z
Answers.LastActivityDate: 2015-04-25T03:25:59.560Z
Answers.LastEditDate: 2015-04-25T03:25:59.560Z
Answers.UserDisplayName: Donald Lobo
Answers.Body: <p>I a temporary workaround until I have time to fix permissions.  It hooks the create group form and prevents users from creating groups whom don't have permission to "edit all contacts".</p>
  
  <pre><code>function memberperms_civicrm_buildForm( $formName, &amp;$form ) {
      if (strpos($formName, "AddToGroup")
          and
          !CRM_Core_Permission::check('edit all contacts')
      ) {
  
          // Display Error Message
          CRM_Core_Session::setStatus("Sorry, the group feature is not currently supported for members", "Permission Denied", "error");
  
          // Redirect to civicrm home
          drupal_goto("civicrm"); 
      }
  }
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-04-17T17:02:21.113Z
Answers.Text: Hey @bdombro. Any update on this? How did you manage to solve it eventually? Do you know if there is any relevant functionality incorporated in newer CiviCRM versions? Thnx for you time!
Answers.UserDisplayName: Vassilis Chryssos
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-04-23T21:44:47.970Z
Answers.LastActivityDate: 2015-04-23T21:44:47.970Z
Answers.UserDisplayName: bdombro
Answers.Body: <p>This is old, but just in case anyone finds it, I <em>think</em> my <a href="https://lab.civicrm.org/extensions/autogroup" rel="nofollow noreferrer">Auto Group Extension</a> solves this problem.</p>
  <blockquote>
  <h1>CiviCRM AutoGroup extension</h1>
  <p>This extension allows you to choose a set of groups which will be
  added to new contacts if the logged in contact is also in that group.</p>
  <p>e.g. If Staff member Wilma is in the group 'Region: Birmingham' and
  Wilma adds a new contact, it can automatically add the new contact
  into 'Region: Birmingham' group.</p>
  <h2>Why this was created</h2>
  <p>If you are using Access Control Lists (ACLs) to restrict access based
  on groups, e.g. a client of ours has a regional model whereby staff in
  different regions only access contacts for that region, then it's
  annoyingly easy to add a contact and immediately lose access to it
  because you forgot to add them into your regional group.</p>
  </blockquote>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-08-29T16:53:34.743Z
Answers.LastActivityDate: 2023-08-29T16:53:34.743Z
Answers.UserDisplayName: artfulrobot
Body: <p>This may be a shortcoming or bug to-do with access control, but maybe I'm missing something.</p>
  
  <p>I've setup Drupal permissions and ACLs and they are working 100% except for one thing:  users can only view the groups for which they explicitly have an ACL for.  In other words, only users with CMS permission to "View all contacts" can view groups they themselves created.</p>
  
  <p>Am I correct in assuming that this is a shortcoming, or is it a bug?  Either way, what are y'alls suggestions for allowing users be able to create, edit and manage their own groups without giving them "View all contacts"?  Is there a way to do it using hook_civicrm_aclWhereClause?</p>
  
Tags: <permissions><acl>
Title: Allowing group management to users with limited permissions
ThreadText: # Allowing group management to users with limited permissions
  
  (Asked by: username_0 on 2015-04-21)
  
  This may be a shortcoming or bug to-do with access control, but maybe I'm missing something.
  
  I've setup Drupal permissions and ACLs and they are working 100% except for one thing: users can only view the groups for which they explicitly have an ACL for. In other words, only users with CMS permission to "View all contacts" can view groups they themselves created.
  
  Am I correct in assuming that this is a shortcoming, or is it a bug? Either way, what are y'alls suggestions for allowing users be able to create, edit and manage their own groups without giving them "View all contacts"? Is there a way to do it using hook\_civicrm\_aclWhereClause?
  
  **Tags:** permissions, acl
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_1 on 2015-04-22. Score: 2
  
  Yes, this is a shortcoming in the current acl system.
  
  One possible workaround for this might be to implement the post hook on the civicrm\_group object. The post hook can take the contactID of the person creating the group and add an ACL giving this person access to the group.
  
  You can implement the above hook in an extension. Probably worth considering including this in core need on a setting
  
  > **Comments:**
  > **username_0**: Thank Donald.  I looked at the group object and none of the fields appeared to offer any permissions control more than what was on the create group form, so I think this is a dead end.  
  > **username_1**: You will need to use the post hook to create the relevant ACLs for that group. The group object does not have any permissioning fields.  
  > **username_0**: Ohhhhh, I see what you are saying:  create a new ACL for every new group.  The downside is the the # of ACLs could go up quickly it there are a lot of groups, but good idea!  
  
  ---
  
  ### Answer by username_0 on 2015-04-23. Score: 1
  
  I a temporary workaround until I have time to fix permissions.  It hooks the create group form and prevents users from creating groups whom don't have permission to "edit all contacts".
  function memberperms_civicrm_buildForm( $formName, &$form ) {
      if (strpos($formName, "AddToGroup")
          and
          !CRM_Core_Permission::check('edit all contacts')
      ) {
  
          // Display Error Message
          CRM_Core_Session::setStatus("Sorry, the group feature is not currently supported for members", "Permission Denied", "error");
  
          // Redirect to civicrm home
          drupal_goto("civicrm"); 
      }
  }
  
  > **Comments:**
  > **username_2**: Hey @username_0. Any update on this? How did you manage to solve it eventually? Do you know if there is any relevant functionality incorporated in newer CiviCRM versions? Thnx for you time!  
  
  ---
  
  ### Answer by username_3 on 2023-08-29. Score: 0
  
  This is old, but just in case anyone finds it, I *think* my [Auto Group Extension](https://lab.civicrm.org/extensions/autogroup) solves this problem.
  
  > # CiviCRM AutoGroup extension
  >
  > This extension allows you to choose a set of groups which will be
  > added to new contacts if the logged in contact is also in that group.
  >
  > e.g. If Staff member Wilma is in the group 'Region: Birmingham' and
  > Wilma adds a new contact, it can automatically add the new contact
  > into 'Region: Birmingham' group.
  >
  > ## Why this was created
  >
  > If you are using Access Control Lists (ACLs) to restrict access based
  > on groups, e.g. a client of ours has a regional model whereby staff in
  > different regions only access contacts for that region, then it's
  > annoyingly easy to add a contact and immediately lose access to it
  > because you forgot to add them into your regional group.
  
  
  ---
  
  