- We have hold shelf expiry periods set at the service point.
- They can be set in minutes, hours, days, weeks and months.
- When an item goes into awaiting pickup (for a request), the hold shelf expiration date is set in the request based on this period (it can be overwritten manually in the request record).
- We then have a job the runs about once an hour depending on the environment (apparently it's configurable) that finds newly expired requests and changes their status to "Closed - Pickup expired".
- The problem is that this job might be too slow for requests that are supposed to expire in just one hour (or even 30 minutes).
Questions for developers:
- How quickly can this job be made to run without impacting performance? Note, for expiration periods set at day, week, month, once a day is fine
- Thoughts on best way to solve this issue?
- While expiry periods set in day, week and month are definitely the most common, SMEs do want minutes and hours for things like reserve items and equipment rentals
- That said, if it makes sense to focus on long term and short term expiry periods separately, the SiG has said it is okay to deprioritize the minutes and hour periods for the time being, as long as we make sure it stays in the backlog
- I believe there was some technical advantage to specifying hold shelf expiration as a date/time (because we didn't then need to factor in time zone?) so we should bear that in mind (Marc Johnson would know more about this)
- The setting of the request expiration date story was
- The story for the request expiration job that changes the request status was
- We have some additional follow-up work to be done on request expiration in that we need to have it respect the closed library due dates and times (UIREQ-246)