Answers.Body: <p>Levels of access is tricky. Generally it is best to think of it in a id, ego, superego type of access. I would recommend at least 3 from most restrictive to least. See/edit own data, See other's data, See/Edit other's data.</p>
  
  <p>If, for example you were to create a fieldset called 'super_secret_stuff' I would recommend the following approach. By default remove the privilege  'CiviCRM: access custom data' from all non-admin users. Then, only give the requisite groups access to 'super_secret_stuff' using the ACL Dashboard(q=civicrm/admin/access) within CiviCRM. This is where it gets tricky. </p>
  
  <p>Generally speaking, if users have access to a specific set of custom data, and can see (and edit of course) other user's profiles then they will be able to see the 'super secret stuff' for those users. To restrict this, you can uncheck the privilege 'CiviCRM: view all contacts' and 'CiviCRM: edit all contacts' in the ACL Dashboard.</p>
  
  <p>Of course, disallowing all users from seeing each other's basic information can be onerous if that is supposed to be an aspect of your system. In order to do this you need to start going behind the scenes. Probably the easiest way to do this is to use the <strong>hook_civicrm_aclGroup</strong>. Using this hook you can specifically grant access to tables that you want your users to be able to see across the database (i.e. basic contact info but not 'super_secret_stuff'). Look at the examples there.</p>
  
  <p>Another hook you could use is the <strong>hook_civicrm_buildForm</strong>
  where you check to see if the form being looked at is 'super_secret_stuff' and if so if the userID of the profile == current user id.</p>
  
  <p>In the buildform example use</p>
  
  <pre><code>function dbhooks_civicrm_buildForm($formName, &amp;$form) {
      if ($formName == 'your custom form_name' ) {
          if ($session-&gt;get('userID') !== $form-&gt;_contactId){
              CRM_Core_Error::fatal(ts('You do not have permission to access this page, user:' . $session-&gt;get('userID')));
          }
  }
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-29T15:16:03.297Z
Answers.LastActivityDate: 2016-04-29T15:16:03.297Z
Answers.UserDisplayName: Vito Mantese
Body: <p>I am planning to set up a database of 12000 members. The database will include considerable amount of personal and confidential data. 
  How many levels of access can I set up - each level graded to allow access up to specified level of information?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-29T17:02:43.650Z
Comments.Text: You are likely to get more helpful answers to this question if you can provide a bit more detail about what you are trying to do.
Comments.UserDisplayName: William Mortada
Tags: <civimember><security>
Title: How many levels of security can I set for a data base of 12000 people with their confidential data?
ThreadText: # How many levels of security can I set for a data base of 12000 people with their confidential data?
  
  (Asked by: username_0 on 2016-04-29)
  
  I am planning to set up a database of 12000 members. The database will include considerable amount of personal and confidential data.
  How many levels of access can I set up - each level graded to allow access up to specified level of information?
  
  **Tags:** civimember, security
  
  > **Comments:**
  > **username_1**: You are likely to get more helpful answers to this question if you can provide a bit more detail about what you are trying to do.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2016-04-29. Score: 1
  
  Levels of access is tricky. Generally it is best to think of it in a id, ego, superego type of access. I would recommend at least 3 from most restrictive to least. See/edit own data, See other's data, See/Edit other's data.
  
  If, for example you were to create a fieldset called 'super\_secret\_stuff' I would recommend the following approach. By default remove the privilege 'CiviCRM: access custom data' from all non-admin users. Then, only give the requisite groups access to 'super\_secret\_stuff' using the ACL Dashboard(q=civicrm/admin/access) within CiviCRM. This is where it gets tricky.
  
  Generally speaking, if users have access to a specific set of custom data, and can see (and edit of course) other user's profiles then they will be able to see the 'super secret stuff' for those users. To restrict this, you can uncheck the privilege 'CiviCRM: view all contacts' and 'CiviCRM: edit all contacts' in the ACL Dashboard.
  
  Of course, disallowing all users from seeing each other's basic information can be onerous if that is supposed to be an aspect of your system. In order to do this you need to start going behind the scenes. Probably the easiest way to do this is to use the **hook\_civicrm\_aclGroup**. Using this hook you can specifically grant access to tables that you want your users to be able to see across the database (i.e. basic contact info but not 'super\_secret\_stuff'). Look at the examples there.
  
  Another hook you could use is the **hook\_civicrm\_buildForm**
  where you check to see if the form being looked at is 'super\_secret\_stuff' and if so if the userID of the profile == current user id.
  
  In the buildform example use
  
  ```
  function dbhooks_civicrm_buildForm($formName, &$form) {
      if ($formName == 'your custom form_name' ) {
          if ($session->get('userID') !== $form->_contactId){
              CRM_Core_Error::fatal(ts('You do not have permission to access this page, user:' . $session->get('userID')));
          }
  }
  
  ```
  
  
  ---
  
  