https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |martin.renvoize@openfifth.c |ity.org |o.uk -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 --- Comment #1 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 199157 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=199157&action=edit Bug 42608: Stop hold pickup expiration from week-jumping over closures Koha::Hold::set_waiting calls Koha::Calendar::days_forward to derive the holds-shelf expiration date when ExcludeHolidaysFromMaxPickUpDelay is on. days_forward iterated next_open_days($dt, 1) ReservesMaxPickUpDelay times, and next_open_days consults get_push_amt for every closed day it encounters. Under useDaysMode=Dayweek, get_push_amt returns 7 for any closure that is not a permanently closed weekday -- so an intermediate Bank Holiday Monday inside the pickup window pushed the cursor a whole week forward instead of one day, inflating the expiration by seven days. Dayweek is a loan-due-date concept: it exists to keep a Friday-due loan due on a Friday across closures. A patron does not pick a weekday for a hold-shelf collection; staff set the expiration when they trap the item, and the only thing that should drive it is how many open days the patron should have to come and collect. days_forward is now decoupled from useDaysMode and always counts forward one open day at a time, ignoring closures without consuming them from the count. next_open_days, prev_open_days, get_push_amt and addDays are unchanged -- loan due-date math keeps the existing Dayweek behaviour. Test plan: 1. Inside KTD, run the updated unit tests: prove t/db_dependent/Calendar.t prove t/db_dependent/Hold.t Confirm both pass, including the new Bug 42608 sub-tests. 2. Manual reproduction: - Set sysprefs: useDaysMode=Dayweek, ReservesMaxPickUpDelay=6, ExcludeHolidaysFromMaxPickUpDelay=ON, ExpireReservesOnHolidays=ON. - On a branch, mark Sundays as a weekly closure and add a single holiday on Monday 2026-05-04. - Trap five holds to waiting at that branch with waitingdates 2026-04-27 through 2026-05-01. - Without the patch: expirationdates are 2026-05-11, 2026-05-12, 2026-05-13, 2026-05-14, 2026-05-15 (all +14 calendar days). - With the patch: expirationdates are 2026-05-05, 2026-05-06, 2026-05-07, 2026-05-08, 2026-05-09 (giving the patron 6 open days in every case, skipping Sun 3 May and Mon 4 May). 3. Verify the existing Calendar mode behaviour is unchanged: - Switch useDaysMode to Calendar and repeat step 2 -- the same expected expirationdates should apply. 4. Verify loan due-date behaviour is unchanged: - With useDaysMode=Dayweek, issue an item with a loan period that places its due date on Mon 2026-05-04. Confirm the due date rolls forward by a whole week (the original Dayweek intent), proving this patch did not regress addDays/addDuration. Sponsored-by: OpenFifth <https://openfifth.co.uk/> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #199157|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 --- Comment #3 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- I've got test failures here: * Proving /kohadevbox/koha/t/db_dependent/Calendar.t FAIL # Looks like you planned 9 tests but ran 4. # Failed test 'days_forward' # at /kohadevbox/koha/t/db_dependent/Calendar.t line 512. DBIx::Class::Schema::source(): Can't find source for RepeatableHoliday at /kohadevbox/koha/t/db_dependent/Calendar.t line 460 # Looks like your test exited with 11 just after 3. /kohadevbox/koha/t/db_dependent/Calendar.t .. Dubious, test returned 11 (wstat 2816, 0xb00) Failed 6/8 subtests Test Summary Report ------------------- /kohadevbox/koha/t/db_dependent/Calendar.t (Wstat: 2816 (exited 11) Tests: 3 Failed: 1) Failed test: 2 Non-zero exit status: 11 Parse errors: Bad plan. You planned 8 tests but ran 3. Files=1, Tests=3, 2 wallclock secs ( 0.00 usr 0.00 sys + 0.93 cusr 0.10 csys = 1.03 CPU) Result: FAIL * Proving /kohadevbox/koha/t/db_dependent/Hold.t FAIL # No tests run! # Failed test 'No tests run for subtest "expirationdate over a Bank Holiday with useDaysMode=Dayweek"' # at /kohadevbox/koha/t/db_dependent/Hold.t line 403. # Looks like you failed 1 test of 3. # Failed test 'set_waiting() tests' # at /kohadevbox/koha/t/db_dependent/Hold.t line 406. DBIx::Class::Schema::source(): Can't find source for RepeatableHoliday at /kohadevbox/koha/t/db_dependent/Hold.t line 352 # Looks like your test exited with 11 just after 34. /kohadevbox/koha/t/db_dependent/Hold.t .. Dubious, test returned 11 (wstat 2816, 0xb00) Failed 3/36 subtests Test Summary Report ------------------- /kohadevbox/koha/t/db_dependent/Hold.t (Wstat: 2816 (exited 11) Tests: 34 Failed: 1) Failed test: 33 Non-zero exit status: 11 Parse errors: Bad plan. You planned 36 tests but ran 34. Files=1, Tests=34, 1 wallclock secs ( 0.01 usr 0.00 sys + 1.47 cusr 0.18 csys = 1.66 CPU) Result: FAIL -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 --- Comment #4 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 206182 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206182&action=edit Bug 42608: Stop hold pickup expiration from week-jumping over closures Koha::Hold::set_waiting calls Koha::Calendar::days_forward to derive the holds-shelf expiration date when ExcludeHolidaysFromMaxPickUpDelay is on. days_forward iterated next_open_days($dt, 1) ReservesMaxPickUpDelay times, and next_open_days consults get_push_amt for every closed day it encounters. Under useDaysMode=Dayweek, get_push_amt returns 7 for any closure that is not a permanently closed weekday -- so an intermediate Bank Holiday Monday inside the pickup window pushed the cursor a whole week forward instead of one day, inflating the expiration by seven days. Dayweek is a loan-due-date concept: it exists to keep a Friday-due loan due on a Friday across closures. A patron does not pick a weekday for a hold-shelf collection; staff set the expiration when they trap the item, and the only thing that should drive it is how many open days the patron should have to come and collect. days_forward is now decoupled from useDaysMode and always counts forward one open day at a time, ignoring closures without consuming them from the count. next_open_days, prev_open_days, get_push_amt and addDays are unchanged -- loan due-date math keeps the existing Dayweek behaviour. Test plan: 1. Inside KTD, run the updated unit tests: prove t/db_dependent/Calendar.t prove t/db_dependent/Hold.t Confirm both pass, including the new Bug 42608 sub-tests. These cover the full matrix of starting weekdays and useDaysMode values; the manual steps below are a single confirmatory pass through the UI. 2. Manual reproduction (UI only -- no database or CLI access needed): - Set sysprefs: useDaysMode=Dayweek, ReservesMaxPickUpDelay=6, ExcludeHolidaysFromMaxPickUpDelay=ON, ExpireReservesOnHolidays=ON. - Administration > Calendar: on a test branch, add one single (one-time) holiday -- not weekly/repeating -- on any weekday within the next 6 days that isn't already closed (e.g. the day after tomorrow, as long as it isn't a Sunday or other closed day). This one-off closure inside the pickup window is what triggers the bug. - Place a hold on an available item, then check the item in at that branch and confirm/trap it. This stamps waitingdate with today's date automatically -- no manual date entry required. - Check the hold's expiration date (Holds awaiting pickup list, or the patron's holds tab): Without the fix: expiration lands a full 7 days later than it should (today + 6 + 7), from the week-jump. With the fix: expiration is today + 6 open days, only skipping the one closed day. 3. Verify the existing Calendar mode behaviour is unchanged: - Switch useDaysMode to Calendar and repeat step 2 -- the same expected expiration date should apply. 4. Verify loan due-date behaviour is unchanged: - With useDaysMode=Dayweek, check out an item whose loan period would place its due date on the same closed day used in step 2. Confirm the due date still rolls forward by a whole week (the original Dayweek intent), proving this patch did not regress addDays/addDuration. Sponsored-by: OpenFifth <https://openfifth.co.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 Andrew Fuerste-Henry <andrew@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 --- Comment #6 from Andrew Fuerste-Henry <andrew@bywatersolutions.com> --- Created attachment 206197 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=206197&action=edit Bug 42608: Stop hold pickup expiration from week-jumping over closures Koha::Hold::set_waiting calls Koha::Calendar::days_forward to derive the holds-shelf expiration date when ExcludeHolidaysFromMaxPickUpDelay is on. days_forward iterated next_open_days($dt, 1) ReservesMaxPickUpDelay times, and next_open_days consults get_push_amt for every closed day it encounters. Under useDaysMode=Dayweek, get_push_amt returns 7 for any closure that is not a permanently closed weekday -- so an intermediate Bank Holiday Monday inside the pickup window pushed the cursor a whole week forward instead of one day, inflating the expiration by seven days. Dayweek is a loan-due-date concept: it exists to keep a Friday-due loan due on a Friday across closures. A patron does not pick a weekday for a hold-shelf collection; staff set the expiration when they trap the item, and the only thing that should drive it is how many open days the patron should have to come and collect. days_forward is now decoupled from useDaysMode and always counts forward one open day at a time, ignoring closures without consuming them from the count. next_open_days, prev_open_days, get_push_amt and addDays are unchanged -- loan due-date math keeps the existing Dayweek behaviour. Test plan: 1. Inside KTD, run the updated unit tests: prove t/db_dependent/Calendar.t prove t/db_dependent/Hold.t Confirm both pass, including the new Bug 42608 sub-tests. These cover the full matrix of starting weekdays and useDaysMode values; the manual steps below are a single confirmatory pass through the UI. 2. Manual reproduction (UI only -- no database or CLI access needed): - Set sysprefs: useDaysMode=Dayweek, ReservesMaxPickUpDelay=6, ExcludeHolidaysFromMaxPickUpDelay=ON, ExpireReservesOnHolidays=ON. - Administration > Calendar: on a test branch, add one single (one-time) holiday -- not weekly/repeating -- on any weekday within the next 6 days that isn't already closed (e.g. the day after tomorrow, as long as it isn't a Sunday or other closed day). This one-off closure inside the pickup window is what triggers the bug. - Place a hold on an available item, then check the item in at that branch and confirm/trap it. This stamps waitingdate with today's date automatically -- no manual date entry required. - Check the hold's expiration date (Holds awaiting pickup list, or the patron's holds tab): Without the fix: expiration lands a full 7 days later than it should (today + 6 + 7), from the week-jump. With the fix: expiration is today + 6 open days, only skipping the one closed day. 3. Verify the existing Calendar mode behaviour is unchanged: - Switch useDaysMode to Calendar and repeat step 2 -- the same expected expiration date should apply. 4. Verify loan due-date behaviour is unchanged: - With useDaysMode=Dayweek, check out an item whose loan period would place its due date on the same closed day used in step 2. Confirm the due date still rolls forward by a whole week (the original Dayweek intent), proving this patch did not regress addDays/addDuration. Sponsored-by: OpenFifth <https://openfifth.co.uk/> Signed-off-by: Jackie Usher <jackie.usher@westsussex.gov.uk> Signed-off-by: Andrew Fuerste Henry <andrew@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42608 Pedro Amorim (ammopt) <pedro.amorim@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Pushed to main Version(s)| |26.11.00 released in| | -- You are receiving this mail because: You are watching all bug changes.