If a library has the system preference, ExpireReservesonHolidays set to Don't Allow - and a library has set their calendar to have the day the hold is set to expire as a holiday, the hold will still show the date the library is closed as the expiration date. The calendar is not being considered although the system preference says to obey the calendar. This was found in Koha version 17.11.07, 17.11.10 and in 18.05.02.
This expiration date is set when the item has been changed to waiting. Steps: 1. System preference : expirereservesonholidays to DON't Allow 2. Make sure the Koha calendar is closed on the day the item will expire if triggered today. 3. Place a hold on a item and check it in to trigger the hold to Waiting. 4. See that the waiting hold date is the date the Koha calendar has indicated as being closed.
IIRC this is only used by the cronjob, it won't cancel when the library is closed. Have you checked ExcludeHolidaysFromMaxPickUpDelay?
Yes Katrin that would be a good system preference to use for a work around, however, if the library does not want to give the patron all the days they are closed included in their reservesmaxpickupdelay Although the cron does not remove the hold, it is misleading to the staff to see that a hold "could" cancel on a day that the library is actually closed. This date is also shown in the OPAC to display the patron when their hold has expired.
So maybe we should remove ExpireReservesOnHolidays and add a third option to ExcludeHolidaysFromMaxPickupDelay, making things work like useDaysMode?
Yes Katrin, that is a great idea! Giving them ALL the options!
(In reply to Katrin Fischer from comment #4) > So maybe we should remove ExpireReservesOnHolidays and add a third option to > ExcludeHolidaysFromMaxPickupDelay, making things work like useDaysMode? +1 on this, ExcludeHolidaysFromMaxPickupDelay should have a "push to the next open day" option.