Answers.Body: <p>I realised that I didn't have to wait for the participant status cron job to run and could run it from the console, so have done some testing and find that by default a cancellation after the event means that a wait-listed person will be offered a place to a now past event. So I looked at my alternatives.</p>
  
  <p>a) does work and is probably the safest and sensibly matches any cut off time for event bookings.</p>
  
  <p>b) works, but I think the person managing the event may forgot</p>
  
  <p>c) works and I thinks its probably what I will use as it distinguishes between the two cases where the place can potentially be reused or not.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-28T18:40:56.100Z
Answers.Text: Glad you found something that can work for you. Still sounds as if the Waitlist feature could do with a tweak to avoid functioning after Event End Date - if you are keen you could open an issue in https://lab.civicrm.org/dev
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-03T21:32:42.450Z
Answers.Text: I think its probably OK, because the waitlist processing only happens when the online booking is open. Its easy to set a cut-off date for bookings. Whilst I can't see a reason for allowing online bookings after the event date, I guess it might allow flexibility for some unusually usage.
Answers.UserDisplayName: Mick Kahn
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-03T21:33:38.490Z
Answers.Text: Bearing in mind the previous comment I actually chose to use my option (a) above.
Answers.UserDisplayName: Mick Kahn
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-28T08:50:41.840Z
Answers.LastActivityDate: 2018-03-28T08:50:41.840Z
Answers.UserDisplayName: Mick Kahn
Body: <p>I'm wanting to keep track of event attendance and in particular to distinguish between those who let us know at the last minute from the complete no-shows. With earlier cancellations I can use the "cancelled" status, which will trigger an offer on the wait-list, but I'm concerned that if I set someone to "cancelled" after the event that it will still offer a place to someone on the wait-list which would be wrong. I can't see anything that stops registration after the date of the event and I presume that this means the wait-list would behave the same.</p>
  
  <p>It would be good to know the default behavior before I explore a few work rounds. I can see a few ways round this:</p>
  
  <p>a) set the online registration to explicitly stop on the day of the event (but would still need to check this would apply to the wait-list</p>
  
  <p>b) explicitly disable the event booking before recording the attenance information</p>
  
  <p>c) creating a new status of "Apologised" for late cancellations that is still counted in the attendance count.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-03-27T18:31:40.217Z
Comments.Text: This maybe the sort of conundrum that is best analysed by creating a test event and seeing what happens
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-03-27T22:13:47.790Z
Comments.Text: Certainly am considering that but involves doing things over a few days to let the event date pass and the wait-list processing run.
Comments.UserDisplayName: Mick Kahn
Tags: <waitlist>
Title: waitlist behaviour
ThreadText: # waitlist behaviour
  
  (Asked by: username_0 on 2018-03-27)
  
  I'm wanting to keep track of event attendance and in particular to distinguish between those who let us know at the last minute from the complete no-shows. With earlier cancellations I can use the "cancelled" status, which will trigger an offer on the wait-list, but I'm concerned that if I set someone to "cancelled" after the event that it will still offer a place to someone on the wait-list which would be wrong. I can't see anything that stops registration after the date of the event and I presume that this means the wait-list would behave the same.
  
  It would be good to know the default behavior before I explore a few work rounds. I can see a few ways round this:
  
  a) set the online registration to explicitly stop on the day of the event (but would still need to check this would apply to the wait-list
  
  b) explicitly disable the event booking before recording the attenance information
  
  c) creating a new status of "Apologised" for late cancellations that is still counted in the attendance count.
  
  **Tags:** waitlist
  
  > **Comments:**
  > **username_1**: This maybe the sort of conundrum that is best analysed by creating a test event and seeing what happens  
  > **username_0**: Certainly am considering that but involves doing things over a few days to let the event date pass and the wait-list processing run.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2018-03-28. Score: 2 | Accepted answer
  
  I realised that I didn't have to wait for the participant status cron job to run and could run it from the console, so have done some testing and find that by default a cancellation after the event means that a wait-listed person will be offered a place to a now past event. So I looked at my alternatives.
  
  a) does work and is probably the safest and sensibly matches any cut off time for event bookings.
  
  b) works, but I think the person managing the event may forgot
  
  c) works and I thinks its probably what I will use as it distinguishes between the two cases where the place can potentially be reused or not.
  
  > **Comments:**
  > **username_1**: Glad you found something that can work for you. Still sounds as if the Waitlist feature could do with a tweak to avoid functioning after Event End Date - if you are keen you could open an issue in https://lab.civicrm.org/dev  
  > **username_0**: I think its probably OK, because the waitlist processing only happens when the online booking is open. Its easy to set a cut-off date for bookings. Whilst I can't see a reason for allowing online bookings after the event date, I guess it might allow flexibility for some unusually usage.  
  > **username_0**: Bearing in mind the previous comment I actually chose to use my option (a) above.  
  
  ---
  
  