When using the fines in days feature, the restrictions will be calculated without taking holidays into account. So the restriction can end in the middle of a period the library is closed. To test: - Set finescalendar to 'not including days the library is closed' - Set a circulation condition with no fine/maxfine, but fine days and max fine days instead - Check out an item with a due date in the past - Check the item in and verify the restriction date - Clean the restriction - Add holidays to your calendar on the calculated restriction date - Check the item out again with the same due date in the past - Check in the item again - Verify the calculated restriction end date now is the same and a holiday.
I guess this is a good thing. After discussing this with others we would suggest to make it work with useDaysMode, to be consistent with the library policy for computing return dates.
useDaysMode is used for calculating the due dates and usually not involved in the overdues process. I am not sure it's the right one. Maybe finesCalendar would be a better fit as it's already used to count the days overdue? So it would make sense to use it for determining the suspension date as well. With an update to the description. We could also have a new preference SuspensionCalendar mimicking the behaviour.
Actually looking at Bug 13909 - Suspension days calculation doesn't honour finesCalendar I think finesCalendar would be best. And update the description to say: Calculate fines and suspensions based on days overdue ...
What is the status for this? Is anyone going to work on this for 18.05?
We are looking into it.
Created attachment 74726 [details] [review] Bug 19204: Make the debarment date calculation depends on finesCalendar This patchs adds the ability to calculate the end of the suspension date (debarment date) using the finesCalendar syspref. Prior to this patch it was never calculating without taking into account the calendar. calculated without taking holidays into account. This was a problem because the restriction could end in the middle of a period the library is closed. Test plan: - Set finescalendar to 'not including days the library is closed' - Set a circulation condition with no fine/maxfine, but fine days and max fine days instead - Check out an item with a due date in the past - Check the item in and verify the restriction date - Clean the restriction - Add holidays to your calendar on the calculated restriction date - Check the item out again with the same due date in the past - Check in the item again - Verify the calculated restriction end date has changed, it's set to the day after the holiday. Fines in days restriction calculation is correctly taking calendar into account.
Created attachment 74727 [details] [review] Bug 19204: Clean the tests a bit to reuse the same pattern The same pattern is used several times in test: checkout, checkin, get the debarment, compare the dates and remove the debarment. Let's move that to a separate subroutine
Created attachment 74728 [details] [review] Bug 19204: Add a test: holiday is expiration date
Created attachment 74730 [details] [review] Bug 19204: Add tests for new days_mode parameter
Created attachment 74733 [details] [review] Bug 19204: Make the debarment date calculation depends on finesCalendar This patchs adds the ability to calculate the end of the suspension date (debarment date) using the finesCalendar syspref. Prior to this patch it was never calculating without taking into account the calendar. calculated without taking holidays into account. This was a problem because the restriction could end in the middle of a period the library is closed. Test plan: - Set finescalendar to 'not including days the library is closed' - Set a circulation condition with no fine/maxfine, but fine days and max fine days instead - Check out an item with a due date in the past - Check the item in and verify the restriction date - Clean the restriction - Add holidays to your calendar on the calculated restriction date - Check the item out again with the same due date in the past - Check in the item again - Verify the calculated restriction end date has changed, it's set to the day after the holiday. Fines in days restriction calculation is correctly taking calendar into account. Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Created attachment 74734 [details] [review] Bug 19204: Clean the tests a bit to reuse the same pattern The same pattern is used several times in test: checkout, checkin, get the debarment, compare the dates and remove the debarment. Let's move that to a separate subroutine Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Created attachment 74735 [details] [review] Bug 19204: Add a test: holiday is expiration date Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Created attachment 74736 [details] [review] Bug 19204: Add tests for new days_mode parameter Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de>
Created attachment 74777 [details] [review] Bug 19204: Make the debarment date calculation depends on finesCalendar This patchs adds the ability to calculate the end of the suspension date (debarment date) using the finesCalendar syspref. Prior to this patch it was never calculating without taking into account the calendar. calculated without taking holidays into account. This was a problem because the restriction could end in the middle of a period the library is closed. Test plan: - Set finescalendar to 'not including days the library is closed' - Set a circulation condition with no fine/maxfine, but fine days and max fine days instead - Check out an item with a due date in the past - Check the item in and verify the restriction date - Clean the restriction - Add holidays to your calendar on the calculated restriction date - Check the item out again with the same due date in the past - Check in the item again - Verify the calculated restriction end date has changed, it's set to the day after the holiday. Fines in days restriction calculation is correctly taking calendar into account. Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 74778 [details] [review] Bug 19204: Clean the tests a bit to reuse the same pattern The same pattern is used several times in test: checkout, checkin, get the debarment, compare the dates and remove the debarment. Let's move that to a separate subroutine Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 74779 [details] [review] Bug 19204: Add a test: holiday is expiration date Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 74780 [details] [review] Bug 19204: Add tests for new days_mode parameter Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Won't QA this (conflict of interest) - can someone else please take a look?
Created attachment 74798 [details] [review] Bug 19204: Make the debarment date calculation depends on finesCalendar This patchs adds the ability to calculate the end of the suspension date (debarment date) using the finesCalendar syspref. Prior to this patch it was never calculating without taking into account the calendar. calculated without taking holidays into account. This was a problem because the restriction could end in the middle of a period the library is closed. Test plan: - Set finescalendar to 'not including days the library is closed' - Set a circulation condition with no fine/maxfine, but fine days and max fine days instead - Check out an item with a due date in the past - Check the item in and verify the restriction date - Clean the restriction - Add holidays to your calendar on the calculated restriction date - Check the item out again with the same due date in the past - Check in the item again - Verify the calculated restriction end date has changed, it's set to the day after the holiday. Fines in days restriction calculation is correctly taking calendar into account. Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 74799 [details] [review] Bug 19204: Clean the tests a bit to reuse the same pattern The same pattern is used several times in test: checkout, checkin, get the debarment, compare the dates and remove the debarment. Let's move that to a separate subroutine Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 74800 [details] [review] Bug 19204: Add a test: holiday is expiration date Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 74801 [details] [review] Bug 19204: Add tests for new days_mode parameter Signed-off-by: Claire Gravely <claire.gravely@bsz-bw.de> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de> Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Hi Jonathan, can you please add a Sponsored-by line before pushing? This was sponsored by the Goethe-Intsitut.
Without typo: Goethe-Institut
Pushed to master for 18.05, thanks to everybody involved!