Uploaded image for project: 'mod-circulation-storage'
  1. mod-circulation-storage
  2. CIRCSTORE-133

Request Expiration Job Takes Too Long for Short Term Expiry Periods

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Closed (View Workflow)
    • Priority: P3
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 8.1.0
    • Labels:
    • Template:
    • Sprint:
      Core: F - Sprint 63, EPAM-Veg Sprint 16
    • Story Points:
      2
    • Development Team:
      Vega

      Description

      Overview:

      • 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:

      1. 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
      2. Thoughts on best way to solve this issue?

      Context:

      • 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 CIRC-194
      • The story for the request expiration job that changes the request status was CIRCSTORE-109
      • 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)

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                kostyantyn-kh Kostyantyn Khodarev
                Reporter:
                cboerema Cate Boerema
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    TestRail: Runs

                      TestRail: Cases