October 26, 2019 at 5:45 AM #16711Resolved
FYI – When I add a custom attribute of
'readonly'=>trueto a date field, the datepicker still shows in the UI and allows me to change and update the value.
'disabled'=>trueworks as expected (prevents the datepicker)
October 28, 2019 at 9:04 AM #16721
Anh TranKeymasterNovember 1, 2019 at 11:26 PM #16771
Unfortunately, we were using the fact that it ignored readonly to get around the lack of format control for the date entered into the input. We had date fields set to readonly to force users to use the datepicker so that we forced the format of the date to be our preferred format. Otherwise, we had users entering years as 2 digits (e.g. 01/01/20 instead of 01/01/2020) which doesn’t work for us.
This fix has prevented the workaround we were utilizing so how can we now force the year to be 4 digits? We already have the
dateFormatattribute set to
mm/dd/yybut that doesn’t prevent a user from typing a date with only 2 digits. We also have the
save_formatfield setting set to
Y-m-dand that doesn’t help either. I’ve searched the jQueryUI documentation and not found a solution.November 1, 2019 at 11:42 PM #16772
Why was this “fix” even needed? If you don’t want the datepicker, then don’t use a date field. Use a text field instead. If it has to do with forcing a date format, then either use validation on a text field to force the format or maybe we need an option to turn the datepicker on/off for date fields.November 2, 2019 at 5:25 AM #16774
I can understand both sides of this. But for me, this is not a major issue either way. So do what you think is best for MB, of course!
Regardless of what’s done, I wonder if using a pattern attribute would help? Maybe something like
(0[1-9]|1)[- /.](0[1-9]|[0-9]|3)[- /.](19|20)\d\d(I stole that one from: http://html5pattern.com/Dates ) to ensure the field doesn’t pass validation unless the format is
mm/dd/yyyy. https://i.imgur.com/tdHJXfT.png Then your users could still manually input a date (IF that’s desired). Also, I tested setting the display values &
save_formatand they all seem to be working correctly for me based on the docs — If those aren’t working for you, that could be a separate issue to look into. Here are the values I was using in Builder to quickly test: https://i.imgur.com/ZJFvMX4.png
I first came across this and posted it because we were having cases when the field was
readonlybut users were tabbing past the field and the datepicker was showing and they were submitting data. Basically, it just seemed incorrect that a ‘readonly’ field wasn’t read-only. For us, the problem was that the field has different attributes based on conditions (beyond just MB conditions/logic). And while enabling/disabling the datepicker is an option, it wasn’t our approach because it seemed more accurate that a
readonlyfield should not be allowed to change. (Of course, as Anh mentioned earlier, jQuery UI chooses to ignore readonly.)
Our workaround was to use a disabled input, but that prevents the field from submitting (which was an issue because we still wanted the input to submit every time).November 4, 2019 at 9:03 AM #16780
I think there are 2 issues here:
- Read-only attribute, and
- Validation for user input
A Boolean attribute which, if present, indicates that the user should not be able to edit the value of the input.
The difference between
read-onlycontrols can still function, whereas
disabledcontrols are not submitted with the form and generally do not function as controls until they are enabled.
So, it’s better to prevent user to change value from a read-only date picker (the 1st issue).
The validation issue is quite different and I think can be solved with @brandonjp’s solution with
Another issue with
readonlyis that it will ignore the
requiredattribute (ref in the MDN docs above), which sometimes is a problem.
You must be logged in to reply to this topic.