mahara-contributors team mailing list archive

[Aaron Wells <1455137@xxxxxxxxxxxxxxxxxx>]

Hi David,

I've confirmed this problem. For now, the workaround is to change
calendar_dateFormat and strftimedatetimeshort 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 strftimedatetimeshort are nearly only used for
the JS calendar widget  (strftimedatetimeshort 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 "strftimedatetimeshort", we use a
new lang string called "calendar_phpdatetimeformat".

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 strftimedatetimeshort
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

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1455137

Title:
  "Edit access" screen has trouble with jscalendar dates if you change
  calendar_dateFormat and/or strtimedatetimeshort

Status in Mahara ePortfolio:
  Confirmed
Status in Mahara 1.10 series:
  Confirmed
Status in Mahara 15.04 series:
  Confirmed
Status in Mahara 15.10 series:
  Confirmed

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['calendar_dateFormat']= 'dd/mm/yy';
  $string['strftimedatetimeshort'] = '%%d/%%m/%%Y %%H:%%M';

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1455137/+subscriptions