Closed agnesgaroux closed 20 hours ago
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”:
The CALM/Sierra records for DeepStore items are going to be updated:
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
As far as the catalogue-pipeline is concerned:
⚠️ 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?
Catching up with Tony Hardy next week to find out more about the source data update mentioned above
RFC
Identifiers for collections held at Deepstore
Manual requests process: examples
Wellcome Collection access policy