https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39532
Katrin Fischer <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #8 from Katrin Fischer <[email protected]> --- (In reply to Kyle M Hall (khall) from comment #7) > > As I see it running this scripts will just overwrite any existing SUSPENSION > > restriction with a date provided in the script when run. It feels to risky > > especially as a change in behavior that might not be noticed in time. > > That is actually a feature of the SUSPENSION restriction. It's a singleton > that should be updated to the longer of the new date or the existing date ( > if there is one ). This is its very purpose. Yes, I am aware, but I will we are mixing use cases here that are different and we might "disturb" the original use of SUSPENSION with this feature. Say we have a library system with mulitple branches. Some use the fine in days feature that sets the SUSPENSION restriction on checkin for overdue items. Some use fines (only for those the CLI script would be interesting) OR: we have one library, that has some item types they charge fines for and fine days for others. They run the script and it will overwrite the existing time limited SUSPENSION to be indefinite. What happens if more overdue items are returned that would add days to that indefinite suspension? Do libraries really expect the time limited SUSPENSION to be turned into INDEFINITE? I agree that you need a unique restriction type here to avoid the repeat restrictions. I just argue against re-using the existing SUSPENSION. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
