Holds are being marked as problematic even before they reach the number of days set in the ReservesMaxPickUpDelay syspref. Library Example: The ReservesMaxPickUpDelay syspref is set to mark holds as problematic at 10 days. Today is August 3rd and yet it is showing holds with expiration dates of August 1st and August 2nd in the Holds Waiting Over 10 days tab at /cgi-bin/koha/circ/waitingreserves.pl
It looks like the holds on that tab are actually just holds that have expired The assumption being that a hold only expires after X days, set by the preference This will not be true if the expiration date is set manually by staff or the patron. Possibly we could just rename the tab to "Holds waiting and expired"
Our staff and customers find this confusing too. I believe Koha did used to consistently give customers the same amount of time (also 10 days in our case) to pick up a hold once it is filled, and folks in our system came to expect that. (I know in theory the expiration date is supposed to mean that the customer doesn't want it at all after that date, but you'd be surprised how many people don't actually use the expiration date that way, no matter how we label it.) Our hold policies are also very lenient in general, so in practice when a hold expires "early", it usually just leads to staff starting the process over with a new hold, which isn't a good use of anyone's time. It would be awesome if this could be a syspref, so that libraries could choose whether they wanted waiting holds to expire after exactly the number of days defined by ReservesMaxPickupDelay, or to expire after whichever comes sooner - ReservesMaxPickupDelay or the manual expiration date.
The display issue here might be fixed by Bug 8367 - How long is a hold waiting for pickup at a more granular level It removes the number from the tab, as with it being in the circulation rules multiple different values might apply. For the timing, I am not sure.
I'm not sure if we should open a new bug or not, but I agree that ReservesMaxPickUpDelay and "Hold not needed after" should be independent, or at least there should be the option to make them independent. I don't know why some customers set expiration dates, but I think this behavior is inconsistent with what most of them actually want. Once a hold is trapped, they expect the normal window of time to pick it up.