"Edit access" screen has trouble with jscalendar dates if you change calendar_dateFormat and/or strtimedatetimeshort
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mahara |
Fix Released
|
Medium
|
Unassigned | ||
1.10 |
Won't Fix
|
Medium
|
Unassigned | ||
15.04 |
Fix Released
|
Medium
|
Unassigned | ||
15.10 |
Fix Released
|
Medium
|
Unassigned |
Bug Description
This is a follow up on Bug #1376997 Date picker not working for certain languages
The date picker works with the dd.mm.yy format when editing access ("shared by me" page).
However if you are to change in langconfig.php the parameters to a french format:
$string[
$string[
You can use the date picker and define a new access. However, you cannot edit a preexisting access besause it doesnt show up when you go to edit it. You are forced to redefine all your access if you want to modify anything.
Theres also a problem when you try to define "Access start date/time" and "Access end date/time" in the Advanced option. It will take the dd/mm/yy format of the datepicker. However, you cannot choose a day higher then 12. You can on the other hand enter a mm/dd/yy format into the textbox manually to define the access.
If the code itself is too complicated to fix, there should at least be a converter to show the chosen date format to the users.
description: | updated |
Changed in mahara: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
summary: |
- Edit access not working in french + "Edit access" screen has trouble with jscalendar dates if you change + calendar_dateFormat and/or strtimedatetimeshort |
Changed in mahara: | |
status: | Fix Committed → Fix Released |
Hi David,
I've confirmed this problem. For now, the workaround is to change calendar_dateFormat and strftimedatetim eshort back to the originals from the English langpack. (And update the lang strings for the help text, to match.) I've looked through the code and verified that calendar_dateFormat and strftimedatetim eshort are nearly only used for the JS calendar widget (strftimedateti meshort also has a couple of other minor uses, usually in outputting data to admins).
Going forward, here's what I would suggest for the fix:
1. For the calendar, instead of using "strftimedateti meshort" , we use a new lang string called "calendar_ phpdatetimeform at".
2. We rename "calendar_ dateformat" to "calendar_ jsdateformat" , and "calendar_ timeformat" to "calendar_ jstimeformat" .
3. Items #1 and #2 together should help make it clearer to devs that these strings must match each other.
4. If possible we add some code to the Pieform calendar and acl elements, so that they themselves do the date format validation, and so that they render the human-readable date into a hard-coded format by the time it gets sent to the form's "_submit" function. That way, we won't have to rely on the devs remembering to use the correct lang strings to parse and validate the calendar's dates on every form where it is used. (It is evident we devs have not been remembering to do that.)
5. If #4 is not possible, at least add some documentation to the Pieform calendar and acl elements. And go through all the forms that use them and fix their validation and submission code.
Unfortunately, this is a non-trivial fix, so I'm probably not going to get to it immediately. In the meantime, I'd suggest using that workaround, of changing calendar_dateFormat and strftimedatetim eshort back to the original values. This shouldn't be a huge inconvenience to your users, because the JS calendar widget means they shouldn't actually need to type in a date anyway.
Cheers,
Aaron