Answers.Body: <p>The title of your question only makes a distinction for "anonymous" users; the question itself mentions "Member-only" vs "public". </p>
  
  <p>If by "Member" you mean "current membership holders as defined in CiviMember", then the <a href="https://civicrm.org/extensions/member-only-event" rel="nofollow noreferrer">Member Only Event</a> extension is probably a good choice.</p>
  
  <p>If on the other hand you only mean "members of my site" a.k.a. "logged in users", then what you're describing is possible with ACLs. The following will default to "authenticated users only" for all events, with exceptions defined on a per-event basis using ACLs.</p>
  
  <ol>
  <li><p>Configure Drupal (or other CMS) permissions to deny the "CiviEvent: register for events" permission for the Anonymous role, and grant this permission to the Authenticated role.</p></li>
  <li><p>In CiviCRM, create an ACL that grants "Edit" permission to a single event for the "Everyone" role, as in this example:
  <a href="https://i.sstatic.net/8koGB.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/8koGB.png" alt="enter image description here"></a></p></li>
  <li><p>Naturally you'll want to test that event and a normal "authenticated user only" event, both as an authenticated user and as an anonymous user, for your own peace of mind that it's configured correctly.</p></li>
  </ol>
  
  <p>An important caveat here is that with ACLs you are introducing a separate mechanism for managing user permissions, which runs parallel with -- and sometimes overlaps with -- Drupal permissions. That's not a bad thing; it just means it's important to a) have a clear understanding of what you're enabling, b) test to ensure you've configured it correctly, and c) remember to check ACLs as well as Drupal permissions, if you ever find an issue later on where users have different access levels than you expected.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-16T20:23:21.653Z
Answers.Text: good info. so for each additional 'public' event you would need to add that event to the ACL?
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-16T20:27:03.847Z
Answers.Text: and if so - and if that makes this not sufficient, perhaps a custom field on an Event to mark some as 'For public eyes' and some for 'special folk'' (and i agree, knowing if the OP means 'users' or 'contacts with a membership' is a key point to get clarified
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-17T14:47:49.650Z
Answers.Text: Pete: Yes, you would need to add a new ACL for each "unauthenticated users event", since the ACL UI will only allow selecting one event.
Answers.UserDisplayName: TwoMice
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-17T14:49:48.317Z
Answers.Text: Pete: And to your other point, I'm not sure that a custom field would help, as there's no support for that in ACLs. If you want to elaborate, it might make a nice alternative answer.
Answers.UserDisplayName: TwoMice
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-17T18:35:16.073Z
Answers.Text: yes the custom field would require an extension
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-16T19:04:46.690Z
Answers.LastActivityDate: 2020-03-16T19:04:46.690Z
Answers.UserDisplayName: TwoMice
Answers.Body: <p>A more custom approach could involve adding a Custom Field to Events, that is used to differentiate if the Event is 'public' or not, and then build an extension that provides the ACL to determine whether anonymous should be able to see/register the event.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-03-17T18:37:23.663Z
Answers.LastActivityDate: 2020-03-17T18:37:23.663Z
Answers.UserDisplayName: petednz - fuzion
Body: <p>I want some CiviCRM events to be Member-only and some to be public. But I'm not seeing a way of creating an ACL permission for the anonymous user and then assigning it to an event.</p>
  
  <p>The only way of doing seems to be to revert to Drupal permissioning, which is global and not selective.</p>
  
  <p>Is there a way around this? I'm thinking make all events available to everyone and put ACLs on profiles attached to events?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-03-22T20:38:55.090Z
Comments.Text: Did you see Jon's answer to https://civicrm.stackexchange.com/questions/28955/roles-for-specific-event-registration and is it of any help?
Comments.UserDisplayName: petednz - fuzion
Tags: <civievent><acl>
Title: Is there a method in ACL of allowing anonymous access to some events and not others?
ThreadText: # Is there a method in ACL of allowing anonymous access to some events and not others?
  
  (Asked by: username_0 on 2019-03-22)
  
  I want some CiviCRM events to be Member-only and some to be public. But I'm not seeing a way of creating an ACL permission for the anonymous user and then assigning it to an event.
  
  The only way of doing seems to be to revert to Drupal permissioning, which is global and not selective.
  
  Is there a way around this? I'm thinking make all events available to everyone and put ACLs on profiles attached to events?
  
  **Tags:** civievent, acl
  
  > **Comments:**
  > **username_1**: Did you see Jon's answer to https://civicrm.stackexchange.com/questions/28955/roles-for-specific-event-registration and is it of any help?  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2020-03-16. Score: 2
  
  The title of your question only makes a distinction for "anonymous" users; the question itself mentions "Member-only" vs "public".
  
  If by "Member" you mean "current membership holders as defined in CiviMember", then the [Member Only Event](https://civicrm.org/extensions/member-only-event) extension is probably a good choice.
  
  If on the other hand you only mean "members of my site" a.k.a. "logged in users", then what you're describing is possible with ACLs. The following will default to "authenticated users only" for all events, with exceptions defined on a per-event basis using ACLs.
  
  1. Configure Drupal (or other CMS) permissions to deny the "CiviEvent: register for events" permission for the Anonymous role, and grant this permission to the Authenticated role.
  2. In CiviCRM, create an ACL that grants "Edit" permission to a single event for the "Everyone" role, as in this example:
     [![enter image description here](https://i.sstatic.net/8koGB.png)](https://i.sstatic.net/8koGB.png)
  3. Naturally you'll want to test that event and a normal "authenticated user only" event, both as an authenticated user and as an anonymous user, for your own peace of mind that it's configured correctly.
  
  An important caveat here is that with ACLs you are introducing a separate mechanism for managing user permissions, which runs parallel with -- and sometimes overlaps with -- Drupal permissions. That's not a bad thing; it just means it's important to a) have a clear understanding of what you're enabling, b) test to ensure you've configured it correctly, and c) remember to check ACLs as well as Drupal permissions, if you ever find an issue later on where users have different access levels than you expected.
  
  > **Comments:**
  > **username_1**: good info. so for each additional 'public' event you would need to add that event to the ACL?  
  > **username_1**: and if so - and if that makes this not sufficient, perhaps a custom field on an Event to mark some as 'For public eyes' and some for 'special folk'' (and i agree, knowing if the OP means 'users' or 'contacts with a membership' is a key point to get clarified  
  > **username_2**: Pete: Yes, you would need to add a new ACL for each "unauthenticated users event", since the ACL UI will only allow selecting one event.  
  > **username_2**: Pete: And to your other point, I'm not sure that a custom field would help, as there's no support for that in ACLs. If you want to elaborate, it might make a nice alternative answer.  
  > **username_1**: yes the custom field would require an extension  
  
  ---
  
  ### Answer by username_1 on 2020-03-17. Score: 1
  
  A more custom approach could involve adding a Custom Field to Events, that is used to differentiate if the Event is 'public' or not, and then build an extension that provides the ACL to determine whether anonymous should be able to see/register the event.
  
  
  ---
  
  