Answers.Body: <p>Ah, ok.  So I had to enable the " CiviCRM: view my contact" and "CiviCRM: edit my contact" fields under Drupal People -> Permissions.  Then if they are in the smart group I'm giving access to, they can see themselves.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-09T21:43:27.380Z
Answers.Text: Good sleuthing but do i take it they will see themselves whether they are in the Group or not now?
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-11T00:25:22.413Z
Answers.Text: I suppose they will.  Which works fine for what we are doing - the idea is each member will be able to edit their own info, but chapter leaders will be able to edit the info for members of their chapter.  I could imagine that some people using civicrm would want to limit some users from editing their info unless they were part of xyz group and given an ACL, but not me.
Answers.UserDisplayName: Matt Muchowski
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-09T20:37:00.413Z
Answers.LastActivityDate: 2016-03-09T20:37:00.413Z
Answers.UserDisplayName: Matt Muchowski
Answers.Body: <p>In case you need to find an alternative recipe, this one is based on Relationships so does not involve making ACL Groups. </p>
  
  <p>Download the <a href="https://civicrm.org/extensions/relationship-permissions-acls" rel="nofollow">Permissioned Relationships extension</a> (and read instructions about its dependency on <a href="https://civicrm.org/extensions/civicrm-entity-settings" rel="nofollow">CiviCRM Entity Settings</a>).</p>
  
  <p>When the above extensions are enabled, on any Relationship Type you should now see a new field saying Always Permission A to B (and vv). And at civicrm/admin/setting/misc?reset=1 you should see an option for 'Allow second-degree relationship permissions' (ie so A can see B, and if B can see C, D and E, then A can see C, D and E).</p>
  
  <p>Make a Relationship Type xxx and set it to be 'always permissioned.</p>
  
  <p>Make a CMS role that does not have "view/edit ALL contacts"</p>
  
  <p>Give Joh that role, and set him as a 'xxx of' for MYORG, and set MYCO as a permissioned relationship of 'yyy' for Mary and Bob and Jane.</p>
  
  <p>Then John will be able to only see Mary and Bob and Jane, and not other contacts who do not have that relationship to MYCO</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-11T21:16:34.670Z
Answers.Text: That extension looks cool, but it's pretty outdated.  It wants to run on civicrm "4.4.6+ (but not 4.5 at this stage )" but we're already running 4.6.10
Answers.UserDisplayName: Matt Muchowski
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-14T19:55:05.210Z
Answers.Text: we have it running on 4.6. x without any issues
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-17T02:19:14.127Z
Answers.Text: Ok, so I used the 'include / exclude' search.  Included the smart-group for the chapter, excluded the 'acl' group for the chapter secretary.  Then I saved this as a new smart-group.  In the ACL settings, made the acl role for the chapter, added the group for the chapter secretary to the role, then gave that role control over the new 'include / exclude' smart group that we created.  Gonna tinker a little more with specific acl settings, but I think this will work for us.   We have a lot of chapters, so there will be a lot of acl's, but oh well.
Answers.UserDisplayName: Matt Muchowski
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-17T04:26:56.813Z
Answers.Text: Good luck. The relationship approach i flagged above takes care of that all automatically in case you end up thinking the ACL approach is to burdensome
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T15:41:14.447Z
Answers.Text: @petednz-fuzion, have you tested this on 4.7 yet?  Could potentially solve http://civicrm.stackexchange.com/questions/9755/restricting-access-to-a-group-of-contacts/9761#9761
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-19T18:13:23.543Z
Answers.Text: Can't say we have tested yet, but eileen tends to build with the future in mind ;-). that said, i don't see the relevance to your case as you would have to be setting up relationships to manage access based on donations so doesn't seem so applicable
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-31T01:46:01.297Z
Answers.Text: @petednz-fuzion Yea, one of the things about the relationship extension you pointed out is that it gives 'edit' access.  If we only wanted to give people 'view' access, we'd have to use acl's - unless someone made some updates to that relationship extension.
Answers.UserDisplayName: Matt Muchowski
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-31T02:20:35.780Z
Answers.Text: which sort of a 'someone' ? ;-)
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-07T20:52:10.177Z
Answers.LastActivityDate: 2016-02-07T20:52:10.177Z
Answers.UserDisplayName: petednz - fuzion
Body: <p>I've been trying to set up ACL's for a number of different chapters in a national organization's civicrm.  The idea is that the secretary for each chapter would be able to access members in that chapter and update their information.</p>
  
  <p>So I
  1.) Keep track of who is a member in the chapter through relationships between the members and the organization contact record for the chapter. 
  2.)Created a smart-group that generates a list of members who have an active relationship with the organization's contact.
  3.) Created an ACL group and added the chapter's secretary
  4.) Created an ACL Role for the Chapter
  5.) Assigned the ACL group for the chapter to it's ACL role.
  6.) Created several rules (view the group (which in this case is the smart-group based on the relationships), edit the group, edit custom fields)</p>
  
  <p>However whenever I login as the secretary for that chapter, I am unable to view the members of the chapter, or my own civicrm contact page.</p>
  
  <p>When I do the same with a 'test' login, it works.  </p>
  
  <p>I suspect that there is something weird happening because the contact for the chapter's secretary is in the smart-group that I am assigning them to have these ACL rules over.</p>
  
  <p>Has anyone else had this problem?  Am I just doing it wrong, or is this some kind of bug?</p>
  
  <p>Thanks, 
  Matt.</p>
  
