Answers.Body: <p>This may not be the answer you hope for, but the way we have approached this for other multi-level sites is to keep the 'lower level' users completely out of civicrm and give them everything they need via Views and Webforms.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-08T16:07:36.400Z
Answers.Text: Thanks for the reply, and yeah, definitely not the answer I was hoping for, as this contact type management is the only aspect we really need to limit for our site locations (that we currently know of), and would really be a bit of a pain to add all those other types of pages and options.  And unfortunately I am just volunteer help that doesn't know coding well.... That's really too bad to hear... everything else is lining up really nicely.
Answers.UserDisplayName: user6070
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-01-06T22:13:42.977Z
Answers.LastActivityDate: 2019-01-06T22:13:42.977Z
Answers.UserDisplayName: petednz - fuzion
Answers.Body: <p>We have done this by creating groups in OG, synching them and adding ACL's for each group. This way, they are able to view and edit their own contacts. Furthermore, we created some super-roles which are allowed to view and/or edit all. Doing so we are even able to have one contact which may be a member of two groups.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-08T20:16:37.680Z
Answers.Text: are you manually creating each ACL? we did work to automate this and also to eg build an OG for everyone with Relationship type X with Contact Y, and separately, everyone who signs up for Event Z, ie if Event Z is of type Q then create an OG, then add everyone who registers.
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-29T17:27:12.050Z
Answers.Text: I have created the ACL's via the OG Sync. Then I duplicated them to differentiate in read/update permissions.
  Which extension are you referring to, @petednz?
Answers.UserDisplayName: Webmaster COVS
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-29T21:59:36.923Z
Answers.Text: sorry it didn't get published as an extension, was part of a custom module for a couple of clients. we can probably extract it but may not happen in the near future
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-07T14:11:01.607Z
Answers.LastActivityDate: 2020-06-07T14:11:01.607Z
Answers.UserDisplayName: Webmaster COVS
Body: <p>Have a small franchise type non-profit organization in which multiple level users within the org need access to tools within civi, however, we do not want base level users that are managing their individual school sites to be able to add higher up organizational type contacts (like other school or club locations or regional type centers). We just want them to work on their individual members only, and to limit the availability of specific management/access of contact types based on their specific roles.
  We are using the Relationship extension to manage permissions on their own members down the chain of command, but we need to cutoff the chain of possible contact types they have access to and also hide those possibilities in the nav menu.  Any help is much appreciated!!!  *using civi 5.2.2 and drupal 7</p>
  
Tags: <permissions><contact-types>
Title: How to limit access to manage/create contacts by type via user roles?
ThreadText: # How to limit access to manage/create contacts by type via user roles?
  
  (Asked by: username_0 on 2019-01-03)
  
  Have a small franchise type non-profit organization in which multiple level users within the org need access to tools within civi, however, we do not want base level users that are managing their individual school sites to be able to add higher up organizational type contacts (like other school or club locations or regional type centers). We just want them to work on their individual members only, and to limit the availability of specific management/access of contact types based on their specific roles.
  We are using the Relationship extension to manage permissions on their own members down the chain of command, but we need to cutoff the chain of possible contact types they have access to and also hide those possibilities in the nav menu. Any help is much appreciated!!! \*using civi 5.2.2 and drupal 7
  
  **Tags:** permissions, contact-types
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2019-01-06. Score: 1
  
  This may not be the answer you hope for, but the way we have approached this for other multi-level sites is to keep the 'lower level' users completely out of civicrm and give them everything they need via Views and Webforms.
  
  > **Comments:**
  > **username_0**: Thanks for the reply, and yeah, definitely not the answer I was hoping for, as this contact type management is the only aspect we really need to limit for our site locations (that we currently know of), and would really be a bit of a pain to add all those other types of pages and options.  And unfortunately I am just volunteer help that doesn't know coding well.... That's really too bad to hear... everything else is lining up really nicely.  
  
  ---
  
  ### Answer by username_2 on 2020-06-07. Score: 0
  
  We have done this by creating groups in OG, synching them and adding ACL's for each group. This way, they are able to view and edit their own contacts. Furthermore, we created some super-roles which are allowed to view and/or edit all. Doing so we are even able to have one contact which may be a member of two groups.
  
  > **Comments:**
  > **username_1**: are you manually creating each ACL? we did work to automate this and also to eg build an OG for everyone with Relationship type X with Contact Y, and separately, everyone who signs up for Event Z, ie if Event Z is of type Q then create an OG, then add everyone who registers.  
  > **username_2**: I have created the ACL's via the OG Sync. Then I duplicated them to differentiate in read/update permissions. Which extension are you referring to, @username_1?  
  > **username_1**: sorry it didn't get published as an extension, was part of a custom module for a couple of clients. we can probably extract it but may not happen in the near future  
  
  ---
  
  