Bug 11846

I'm just wondering why even fix the old one? It requires more testing to prove it works. If it upgrades incorrectly (because you upgrade an older one), the current one will fix it. If it already upgraded incorrectly (because you upgrade after the back patch fix), the current one will fix it. But because of the back patch fix portion, you need to test the upgrading prior to the back patch fix portion.

You confused debarred (from borrowers) with expiration (from borrower_debarments).

(In reply to M. Tompsett from comment #3)
> You confused debarred (from borrowers) with expiration (from
> borrower_debarments).
Oh.
Is the patch wrong or is only the upgrade text wrong ?

Comment on attachment 25637 [details] [review]
Bug 11846 - Correct database update for debarments with 9999-12-31

Review of attachment 25637 [details] [review]:
-----------------------------------------------------------------

::: installer/data/mysql/updatedatabase.pl
@@ +8019,5 @@
>  
> +$DBversion = "3.15.00.XXX";
> +if ( CheckVersion($DBversion) ) {
> +    $dbh->do(q{
> +        UPDATE borrower_debarments SET debarred = NULL WHERE debarred = '9999-12-31'

This line is not right, as there is no debarred as a date in borrower_debarments. Please fix and test.

Thank you for clarifying the problem, Katrin. That line. :)

Indeed. I correct my patch

Thanks for the fix. However, you still didn't address my question in comment 2.

"why even fix the old one?"

If it upgrades incorrectly (because you upgrade an older one), the current one will fix it. If it already upgraded incorrectly (because you upgrade after the back patch fix), the current one will fix it. I see no reason to change historical versions.

Is there a reason not to fix the old update? :)

(In reply to Katrin Fischer from comment #10)
> Is there a reason not to fix the old update? :)

I agree that we can fix older updates. And in this case testing the older dbrev is more or less a theoretical problem. (By resetting Version and adding one SetVersion line in updatedatabase, we can achieve the same result.)

> 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.)

Yes, borrower.debarred was retained for both speed and the fact that we wouldn't need to modify all the code that checks this field.

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

Agreed, but again this is due to the extended feature being "backwards compatible" with the original debarment system.

Created attachment 27093 [details] [review]
Bug 11846 - Correct database update for debarments with 9999-12-31

The borrowers with infinite debarments 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 infinite debarments.

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 debarments (which looks not very consistent).

Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>

Pushed to master.  Thanks, Fridolin!

Patch pushed to 3.14.x, will be in 3.14.06
(creates version 3.14.05.001)