[offsiteReq] Determine which combination(s) of Sierra fields:value indicates that an item is held at DeepStore

[agnesgaroux]

RFC

Identifiers for collections held at Deepstore

Manual requests process: examples

Wellcome Collection access policy

[agnesgaroux]

DeepStore items requesting

What we’re trying to do: find a reliable way to tell whether an item can be requested online, and when the 1st available day to view it will be

NOTE ⚠️ after this was posted on Slack #wc-offsite-requesting, it turned out that this not how we're going to do it. Keeping this here anyway, for posterity? but see next comment for new approach

1. The website needs correct/valid values to display for the items' Location, Status and Access + a way to decide whether to show the "Request item" button (the latter probably being a combination of the former's values)
2. When a user clicks the "Request item" button, the backend (itemsAPI) needs to find out whether the item is stored on site or at DeepStore so it can calculate when the 1st available day to view the item will be.

I'm going to address 2. first, as it's a more self-contained issue:

Currently one category of items can be requested online: those where the item’s access condition method (aka “OPACSMG”) is “online-request” AND the access condition status is “open”, “open-with-advisory” or “restricted”
For these items the 1st available date is the next day if the time is before 10am, the day after that if it’s after 10am.

We want to add another category of items that can be requested online: the items that have been moved to DeepStore.
The request process will be the same as above from a user’s perspective, except the 1st available date will be 10 days from the day the request is made.

The items that have already been moved to DeepStore ALL have the location name “Closed stores Arch. & MSS” (aka location.code: scmac)
However we cannot rely on this location name/code to ascertain that an item is at DeepStore, because NOT ALL items that have this location name/code are in fact at DeepStore. Therefore we need to look at something else: refNumber starting with SA/HEC
We have to look at both the location name/code AND the refNumber, because NOT ALL refNumber starting with SA/HEC are requestable. Eight of them have the location.name “Unrequestable Arch. & MSS” (location.code: sc#ac) which, I assume, means they cannot be requested.

Therefore, when an item’s access condition status is “open”, “open-with-advisory” or “restricted”:

• If its access conditions method (OPACSMG) is “online-request”, it will be available to view tomorrow or the day after, depending on the time of day
• If its location code is scmac AND its refNumber starts with SA/HEC, it will be available to view in 10 days

[agnesgaroux]

Source data update

The CALM/Sierra records for DeepStore items are going to be updated:

• the OPACSMG will become “online-request"
• the location code will become "harop" (for requestable DeepStore items. Non-requestable DeepStore items will get a different location code: harcl)
• the location label is still TBD. Working title: "Offsite Closed Stores requestable Deepstore Archives" (bit of a mouthful but it needs to be descriptive enough for Collection staff to know exactly what it refers to)

[agnesgaroux]

As far as the itemsAPI is concerned

-> pull in the item's location code from Sierra when we get its access conditions here then use it to figure out whether it's DeepStore (harop) or onsite (any other location code)
❓I don't think the location code should be part of the DisplayAccessCondition since it's not something we want to display on the work page. We could include it and let wc.org ignore it, or refactor updateItems so that it handles items one by one which I believe would keep things are bit cleaner. OTOH that would mean making multiple calls to Sierra rather than a bulk one with all the items as is the case now

-> there will be some slight complication around the available dates after the first

• first available date is dependent on DeppStore working days. Alexandra confirmed it's any day other than Saturdays, Sundays and public holidays
• the following days are dependent on the library opening days: once the item is onsite it can be viewed in the library any day it is open

[agnesgaroux]

As far as the catalogue-pipeline is concerned:

• the item's status will still come from the same Sierra field, will simply change from "by appointment" to either “open”, “open-with-advisory” or “restricted”
• the item's access will still come from the same Sierra field, will simply change from "manual request" to "online request"
• the item's location will need some code change here to set the location type to "Offsite" based on a TBD location label/name in Sierra that will be used for DeepStore items (matched with harop location code)

⚠️ Once the catalogue-pipeline indexes an item with "online-request" access condition method, wc.org will show the Request item button so that can't happen until the itemAPI can handle DeepStore items

❓would it be sensible to use the location name "offsite" as a safeguard/condition for a toggle on the work page?

• toggle off: if the item is online-request and the location is offsite, it's not requestable
• toggle on: if the item is online-request and the location is offsite, make it requestable
  This would allow us to test + will keep offsite items from being requestable by the public before we're ready to go

[agnesgaroux]

Catching up with Tony Hardy next week to find out more about the source data update mentioned above