When an item is returned, if it was reserved, reservation status is set to W and expiration date is calculated. But if the hold already had an expiration date, this one is kept (why ?) if it is prior to the one calculated, without controlling if it is already past. This can lead to have an expiration date prior to waiting date.
If it has already an expiration date that would have been set by the patron when starting the hold 'not needed after...'. So actually the patron indicated they no longer need it... I wonder if those shoudl not be set to waiting but move on to the next patron immediately?
It seems that expiration date is also set when hold is suspended and not recalculated when item is finally set "waiting for pickup"
Our holds are canceled by a cron if the expiration date is in the past, so this problem does not affect us in that way. But if a patron has chosen to set a "not needed after.." date, they often mean that they don't want it if it hasn't been placed on the hold shelf by that date, but they still want the 7 days to pick it up if it has been moved to waiting by that date. So we are seeing holds that are scanned in at our library and have an expiration date that is shorter than the 7 days we have set for our ReservesMaxPickUpDelay.
We now have separate fields for the pickup expiration date and the patron set 'not needed after: | expirationdate | date | YES | | NULL | patron_expiration_date | date | YES | | NULL So things have changed here. I believe this to be fixed.