Tags: <smartgroups><acl>
Title: Can a person inside a group be granted ACL Access to the group?
ThreadText: # Can a person inside a group be granted ACL Access to the group?
  
  (Asked by: username_0 on 2016-02-06)
  
  I've been trying to set up ACL's for a number of different chapters in a national organization's civicrm. The idea is that the secretary for each chapter would be able to access members in that chapter and update their information.
  
  So I
  1.) Keep track of who is a member in the chapter through relationships between the members and the organization contact record for the chapter.
  2.)Created a smart-group that generates a list of members who have an active relationship with the organization's contact.
  3.) Created an ACL group and added the chapter's secretary
  4.) Created an ACL Role for the Chapter
  5.) Assigned the ACL group for the chapter to it's ACL role.
  6.) Created several rules (view the group (which in this case is the smart-group based on the relationships), edit the group, edit custom fields)
  
  However whenever I login as the secretary for that chapter, I am unable to view the members of the chapter, or my own civicrm contact page.
  
  When I do the same with a 'test' login, it works.
  
  I suspect that there is something weird happening because the contact for the chapter's secretary is in the smart-group that I am assigning them to have these ACL rules over.
  
  Has anyone else had this problem? Am I just doing it wrong, or is this some kind of bug?
  
  Thanks,
  Matt.
  
  **Tags:** smartgroups, acl
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2016-03-09. Score: 1 | Accepted answer
  
  Ah, ok. So I had to enable the " CiviCRM: view my contact" and "CiviCRM: edit my contact" fields under Drupal People -> Permissions. Then if they are in the smart group I'm giving access to, they can see themselves.
  
  > **Comments:**
  > **username_1**: Good sleuthing but do i take it they will see themselves whether they are in the Group or not now?  
  > **username_0**: I suppose they will.  Which works fine for what we are doing - the idea is each member will be able to edit their own info, but chapter leaders will be able to edit the info for members of their chapter.  I could imagine that some people using civicrm would want to limit some users from editing their info unless they were part of xyz group and given an ACL, but not me.  
  
  ---
  
  ### Answer by username_1 on 2016-02-07. Score: 0
  
  In case you need to find an alternative recipe, this one is based on Relationships so does not involve making ACL Groups.
  
  Download the [Permissioned Relationships extension](https://civicrm.org/extensions/relationship-permissions-acls) (and read instructions about its dependency on [CiviCRM Entity Settings](https://civicrm.org/extensions/civicrm-entity-settings)).
  
  When the above extensions are enabled, on any Relationship Type you should now see a new field saying Always Permission A to B (and vv). And at civicrm/admin/setting/misc?reset=1 you should see an option for 'Allow second-degree relationship permissions' (ie so A can see B, and if B can see C, D and E, then A can see C, D and E).
  
  Make a Relationship Type xxx and set it to be 'always permissioned.
  
  Make a CMS role that does not have "view/edit ALL contacts"
  
  Give Joh that role, and set him as a 'xxx of' for MYORG, and set MYCO as a permissioned relationship of 'yyy' for Mary and Bob and Jane.
  
  Then John will be able to only see Mary and Bob and Jane, and not other contacts who do not have that relationship to MYCO
  
  > **Comments:**
  > **username_0**: That extension looks cool, but it's pretty outdated.  It wants to run on civicrm "4.4.6+ (but not 4.5 at this stage )" but we're already running 4.6.10  
  > **username_1**: we have it running on 4.6. x without any issues  
  > **username_0**: Ok, so I used the 'include / exclude' search.  Included the smart-group for the chapter, excluded the 'acl' group for the chapter secretary.  Then I saved this as a new smart-group.  In the ACL settings, made the acl role for the chapter, added the group for the chapter secretary to the role, then gave that role control over the new 'include / exclude' smart group that we created.  Gonna tinker a little more with specific acl settings, but I think this will work for us.   We have a lot of chapters, so there will be a lot of acl's, but oh well.  
  > **username_1**: Good luck. The relationship approach i flagged above takes care of that all automatically in case you end up thinking the ACL approach is to burdensome  
  > **username_2**: @petednz-fuzion, have you tested this on 4.7 yet?  Could potentially solve http://civicrm.stackexchange.com/questions/9755/restricting-access-to-a-group-of-contacts/9761#9761  
  > **username_1**: Can't say we have tested yet, but eileen tends to build with the future in mind ;-). that said, i don't see the relevance to your case as you would have to be setting up relationships to manage access based on donations so doesn't seem so applicable  
  > **username_0**: @petednz-fuzion Yea, one of the things about the relationship extension you pointed out is that it gives 'edit' access.  If we only wanted to give people 'view' access, we'd have to use acl's - unless someone made some updates to that relationship extension.  
  > **username_1**: which sort of a 'someone' ? ;-)  
  
  ---
  
  