*** Bug 10995 has been marked as a duplicate of this bug. ***

Maybe the current date format could be displayed in the alert message?
Something like:
 	
alert(MSG_PLEASE_ENTER_A_VALID_DATE '('+ dateformat + ')');

---
I found following place without validation:

Go to Detail of a patron with hold(s)
Select Tab Hold
Date field near "Suspend all holds until" allows wrong date format, e.g. "12345678"

*** Bug 11448 has been marked as a duplicate of this bug. ***

g13:42 ~/kohaclone (master % u=)$ git qa 14060
Note: checking out 'origin/master'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at fd12390... Bug 15010: Import patron tool creates 'duplicate' restrictions ( debarments )
Branch bug14060-qa set up to track remote branch master from origin.
Switched to a new branch 'bug14060-qa'
Bug 14060 - Remove readonly on date inputs

38484 - Bug 14060: Remove readonly attributes on date inputs
38540 - Bug 14060: Add OnClose event on missing datepicker
38541 - Bug 14060: Display the date format on the warning popup

Apply? [(y)es, (n)o, (i)nteractive] y
Applying: Bug 14060: Remove readonly attributes on date inputs
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/tools/modborrowers.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/reserve/request.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/circ/returns.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/circ/offline.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/circ/circulation.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/acqui/invoices.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/modules/acqui/invoice.tt
Auto-merging koha-tmpl/intranet-tmpl/prog/en/includes/checkouts-table-footer.inc
Auto-merging koha-tmpl/intranet-tmpl/prog/en/includes/calendar.inc
Auto-merging koha-tmpl/intranet-tmpl/prog/en/includes/borrower_debarments.inc
Applying: Bug 14060: Add OnClose event on missing datepicker
Applying: Bug 14060: Display the date format on the warning popup
13:43 ~/kohaclone (bug14060-qa % u+3)$

Testing with date format "MM/DD/YYYY":

In the "specify due date" field I was able to enter "11/1/2015" without any error. When I checked out the item it ignored the invalid date and used the default due date.

In the "Renewal due date" field I was able to enter "11/1/2015" without any error. When I clicked the renew button the AJAX renewal process was started but never finished. Firebug reveals the error in the AJAX response:

"The given date (11/1/2007) does not match the date format (us) at /home/oleonard/kohaclone/Koha/DateUtils.pm line 153."

Hi Owen,
Could you detail how you managed to insert an invalid date?

(In reply to Jonathan Druart from comment #12)
> Could you detail how you managed to insert an invalid date?

I typed it in the date input field.

(In reply to Owen Leonard from comment #13)
> (In reply to Jonathan Druart from comment #12)
> > Could you detail how you managed to insert an invalid date?
> 
> I typed it in the date input field.

Indeed :)
I was using another version of the code.

Hi Jonathan,

Sorry, I found following issues:

1)
Syspref dateformat = dmydot (01.10.2017) is not covered by the function is_valid_date

Symptom 1:
  - Set syspref dateformat to dmydot, clear browser chache
  - Try to add a manual restriction on moremember.pl
  - manually enter 26.01.2017
  - hit 'Add restriction'
    Result: restriction is added with empty date = indefinite restriction.

Symptom 2:
  - manually enter 1.1.2018
  - hit enter
  - Message appears "Please enter valid date...", closes automatically after ca. 1 second
    Result: restriction is added with empty date = indefinite restriction.


2)
Software error in following cases

Case 1:
  - Set syspref dateformat to dd/mm/yyyy, clear browser cache
  - manually enter 1/10/2017
  - hit 'Add restriction'
  Result: Software error: The given date (1/10/2017) does not match the date format (metric) at /usr/share/kohaclone/Koha/DateUtils.pm line 153.

Case 2:
  - Set syspref to yyyy-mm-dd
  - manually enter 2017-2-2
  - hit 'Add Restiction'
  Result: Software error: The given date (2018-2-2) does not match the date format (iso) at /usr/share/kohaclone/Koha/DateUtils.pm line 153.

