Bug 32383 - Indefinite debarments should not be recorded with an expiration date of '9999-12-31'
Summary: Indefinite debarments should not be recorded with an expiration date of '9999...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Patrons (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on: 11846
Blocks:
  Show dependency treegraph
 
Reported: 2022-11-30 21:27 UTC by Andrew Fuerste-Henry
Modified: 2023-03-10 15:04 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Fuerste-Henry 2022-11-30 21:27:28 UTC
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.'
Comment 1 Magnus Enger 2023-03-10 15:04:43 UTC
To widen the scope of this a bit, we could perhaps consider if it makes sense to record debarments/restrictions both in the borrowers table, and in the dedicated borrower_debarments table? Would it not make more sense to have them only in the borrower_debarments table, since there can be multiple debarments per patron?