Bug 11846: Correct database update for restrictions with date 9999-12-31
authorFridolin Somers <fridolin.somers@biblibre.com>
Mon, 24 Feb 2014 11:15:55 +0000 (12:15 +0100)
committerGalen Charlton <gmc@esilibrary.com>
Mon, 14 Apr 2014 15:21:23 +0000 (15:21 +0000)
commitf6131d8e6094ae9e221a9d5750d744ed1f91dd85
tree0cf4ed718ca3d98ac03e642fd5bcd135b9009df1
parentc52b086d38cde98504457aa9f40f65ba20bbfbe1
Bug 11846: Correct database update for restrictions with date 9999-12-31

The borrowers with indefinite restrictions have borrowers.debarred with '9999-12-31'.

Database update for this bug contained :
  INSERT INTO borrower_debarments ( borrowernumber, expiration, comment )
  SELECT borrowernumber, debarred, debarredcomment FROM borrowers WHERE debarred IS NOT NULL

For borrowers where borrowers.debarred is '9999-12-31', this value
is copied into borrower_debarments.expiration.

This is not correct because borrower_debarments.expiration must be
NULL for indefinite restrictions.

This patch corrects update 3.13.00.035 and also adds an update for
databases already updated.

Test plan :
- Use a database with version 3.13.00.000
- Set a borrower as restricted for ever (leave until empty)
- Use sources to master + patch
- Perform updatedatabase
- Look at borrower details, tab "Restrictions"
=> Without patch, you see Expiration 31/12/9999
=> With patch, you see Expiration Infinite

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
I tested both DB revisions by resetting Version of my database (and
adding a SetVersion after the revised older dbrev). This was possible
since the debarred field still exists in borrowers. (I have my doubts
about that, but that goes outside the scope of this report.)

Also note that routine _UpdateBorrowerDebarmentFlags puts back 9999-12-31
into borrowers for indefinite restrictions (which looks not very consistent).

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
Signed-off-by: Galen Charlton <gmc@esilibrary.com>
installer/data/mysql/updatedatabase.pl