An event itself is never explicitly on-sale, or not-on-sale on its own - that's determined by evaluating all the settings for each type of ticket for sale, for that event . I wish it were that simple!
There is a StockItem model. A stock item is essentially a type of ticket for sale. An event can have many of these. It has four relevant attributes: on_sale_at, end_sale_at, enabled (boolean), and paused (boolean) (which are not currently available in the API). When the current time falls outside those two dates, or if enabled is FALSE or if paused is TRUE, then the StockItem is not on sale. In Miele's case, these properties are set automatically based on the event start_date, end_date, and cut_sales_policy. However... admins can edit any of those four settings at any time, so relying on the event dates is not fully accurate.
Initial settings:
on_sale_at = when the ticket was put on sale (i.e. when the event was created)
end_sale_at = event.start_date - cut_sales_policy. cut_sales_policy in this case is 24 hours for Miele.
enabled=TRUE
paused=FALSE
Ultimately, relying on the event dates to determine if a class is onsale is not ideal, as its not the source of truth... because settings can change, an event can have multiple tickets/stock_items for sale (each with their own onsale/endsale dates), and most importantly, an admin can disable sales on a StockItem, etc.
What do you want to see happen? Do you want those four properties added to the API? I can also add a boolean on_sale attribute to make it simpler (and you'd see this on the ticket tier object, ie.e. where the status attribute is). I could potentially add this attribute to the Event (and it would check if any stock items are on sale), but I am worried about performance.
An event itself is never explicitly on-sale, or not-on-sale on its own - that's determined by evaluating all the settings for each type of ticket for sale, for that event . I wish it were that simple!
There is a StockItem model. A stock item is essentially a type of ticket for sale. An event can have many of these. It has four relevant attributes: on_sale_at, end_sale_at, enabled (boolean), and paused (boolean) (which are not currently available in the API). When the current time falls outside those two dates, or if enabled is FALSE or if paused is TRUE, then the StockItem is not on sale. In Miele's case, these properties are set automatically based on the event start_date, end_date, and cut_sales_policy. However... admins can edit any of those four settings at any time, so relying on the event dates is not fully accurate.
Initial settings:
on_sale_at = when the ticket was put on sale (i.e. when the event was created)
end_sale_at = event.start_date - cut_sales_policy. cut_sales_policy in this case is 24 hours for Miele.
enabled=TRUE
paused=FALSE
Ultimately, relying on the event dates to determine if a class is onsale is not ideal, as its not the source of truth... because settings can change, an event can have multiple tickets/stock_items for sale (each with their own onsale/endsale dates), and most importantly, an admin can disable sales on a StockItem, etc.
What do you want to see happen? Do you want those four properties added to the API? I can also add a boolean on_sale attribute to make it simpler (and you'd see this on the ticket tier object, ie.e. where the
statusattribute is). I could potentially add this attribute to the Event (and it would check if any stock items are on sale), but I am worried about performance.