[Koha-bugs] [Bug 31143] We should attempt to fix/identify all cases where '0000-00-00' may still remain in the database

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31143

David Nind <david at davidnind.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Text to go in the|                            |This new script identifies
      release notes|                            |patron fields that have
                   |                            |'0000-00-00' for date
                   |                            |fields (for example:
                   |                            |dateofbirth) and updates
                   |                            |them to 'NULL'. Date fields
                   |                            |with a value of '000-00-00'
                   |                            |can cause upgrade and API
                   |                            |issues, stop the
                   |                            |autocomplete patron search
                   |                            |working, and generate a 500
                   |                            |internal server error issue
                   |                            |with normal patron
                   |                            |searching.
                 CC|                            |david at davidnind.com

--- Comment #6 from David Nind <david at davidnind.com> ---
Testing notes (using KTD):

1. Before applying the patch, I updated a couple of patron records using this
SQL (Mary (49) and Henry (19)):
   . koha-mysql kohadev
   . update borrowers set dateofbirth ="0000-00-00" where borrowernumber =
"49";
   . update borrowers set date_renewed ="0000-00-00" where borrowernumber =
"19";

2. Note that the values updated now have a value of 0000-00-00 (SQL: select *
from borrowers where borrowernumber = 19;).

3. In the staff interface, go to patrons. Note that the autocomplete for the
search in the header doesn't work, and that you get a 500 error if you use the
search on the left-hand side:

  Something went wrong when loading the table.
  500: Internal Server Error. 
  Month out of range.

4. Apply the patch (and restart_all).

5. Run the new script: misc/cronjobs/fix_patron_dates.pl -c -v

6. Output is: 2 wrong dates found

Some other notes:

1. If you run when there are no wrong dates, you get this (with the -c and -v
options):

Use of uninitialized value $count in concatenation (.) or string at
misc/cronjobs/fix_patron_dates.pl line 53.
 wrong dates found

2. I'm not sure of the protocol, but for many scripts:
   - you can add the -h or --help and get quick help with a description, what
the different options do, and some examples.
   - normally the help would have the options, like -v, etc (in the script
currently it just has c or v)
   - sometimes with verbose options, it may list the things changed

3. These could probably be added as new bugs, if determined as warranted.

-- 
You are receiving this mail because:
You are watching all bug changes.