It seems that the timepicker's function parseDate accepts such dates.

(In reply to Marc Véron from comment #16)
> Hi Jonathan,
> 
> Sorry, I found following issues:
> 
> 1)
> Syspref dateformat = dmydot (01.10.2017) is not covered by the function
> is_valid_date
> 
> Symptom 1:
>   - Set syspref dateformat to dmydot, clear browser chache
>   - Try to add a manual restriction on moremember.pl
>   - manually enter 26.01.2017
>   - hit 'Add restriction'
>     Result: restriction is added with empty date = indefinite restriction.
> 
> Symptom 2:
>   - manually enter 1.1.2018
>   - hit enter
>   - Message appears "Please enter valid date...", closes automatically after
> ca. 1 second
>     Result: restriction is added with empty date = indefinite restriction.


Should be fixed with the last patch.

> 2)
> Software error in following cases
> 
> Case 1:
>   - Set syspref dateformat to dd/mm/yyyy, clear browser cache
>   - manually enter 1/10/2017
>   - hit 'Add restriction'
>   Result: Software error: The given date (1/10/2017) does not match the date
> format (metric) at /usr/share/kohaclone/Koha/DateUtils.pm line 153.
> 
> Case 2:
>   - Set syspref to yyyy-mm-dd
>   - manually enter 2017-2-2
>   - hit 'Add Restiction'
>   Result: Software error: The given date (2018-2-2) does not match the date
> format (iso) at /usr/share/kohaclone/Koha/DateUtils.pm line 153.
> 
> It seems that the timepicker's function parseDate accepts such dates.

I don't manage to force the leading zeros, suggestions are welcome.

