Answers.Body: <p>IMHO it seems like you really need a consultant for this stuff.  Hopefully an organization of your size (400 chapters with an unknown # of people per chatper) has budget for help.</p>
  
  <p>But let me offer a few bits of advice: </p>
  
  <ol>
  <li><p>the "corresponded Organisation Group" as you put it CAN be a smart group, thus people (not admins) can self-select their own groups when they signup and/or register if you use a custom data field for "select your chapter".</p>
  
  <ol start="2">
  <li><p>CiviMember Roles Sync doesn't work as you describe, that's Civi Group Role Sync for that functionality</p></li>
  <li><p>I'm not sure why you feel people need to use CiviGroup Role Sync</p></li>
  <li><p>Don't understand your point 2.3</p></li>
  </ol></li>
  </ol>
  
  <p>So I hope that helps, I've done this on a smaller scale for a group with 12 national chapters and 20-30 people per chapter, it works pretty well.  Please remember I do think a consultant with experience on ACL is needed.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-17T18:48:31.033Z
Answers.Text: What you're trying to do is not easy without custom coding. Setting up and maintaining so many groups is likely to cause problems even if you manage to make it work. As CiviTeacher suggested you are better off working with someone who has done this sort of implementation before. Working with a CiviCRM [Partner and Contributor](https://civicrm.org/providers) makes CivCRM better for everyone.
Answers.UserDisplayName: Sanjay Jain
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-18T14:14:16.957Z
Answers.Text: Thank you for an input, it's valuable to talk to someone who has relevant experience, believe stackexchange is all about experience exchange, not sure if "paid development" advised as preferred option would be our #1 and only option indeed. So, let me ask if you have made a similar setup you've mentioned manually, following all steps for each of 12 chapters? Thanks!
Answers.UserDisplayName: yurg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-19T06:32:18.740Z
Answers.Text: To be clear I'm not advertising my services, and I'm not available as a consultant.  My Stack Exchange to you advice is both technical and instructional in "how the Civi community works" - I'm trying to help you get what you want.  I did a similar setup as I describe for an organization and it worked well.   For your situation, I think that someone who is a consultant could help you achieve your goals more rapidly and efficiently than Stack Enchange can (as wonderful as Stack Exchange is) it's more for simple "how to" solutions not detailed project planning.
Answers.UserDisplayName: CiviTeacher
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-17T15:27:06.007Z
Answers.LastActivityDate: 2015-07-17T15:27:06.007Z
Answers.UserDisplayName: CiviTeacher
Answers.Body: <p>Well, it has turned that unfortunately it's a feature one would have to pay for.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-06T21:53:00.507Z
Answers.Text: Can you please clarify what solution you ended up using as it might benefit others reading this ticket
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-08T03:50:07.717Z
Answers.Text: Yeah, on its own this isn't a very helpful answer, but if you edit and elaborate, it would be very useful to share your experience @user1924232
Answers.UserDisplayName: Andie Hunt
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-17T10:50:59.090Z
Answers.Text: @petednz My honest thoughts about it might start a flame which would be a way out from a question itself and more about your sponsorship/funding seek methods. So let it be as is, mean this feature demands a paid development.
Answers.UserDisplayName: yurg
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-06T20:20:44.660Z
Answers.LastActivityDate: 2015-08-11T20:40:21.990Z
Answers.LastEditDate: 2015-08-11T20:40:21.990Z
Answers.UserDisplayName: yurg
Body: <p>We have an Organisation with cca. 400 local branches and have trying to achieve a following ACL behaviour: </p>
  
  <p>-- Organisation members needs to be able to login and have access to their Organisation members records only. </p>
  
  <p>-- Organisation admins may administer all members in their Organisations and Organisation itself (and in theory could be administering more than one Organisation thus more members). </p>
  
  <p>-- Organisation admins need some kind of dashboard which gives them access to their own societies.</p>
  
  <p>-- Main civiCRM admin(s) need to be able to assign ACLs to a user</p>
  
  <p>We have Relationships in place, so each Organisation has it's members listed in Relationships tab in civiCRM. Now, this is a workaround which seems has to be done: </p>
  
  <p><strong>1. civiCRM side</strong></p>
  
  <p>1.1. Create Group (AccessControl) for each Organisation</p>
  
  <p>1.2. Create Group (AccessControl) for each Organisation Admin Users (NB! SmartGroups wi not work since there is no AcessControl for them, there is a thread from 2007 regarding this: <a href="http://forum.civicrm.org/index.php?topic=1645.0" rel="nofollow noreferrer">http://forum.civicrm.org/index.php?topic=1645.0</a>)</p>
  
  <p>1.3. Create ACL Role for each Organisation Admin</p>
  
  <p>1.4. Assign each ACL Role to corresponded Organisation Admin Group</p>
  
  <p>1.5. Create ACL for each Organisation where Role = Soiety Admin Role and operation = Edit and Type of Data = Group of Contacts and Group = corresponded Organisation Group  </p>
  
  <p><strong>2.Drupal side</strong></p>
  
  <p>2.1. Create Role for each Organisation Admin</p>
  
  <p>2.2 Grant access: </p>
  
  <ul>
  <li><p>Admin Menu</p></li>
  <li><p>CiviCRM: profile listings and forms </p></li>
  <li><p>CiviCRM: profile listings </p></li>
  <li><p>CiviCRM: access CiviCRM </p></li>
  <li><p>CiviCRM: access Contact Dashboard </p></li>
  </ul>
  
  <p>2.3. Create/move DrupalUsers based on Civi Contacts we'd want to be admins and assign each of them to own Role   </p>
  
  <p>2.4 Use "CiviMember Roles Sync" <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/CiviMember+Roles+Sync" rel="nofollow noreferrer">http://wiki.civicrm.org/confluence/display/CRMDOC/CiviMember+Roles+Sync</a> to sync Drupal Roles with Civi Groups </p>
  
  <hr>
  
  <p>We've studied some related threads:</p>
  
  <ol>
  <li><p>"Multi-level Organization ACL Permissions"
  <a href="https://civicrm.stackexchange.com/questions/573/multi-level-organization-acl-permissions">Multi-level Organization ACL Permissions</a>
  ( where multi-site workaround suggested sounds even more overhelming than current approach,since we have 380+ organisations and all Contacts data currently stored in single CiviCRM database ). Have tried also "local permissions extension we built for the National Democratic Institute" hoping that it would be possible to convert geografic-centered approach to Organisations-centered; may be it's a way to go, although it needs deep code diving. </p></li>
  <li><p>"Allowing group management to users with limited permissions" 
  <a href="https://civicrm.stackexchange.com/questions/717/allowing-group-management-to-users-with-limited-permissions/732#732">Allowing group management to users with limited permissions</a> from where we've found out that " users can only view the groups for which they explicitly have an ACL for. " which doubles all work, since now we need a pair (Admins and Members) of Role,ACL,Group for each Organisation.</p></li>
  <li><p>Yet another option found has been a "Related Permissions Module" extention from nz.co.fuzion ( <a href="http://github.com/eileenmcnaughton/nz.co.relatedpermissions/zipball/master" rel="nofollow noreferrer">http://github.com/eileenmcnaughton/nz.co.relatedpermissions/zipball/master</a> )  suggested among related threads at stackexchange or forum.civicrm.org, however it doesn't seems to be compatible with most recent version of civicrm. This one sounds like a best "theoretical" approach so far since it tends to use component (Relations) which have been already installed and configured. However it's hard to find out from here if it worth investment of development hours to make it work since it's hard to say if it was working the way we need. </p></li>
  </ol>
  
  <p>Afraid, not all related links from all sources are listed here (like related pages from book.civicrm.org or wiki.civicrm.org), we've studied a lot.   </p>
  
  <p>So, any fresh advice will be highly appreciated; can't believe CRM might have such,well, let's call it "complex"  permissioning system.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-17T23:21:40.030Z
Comments.Text: To clarify what 'not working' means in terms of the relatedpermissions extension. The extension will 'work' in terms of the ACL part - ie I have a permissioned relationship of branch Y & branch y has a permissioned relationship over 85 people then I have permission over those 85 people and the branch.
  
  The part that doesn't work (athough anecdotally it may) is that the extension injects extra fields into the relationship type form, allowing you to specify that a particular relationship type will always be permissioned. The breakages is specifically around the the UI on this form
Comments.UserDisplayName: eileen
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-17T23:24:50.390Z
Comments.Text: Also note, if you DO use relatedpermissions extension you ALSO need the entitysettings extension & you should obtain both from github rather than the extensions directory to be sure you have the latest
Comments.UserDisplayName: eileen
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-18T01:44:51.420Z
Comments.Text: If you need any help with using relatedpermissions or entitysettings extensions please get in touch with either Eileen or myself.
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-18T14:43:29.737Z
Comments.Text: Hi Eileen and petednz, haven't expected you'd participate in discussion! Thanks for a chance to talk to you!  Your extension sounds like the best available alternate of default ACL workaround for our needs. I've tried to follow extensions docs carefully. Mean, have got both entitysetting and relatedpermissions 1.2  from github, but after enabling extensions have got this ( http://awesomescreenshot.com/0e652su886 ); also, not really sure what exactly "Always Permission A to B" and "Always Permission B to A" should work. Frankly, not even sure how all this thing should be configured.
Comments.UserDisplayName: yurg
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-18T14:59:07.907Z
Comments.Text: @petednz Yes, please, I do need help with an extensions; will you please tell which way of getting in touch would be more convenient? We could continue here so thread could be found useful to someone, not sure, however, if our case is quite unique, since there is not much about similar issues at civicrm forum/wiki and here, at stackexchange. Thanks a mil!
Comments.UserDisplayName: yurg
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-18T21:58:22.067Z
Comments.Text: https://forum.civicrm.org/index.php?action=profile;u=312
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-22T10:39:53.423Z
Comments.Text: Have sent a PM via civicrm forum, look forward to your response, thanks!
Comments.UserDisplayName: yurg
Tags: <groups><permissions><acl><roles>
Title: How to design ACL for a multi-level organisation
ThreadText: # How to design ACL for a multi-level organisation
  
  (Asked by: username_0 on 2015-07-17)
  
  We have an Organisation with cca. 400 local branches and have trying to achieve a following ACL behaviour:
  
  -- Organisation members needs to be able to login and have access to their Organisation members records only.
  
  -- Organisation admins may administer all members in their Organisations and Organisation itself (and in theory could be administering more than one Organisation thus more members).
  
  -- Organisation admins need some kind of dashboard which gives them access to their own societies.
  
  -- Main civiCRM admin(s) need to be able to assign ACLs to a user
  
  We have Relationships in place, so each Organisation has it's members listed in Relationships tab in civiCRM. Now, this is a workaround which seems has to be done:
  
  **1. civiCRM side**
  
  1.1. Create Group (AccessControl) for each Organisation
  
  1.2. Create Group (AccessControl) for each Organisation Admin Users (NB! SmartGroups wi not work since there is no AcessControl for them, there is a thread from 2007 regarding this: <http://forum.civicrm.org/index.php?topic=1645.0>)
  
  1.3. Create ACL Role for each Organisation Admin
  
  1.4. Assign each ACL Role to corresponded Organisation Admin Group
  
  1.5. Create ACL for each Organisation where Role = Soiety Admin Role and operation = Edit and Type of Data = Group of Contacts and Group = corresponded Organisation Group
  
  **2.Drupal side**
  
  2.1. Create Role for each Organisation Admin
  
  2.2 Grant access:
  
  * Admin Menu
  * CiviCRM: profile listings and forms
  * CiviCRM: profile listings
  * CiviCRM: access CiviCRM
  * CiviCRM: access Contact Dashboard
  
  2.3. Create/move DrupalUsers based on Civi Contacts we'd want to be admins and assign each of them to own Role
  
  2.4 Use "CiviMember Roles Sync" <http://wiki.civicrm.org/confluence/display/CRMDOC/CiviMember+Roles+Sync> to sync Drupal Roles with Civi Groups
  
  ---
  
  We've studied some related threads:
  
  1. "Multi-level Organization ACL Permissions"
     [Multi-level Organization ACL Permissions](https://civicrm.stackexchange.com/questions/573/multi-level-organization-acl-permissions)
     ( where multi-site workaround suggested sounds even more overhelming than current approach,since we have 380+ organisations and all Contacts data currently stored in single CiviCRM database ). Have tried also "local permissions extension we built for the National Democratic Institute" hoping that it would be possible to convert geografic-centered approach to Organisations-centered; may be it's a way to go, although it needs deep code diving.
  2. "Allowing group management to users with limited permissions"
     [Allowing group management to users with limited permissions](https://civicrm.stackexchange.com/questions/717/allowing-group-management-to-users-with-limited-permissions/732#732) from where we've found out that " users can only view the groups for which they explicitly have an ACL for. " which doubles all work, since now we need a pair (Admins and Members) of Role,ACL,Group for each Organisation.
  3. Yet another option found has been a "Related Permissions Module" extention from nz.co.fuzion ( <http://github.com/username_1mcnaughton/nz.co.relatedpermissions/zipball/master> ) suggested among related threads at stackexchange or forum.civicrm.org, however it doesn't seems to be compatible with most recent version of civicrm. This one sounds like a best "theoretical" approach so far since it tends to use component (Relations) which have been already installed and configured. However it's hard to find out from here if it worth investment of development hours to make it work since it's hard to say if it was working the way we need.
  
  Afraid, not all related links from all sources are listed here (like related pages from book.civicrm.org or wiki.civicrm.org), we've studied a lot.
  
  So, any fresh advice will be highly appreciated; can't believe CRM might have such,well, let's call it "complex" permissioning system.
  
  **Tags:** groups, permissions, acl, roles
  
  > **Comments:**
  > **username_1**: To clarify what 'not working' means in terms of the relatedpermissions extension. The extension will 'work' in terms of the ACL part - ie I have a permissioned relationship of branch Y & branch y has a permissioned relationship over 85 people then I have permission over those 85 people and the branch.  The part that doesn't work (athough anecdotally it may) is that the extension injects extra fields into the relationship type form, allowing you to specify that a particular relationship type will always be permissioned. The breakages is specifically around the the UI on this form  
  > **username_1**: Also note, if you DO use relatedpermissions extension you ALSO need the entitysettings extension & you should obtain both from github rather than the extensions directory to be sure you have the latest  
  > **username_2**: If you need any help with using relatedpermissions or entitysettings extensions please get in touch with either Eileen or myself.  
  > **username_0**: Hi Eileen and petednz, haven't expected you'd participate in discussion! Thanks for a chance to talk to you!  Your extension sounds like the best available alternate of default ACL workaround for our needs. I've tried to follow extensions docs carefully. Mean, have got both entitysetting and relatedpermissions 1.2  from github, but after enabling extensions have got this ( http://awesomescreenshot.com/0e652su886 ); also, not really sure what exactly "Always Permission A to B" and "Always Permission B to A" should work. Frankly, not even sure how all this thing should be configured.  
  > **username_0**: @petednz Yes, please, I do need help with an extensions; will you please tell which way of getting in touch would be more convenient? We could continue here so thread could be found useful to someone, not sure, however, if our case is quite unique, since there is not much about similar issues at civicrm forum/wiki and here, at stackexchange. Thanks a mil!  
  > **username_2**: https://forum.civicrm.org/index.php?action=profile;u=312  
  > **username_0**: Have sent a PM via civicrm forum, look forward to your response, thanks!  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2015-08-06. Score: 0 | Accepted answer
  
  Well, it has turned that unfortunately it's a feature one would have to pay for.
  
  > **Comments:**
  > **username_2**: Can you please clarify what solution you ended up using as it might benefit others reading this ticket  
  > **username_5**: Yeah, on its own this isn't a very helpful answer, but if you edit and elaborate, it would be very useful to share your experience @user1924232  
  > **username_0**: @petednz My honest thoughts about it might start a flame which would be a way out from a question itself and more about your sponsorship/funding seek methods. So let it be as is, mean this feature demands a paid development.  
  
  ---
  
  ### Answer by username_3 on 2015-07-17. Score: 4
  
  IMHO it seems like you really need a consultant for this stuff. Hopefully an organization of your size (400 chapters with an unknown # of people per chatper) has budget for help.
  
  But let me offer a few bits of advice:
  
  1. the "corresponded Organisation Group" as you put it CAN be a smart group, thus people (not admins) can self-select their own groups when they signup and/or register if you use a custom data field for "select your chapter".
  
     2. CiviMember Roles Sync doesn't work as you describe, that's Civi Group Role Sync for that functionality
     3. I'm not sure why you feel people need to use CiviGroup Role Sync
     4. Don't understand your point 2.3
  
  So I hope that helps, I've done this on a smaller scale for a group with 12 national chapters and 20-30 people per chapter, it works pretty well. Please remember I do think a consultant with experience on ACL is needed.
  
  > **Comments:**
  > **username_4**: What you're trying to do is not easy without custom coding. Setting up and maintaining so many groups is likely to cause problems even if you manage to make it work. As username_3 suggested you are better off working with someone who has done this sort of implementation before. Working with a CiviCRM [Partner and Contributor](https://civicrm.org/providers) makes CivCRM better for everyone.  
  > **username_0**: Thank you for an input, it's valuable to talk to someone who has relevant experience, believe stackexchange is all about experience exchange, not sure if "paid development" advised as preferred option would be our #1 and only option indeed. So, let me ask if you have made a similar setup you've mentioned manually, following all steps for each of 12 chapters? Thanks!  
  > **username_3**: To be clear I'm not advertising my services, and I'm not available as a consultant.  My Stack Exchange to you advice is both technical and instructional in "how the Civi community works" - I'm trying to help you get what you want.  I did a similar setup as I describe for an organization and it worked well.   For your situation, I think that someone who is a consultant could help you achieve your goals more rapidly and efficiently than Stack Enchange can (as wonderful as Stack Exchange is) it's more for simple "how to" solutions not detailed project planning.  
  
  ---
  
  