| Summary: | Hold expiration date could be in the past | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Sophie MEYNIEUX <sophie.meynieux> |
| Component: | Hold requests | Assignee: | Bugs List <koha-bugs> |
| Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
| Severity: | normal | ||
| Priority: | P5 - low | CC: | e.betemps, gmcharlt, jheltibridle, josef.moravec, sally.healey |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| GIT URL: | Initiative type: | --- | |
| Sponsorship status: | --- | Comma delimited list of Sponsors: | |
| Crowdfunding goal: | 0 | Patch complexity: | --- |
| Documentation contact: | Documentation submission: | ||
| Text to go in the release notes: | Version(s) released in: | ||
| Circulation function: | |||
|
Description
Sophie MEYNIEUX
2019-03-25 13:29:09 UTC
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. |