(In reply to Jonathan Druart from comment #18)
(...)
> I don't manage to force the leading zeros, suggestions are welcome.

The date validation seems to be on the datepicker's onClose and change functions only, but there is no onclick function directly on the Submit button. I think that a final date validation could take place there with a function that returns false if the date is not valid. Maybe the same function could try to do some formatting (1/1/2016 -> 01/01/2016  etc.) before validation.

I'd really like to see this moving forward. So, if I understand correctly, the current problem is that the validation is not triggered, when you enter the date without using the datepicker?

(In reply to Katrin Fischer from comment #20)
> I'd really like to see this moving forward. So, if I understand correctly,
> the current problem is that the validation is not triggered, when you enter
> the date without using the datepicker?

Hi Katrin,

That seems to be one of the problems, but I think some problems hide other ones.

I write down som notes I did while playing with the code, just pro memoria.

One finding is that in borrower_debarments.inc, the id manual_restriction_form is not on the form, but on the fieldset:
 <fieldset class="rows" id="manual_restriction_form">

After moving the form tag, I was able to add a validation to the form, something like:
            mrform.on("submit",function(e) {
                var testDate = $("#rexpiration").val();
                if (!validate_date( testDate )) {
                    e.preventDefault();
                    return false;
                }
                return true;
            }); 


Then I tweaked is_valid_date(date) to return false if it gets dates like 1.1.2014 etc. (depending on the dateformat syspref), something like:

function is_valid_date(date) {
    var dateformat = dateformat_str = '[% Koha.Preference('dateformat') %]';
    if ( dateformat == 'us' ) {
        if (! date.match('[0-9]{2}/[0-9]{2}/[0-9]{4}') )
            return 0;
        dateformat = 'mm/dd/yy';
        dateformat_str = 'mm/dd/yyyy';
    } else if ( dateformat == 'metric' ) {
        if (! date.match('[0-9]{2}/[0-9]{2}/[0-9]{4}') )
            return 0;
        dateformat = 'dd/mm/yy';
        dateformat_str = 'dd/mm/yyyy';
    } else if (dateformat == 'iso' ) {
        if (! date.match('[0-9]{2}-[0-9]{2}-[0-9]{4}') )
            return 0;
        dateformat = 'yy-mm-dd';
        dateformat_str = 'yyyy-mm-dd';
    } else if ( dateformat == 'dmydot' ) {
        if (! date.match('[0-9]{2}.[0-9]{2}.[0-9]{4}') )
            return 0;
        dateformat = 'dd.mm.yy';
        dateformat_str = 'dd.mm.yyyy';
    }
    try {
        $.datepicker.parseDate(dateformat, date);
    } catch (e) {
        return 0;
    };
    return 1;
}

Then I tweaked the function validate_date to return true / false (in calendar.inc)

function validate_date (dateText, inst) {
    if ( !is_valid_date(dateText) ) {
        var dateformat_str = '[% Koha.Preference('dateformat') %]';
        alert(MSG_PLEASE_ENTER_A_VALID_DATE.format(dateformat_str));
        if (inst) {
            $('#'+inst.id).val('');
        }
        return 0;
    }
    return 1;
}

(The if (inst) was to avoid a JavaScript error)


Now I could trigger the validation. But one problem now was that empty dates could no longer be saved.

I have no more time at the moment to dig deeper, but maybe the notes can help somebody else to find a solution.

Adding Owen... maybe he has an idea about the client side Javascript checks

For the records: jQuery Validation Plugin's date method is no option, it would consider 30/30/2008 as a valid date.
"Use dateISO instead or one of the locale specific methods (in localizations/ and additional-methods.js)." See: https://jqueryvalidation.org/date-method

For the records:

koha-tmpl/intranet-tmpl/prog/js/members.js
(...)
// this function checks id date is like DD/MM/YYYY
function CheckDate(field)
(...)

Used in:

koha-tmpl/intranet-tmpl/prog/en/modules/members/memberentrygen.tt
for fields dateenrolled and dateexpiry
(only if dateformat == "metric" )

I think this version should be push as it, and follow-ups could come later...

(In reply to Jonathan Druart from comment #25)
> I think this version should be push as it, and follow-ups could come later...

No discussion and what I proposed is the only suggestion, so I switch the status back to needs signoff.

I'm getting a JavaScript error on returns.pl:

SyntaxError: expected expression, got ','
$("#barcode").focus(); },

Is it possible for the error message to use the date format pattern instead of the date format name? It's not very clear for the alert to say

"Please enter a valid date (should match us)."

It would be better to see:

"Please enter a valid date (should match MM/DD/YYYY)."

Other than that, this seems to be working really well.

- With my date format preference set to US (mm/dd/yyyy) it accepts dates like 3/3/2016. Sometimes saving this date triggers an error in Koha, sometimes the date is ignored (and no date is saved).

- With my date format preference set to dmydot (dd.mm.yyyy) it accepts dates like 1.1.2016 without any warning, but the date which is saved does not match (in this case, 12.09.2016). The same thing happens with dd/mm/yyyy, including the saved date -- 12/09/2016.

- I'm getting no warnings on the patron edit page when adding invalid data to the date of birth field. It works correctly with registration date and expiration date.

This all works very well, I can't enter any errors, I can press enter with an invalid date, but it reads it as empty so that seems okay.

My one complaint would be that if you click into the datepicker, and decide not to enter a date you should not receive the warning. That is, closing on an empty value should not warn

(In reply to Nick Clemens from comment #50)
> This all works very well, I can't enter any errors, I can press enter with
> an invalid date, but it reads it as empty so that seems okay.
> 
> My one complaint would be that if you click into the datepicker, and decide
> not to enter a date you should not receive the warning. That is, closing on
> an empty value should not warn

Heh, good catch!

Hmm..and now one more I ran across:

At checkout, specify due date of: January 1, 01984

No error on setting this date, but attempting to checkout gives an invalid date error.

Checking in items you can set and keep 01/01/01984 and items are marked as returned 0198-01-01 00:00:00

I am not sure if these dates should be handled, or simply rejected (I think the latter)

(In reply to Jonathan Druart from comment #54)
> Created attachment 55246 [details] [review] [review]
> Bug 14060: Improve regex to limit year to 4 integers
> 
> 01/01/01984 should not be considered as a valid date.

I hope Koha stays free software until the year 10000, or this will lead to some library having to sponsor a new ILS again.

Created attachment 55247 [details] [review]
Bug 14060: Remove readonly attributes on date inputs

In order to remove accessibility issues due to the readonly attributes
on date inputs, this patch will remove them and introduce a javascript
validation on them.

This patch is not perfect for some reason:
I didn't manage to force the user to select a valid date. One solution
would be to reopen the datepicker plugin until a valid date is inserted.
But it could be annoying for users (and for me: I did not manage to
implement this solution).
You will note that input is emptied if the date is not valid. This is a
quick and efficient solution to prevent submitting invalid date and make
Koha explodes. A proper solution would be to implement the check server
side send a friendly message to the user.

Test plan:
For all inputs, try an invalid and a valid date.
 1/ Debar a patron
 2/ On the checkout tables (circulation and moremember), add a renewal
due date (at the bottom of the tables)
 3/ On the checkout page, specify a due date
 4/ On the return page, specify a return date
 5/ On the invoice page (acquisition module), enter a shipment and
billing date
 6/ On the invoice search page (invoices.pl) use filters shipment and
billing dates
 7/ On the offline circ page, specify a due date
 8/ On the edit patron page (memberentry), add a debarment
 9/ On the reserve page (reserve/request.pl), use the date inputs to
suspend until a defined date
10/ Edit patrons in a batch (tools/modborrowers.pl) and use the
registration and expiry date inputs

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 55248 [details] [review]
Bug 14060: Add OnClose event on missing datepicker

The "suspend until" inputs (hold list on circ/circulation.pl and
members/moremember.pl) were not set in the same way.
The minDate option should be set for both (bug 10703 removed it for
circ/circulation.pl).
This patch reintroduces the option and add the OnClose event on both.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 55249 [details] [review]
Bug 14060: Display the date format on the warning popup

The date format is now displayed on the warning popup.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 55250 [details] [review]
Bug 14060: Force the input to contain a valid date

Before this patch, the user was still allowed to enter a valid date.
Now, if the date is not valid, the input is emptied.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 55251 [details] [review]
Bug 14060: Add support for dmydot

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 55252 [details] [review]
Bug 14060: Display date format pattern instead of date format name

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 55253 [details] [review]
Bug 14060: Force leading zeros on date

If a date does not contain leading zeros for day and month, the date
will be refused.
parseDate function considers 1/1/1990 as a valid date, but our perl code
does not. We must refuse it.

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 55254 [details] [review]
Bug 14060: Add the datepicker class to dateofbirth

Signed-off-by: Owen Leonard <oleonard@myacpl.org>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 55255 [details] [review]
Bug 14060: Consider an empty string as a valid date

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Created attachment 55256 [details] [review]
Bug 14060: Improve regex to limit year to 4 integers

01/01/01984 should not be considered as a valid date.

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>

Pushed to master for 16.11, thanks Jonathan!

Pushed in 16.05. Will be in 16.05.05.

Hello,
I see an error when format  is an ISO (yyyy-mm-dd).
In the calendar.inf file the date format appears to: 

dateformat = 'yy-mm-dd'
but in a ISO format is  dateformat = 'yyyy-mm-dd'
four digits for year...

(In reply to MetaBiblioteca Colombia from comment #68)
> Hello,
> I see an error when format  is an ISO (yyyy-mm-dd).
> In the calendar.inf file the date format appears to: 
> 
> dateformat = 'yy-mm-dd'
> but in a ISO format is  dateformat = 'yyyy-mm-dd'
> four digits for year...

can you please specify the page and date you tried?
What kind of error do you get?

(In reply to MetaBiblioteca Colombia from comment #68)
> Hello,
> I see an error when format  is an ISO (yyyy-mm-dd).
> In the calendar.inf file the date format appears to: 
> 
> dateformat = 'yy-mm-dd'
> but in a ISO format is  dateformat = 'yyyy-mm-dd'
> four digits for year...

See bug 17524 for a patch.