Answers.Body: <p>You could apply the same techniques for event pages that are described for contribution pages here: <a href="https://civicrm.stackexchange.com/questions/4637/are-private-contribution-pages-a-thing">Are private contribution pages a thing?</a>.</p>
  
  <p>EDIT: Actually that's only a piece of the puzzle, let me give an example (and make it CMS-agnostic).  Assuming you want to limit access to members of "Newsletter Subscribers"</p>
  
  <pre><code>function hook_civicrm_preProcess($formName, &amp;$form) {
  
    $redirectPath = 'home';  // set this to the url to redirect to if access is denied
  
    if ($formName == "CRM_Event_Form_Registration_Register") {
      $contactId = CRM_Core_Session::singleton()-&gt;getLoggedInContactID();
      $result = civicrm_api3('Contact', 'get', array(
        'group' =&gt; "Newsletter Subscribers",
        'id' =&gt; $contactId,
      ));
      if ($result['count'] === 0) {
        CRM_Utils_System::redirect($redirectPath);
      }
    }
  }
  </code></pre>
  
  <p>Note: This will hide ALL event registrations.  You'll have to find a variable in the <code>$form</code> object to use to determine whether this code should run on a particular page and modify the <code>if</code> condition.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-02T14:38:28.057Z
Answers.Text: Is there a specific technique you are referring to? Checked this thread before but haven't seen a solution/technique to solve this problem.
Answers.UserDisplayName: florian norbert bepunkt
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-02T16:11:12.997Z
Answers.Text: @floriannorbertbepunkt I updated my answer.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-02T16:19:46.130Z
Answers.Text: okay, I get what you mean. thank you for posting the example… my question was about a different approach: tieing an ACL to a custom field of an event (or more general extending an acls functionality to include conditional checks). with your approach you would not use ACLs at all but implement a query to conditionally show the data.
Answers.UserDisplayName: florian norbert bepunkt
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-02T17:06:02.827Z
Answers.Text: Yes, that's correct.  I understand what you're asking for - and even have the same need myself!  This is higher-performance than ACLs, but I agree that what you're asking for is more user-friendly.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-02-01T16:33:54.820Z
Answers.LastActivityDate: 2018-02-03T00:16:49.710Z
Answers.LastEditDate: 2018-02-03T00:16:49.710Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>I have a use case where there are public and non public events. Public events should be seen by everyone and can be registered for. Non public events should only be seen and registerable for a certain group (members.</p>
  
  <p>With ACLs I deactivated the CMS permissions and added the rights to view / edit an event. I got as far as to create a seperate ACL for each event which grants the appropriate right in order to make an event public / non-public. This process however is very tedious since it required the creation of a seperate ACL for each event. Is there a way to make this more "global" so that events of a certain category (custom field) are public while others are non public?</p>
  
Tags: <civievent><permissions><acl><registration>
Title: Using ACL for event registration
ThreadText: # Using ACL for event registration
  
  (Asked by: username_0 on 2018-02-01)
  
  I have a use case where there are public and non public events. Public events should be seen by everyone and can be registered for. Non public events should only be seen and registerable for a certain group (members.
  
  With ACLs I deactivated the CMS permissions and added the rights to view / edit an event. I got as far as to create a seperate ACL for each event which grants the appropriate right in order to make an event public / non-public. This process however is very tedious since it required the creation of a seperate ACL for each event. Is there a way to make this more "global" so that events of a certain category (custom field) are public while others are non public?
  
  **Tags:** civievent, permissions, acl, registration
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-02-01. Score: 1 | Accepted answer
  
  You could apply the same techniques for event pages that are described for contribution pages here: Are private contribution pages a thing?.
  EDIT: Actually that's only a piece of the puzzle, let me give an example (and make it CMS-agnostic).  Assuming you want to limit access to members of "Newsletter Subscribers"
  function hook_civicrm_preProcess($formName, &$form) {
  
    $redirectPath = 'home';  // set this to the url to redirect to if access is denied
  
    if ($formName == "CRM_Event_Form_Registration_Register") {
      $contactId = CRM_Core_Session::singleton()->getLoggedInContactID();
      $result = civicrm_api3('Contact', 'get', array(
        'group' => "Newsletter Subscribers",
        'id' => $contactId,
      ));
      if ($result['count'] === 0) {
        CRM_Utils_System::redirect($redirectPath);
      }
    }
  }
  
  Note: This will hide ALL event registrations.  You'll have to find a variable in the $form object to use to determine whether this code should run on a particular page and modify the if condition.
  
  > **Comments:**
  > **username_0**: Is there a specific technique you are referring to? Checked this thread before but haven't seen a solution/technique to solve this problem.  
  > **username_1**: @floriannorbertbepunkt I updated my answer.  
  > **username_0**: okay, I get what you mean. thank you for posting the example… my question was about a different approach: tieing an ACL to a custom field of an event (or more general extending an acls functionality to include conditional checks). with your approach you would not use ACLs at all but implement a query to conditionally show the data.  
  > **username_1**: Yes, that's correct.  I understand what you're asking for - and even have the same need myself!  This is higher-performance than ACLs, but I agree that what you're asking for is more user-friendly.  
  
  ---
  
  