| Summary: | Prevent cleanup_database.pl from locking too many accounts | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Marcel de Rooy <m.de.rooy> |
| Component: | Patrons | Assignee: | Marcel de Rooy <m.de.rooy> |
| Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | gmcharlt, jonathan.druart, kyle, robin |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | Trivial patch |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: |
22.11.00
|
|
| Circulation function: | |||
| Bug Depends on: | 21336 | ||
| Bug Blocks: | |||
| Attachments: |
Bug 31937: Fix Patrons::search_unsubscribed - sharpen condition
k Bug 31937: Fix Patrons::search_unsubscribed - sharpen condition Bug 31937: Fix Patrons::search_unsubscribed - sharpen condition |
||
Nothing better than being hit by your own development :) We need to refine the condition of search_unsubscribed in cleanup_database. I added a lot of refusals for another consent type (still customization), but they were picked up nicely by cleanup_database :) So no more casualties expected after all.. Created attachment 142712 [details] [review] Bug 31937: Fix Patrons::search_unsubscribed - sharpen condition The condition is fine as long as we only have GDPR consents. But if you dont, you would have trouble. I know :) Lets prevent that here, although the table still has an ENUM. So double safety. Test plan: Run t/db_dependent/Koha/Patrons.t Bonus: Run cleanup_database.pl and check for unusual number of locked accounts: misc/cronjobs/cleanup_database.pl --confirm -v --sessions Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Note for QA: I did explicitly leave this on bug, not enh. Since it does not hurt to backport it too. (In reply to Marcel de Rooy from comment #0) > The first run of cleanupdatabase after the upgrade to 21.11 did indeed > cleanup a lot ;) > It seems that this statement > my $expired_patrons = Koha::Patrons->filter_by_expiration_date({ days => > $lock_days })->search({ login_attempts => { '!=' => -1 } }); > > works different than before. It must have selected patrons that had an empty > dateexpiry in 20.11 ? In order to be complete, this comment was not the cause. See comment1. Created attachment 143979 [details] [review] k Created attachment 143980 [details] [review] Bug 31937: Fix Patrons::search_unsubscribed - sharpen condition The condition is fine as long as we only have GDPR consents. But if you dont, you would have trouble. I know :) Lets prevent that here, although the table still has an ENUM. So double safety. Test plan: Run t/db_dependent/Koha/Patrons.t Bonus: Run cleanup_database.pl and check for unusual number of locked accounts: misc/cronjobs/cleanup_database.pl --confirm -v --sessions Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> (In reply to Katrin Fischer from comment #6) > Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Great. Thx Created attachment 143982 [details] [review] Bug 31937: Fix Patrons::search_unsubscribed - sharpen condition The condition is fine as long as we only have GDPR consents. But if you dont, you would have trouble. I know :) Lets prevent that here, although the table still has an ENUM. So double safety. Test plan: Run t/db_dependent/Koha/Patrons.t Bonus: Run cleanup_database.pl and check for unusual number of locked accounts: misc/cronjobs/cleanup_database.pl --confirm -v --sessions Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> Pushed to master for 22.11. Nice work everyone, thanks! |
The first run of cleanupdatabase after the upgrade to 21.11 did indeed cleanup a lot ;) It seems that this statement my $expired_patrons = Koha::Patrons->filter_by_expiration_date({ days => $lock_days })->search({ login_attempts => { '!=' => -1 } }); works different than before. It must have selected patrons that had an empty dateexpiry in 20.11 ?