Bug: In events, setting an end datetime is not compulsory, which makes sense. However, when leaving that field blank or clearing it, the system fills in a datetime with the same day and the time 23:59
. Expected behavior would be, that the field stays blank so it’s state can be checked for null
on the front end.
@vlad.z @Eugene Can you guys please confirm that this is on your internal backlog, so I can tick this from my list?
Hi @TimL,
I’m afraid this is not a bug, that’s how it’s supposed to be working - an event should have an expiration date. If you think this should be working another way, we’re open to suggestions, just would like to know other partners’ opinions.
@Violetta.S Got it. But in this case the UX is broken then. If Event Date End
is mandatory it should be marked as such (with an asterix) and validated on item submission. That’s because if admins can leave this blank and still create the item, they might not know that an unintended value is populating the field.
Can you please mark this field as mandatory and validate it on item creation?
Hi @TimL
We will make Event Date End field to be mandatory in the current sprint release (v5.7)
Will this break any events in the past that don’t have an end date?
If you had events without an end date, the system would have populated that field with a value, showing the same date and the time 23:59. So if you hadn’t done a workaround to remedy that, like {% unless this['EventDateEnd'] == null or this['EventDateEnd'] | format_date: "H:mm" == "23:59" %} [code to show end date and time] {% endunless %}
you should be good .
@vlad.z Btw the best solution would be to leave the field non-mandatory and also NOT autopopulate it as there are events which have no end datetime indeed (open end events). But if this is creating to much fuss, it works for us as long as it’s consistent in the admin. We can create a fix for that in Liquid and train the client to input e.g. a one minute long event or so to not display an end date on the front end.
But please consider that UX like that makes the platform look kind of deficient for clients though.
Hi @TimL
End date is required to be set in the current event logic so we can’t leave it “unset” for now.
If you want to create infinite events - just set the end date to the +100 years from the start date for example.
Also if you don’t want to show end date for such events you could:
- Create custom property, for example Lifetime Event (boolean type). And use {% if this.LifetimeEvent != true %} in order to show end date only for those events that are Lifetime
- As an alternative you could convert **end date ** to year
{% assign expiryYear = this.expiryDate | date: ‘%Y’ | plus:0 %}
and if it bigger then 2080 for example - do not show the end date.
Thanks, Vlad! Got it.