[BUG] You can enter an issued_at date without a time. Hijinks ensue.

[cielf]

Summary

It is possible to enter an issued_at date without a time. If you do, the date is not properly saved.

Why investigate?

Possible reduction of support issues.

Details

See discussion in #3530
Enter a new (or edit a) distribution. Change the date to a different day, but blank out the time. Save.
It saves as today. Weird.

This is not incredibly high priority, as we've made it so the user has to go out of their way to enter an issued_at date without a time.

Criteria for completion

[] Figure out how we could fix this
[] Either put in a PR to fix it, comment the heck out of it on this issue and raise it to the senior folks attention, or come to the Sunday meeting to discuss.

[MohanThanigaivelan]

Hi @cielf , Can I take up this one if available ?

[dorner]

Go for it!

[MohanThanigaivelan]

Thanks @dorner . As per my analysis so far, browser validation is set to false here.

human-essentials/config/initializers/simple_form.rb

Line 124 in b583d7b

config.browser_validations = false

If enabled it would have shown like this in chrome and prevented the form submission.

Will try to find a way a solution of achieving something similar to this without updating browser_validations config .

[MohanThanigaivelan]

Hi @dorner ,

I think , we can solve this in three ways.

1. Prevent users from manually typing in the datetime field and ensure they only use a date-time picker.
2. Enable browser validations only for this form . Browser prevents from form submission and automatically displays an error message indicating which field needs to be corrected.
3. When user clicks Save , before proceeding with the submission , validate the date time and display a custom error message in a popup if validation fails

Which one do you prefer is the best ? I prefer option 1 due to simplicity .

[MohanThanigaivelan]

@dorner / @cielf , Can you check my above comment ? thanks

[cielf]

Hey @MohanThanigaivelan -- I definitely want @dorner's take on this.

If we were to go with #1, we'd want to have the same restriction in some other places, for consistency's sake. There might be accessibility issues with not allowing the text input, though. (need to check if our current datepicker meets the appropriate standards)

The other two may introduce an inconsistent look and feel, which can be confusing to users.

[dorner]

Yeah, I wouldn't want to choose #1 - locking things down unless you have JS working is kind of a last resort.

If we can detect the bad date/time on the controller side, I'd rather validate it there and punt them back with an error. We should be able to do this in a reusable way so all date-time fields can make use of that logic.