https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32383 Bug ID: 32383 Summary: Indefinite debarments should not be recorded with an expiration date of '9999-12-31' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs@lists.koha-community.org Reporter: andrewfh@dubcolib.org QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com Depends on: 11846 This all might be a regression, looking at Bug 11846 from 2014. To recreate: - have a patron - create a manual restriction for your patron, entering a reason but not a date - confirm that the patron account shows your restriction with an expiration date of "indefinite" - in reports, SELECT * FROM borrower_debarments WHERE borrowernumber= [your patron] - confirm borrower_debarments.expiration is null - in reports, SELECT * FROM borrowers WHERE borrowernumber= [your patron] - confirm borrowers.debarred='9999-12-31' This will cause a lot of issues in 7,977 years. Here in the year 2022, it's generally incorrect and confusing to be using a far-future date to denote "indefinite," and is made more confusing by the fact that borrowers and borrower_debarments don't handle it the same way. This also means one cannot create indefinite debarments via patron import. If one's CSV contains a debarredcomment value without a debarred value, no restriction is created. If one's CSV contains a debarred value of '9999-12-31,' that is treated literally and the restriction is given an expiration date of '9999-12-31.' Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11846 [Bug 11846] Correct database update for debarments with 9999-12-31 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.