Page Comparison

see: https://docs.google.com/document/d/12wsnBM6_8iN0NflpgXFKaWbNZubAtfyCvLqwLAon17A/edit?usp=sharing

Discussion of specific needs are outlined in document above

• Edge Patron API documentation may be incomplete/out of date - states support for only UUID which is not the case, supports external system ID in user records and barcodes.
  • Generally documentation around discovery integrations could be improved
• Need for pulling item level information which is specific to individual libraries for display in discovery systems, not specifically for circulation
  • Pulling HRID through edge_patron would allow this information to display for loaned items in a patron display. Optimum would be to be able to use both UUID and HRID as a way to request data from FOLIO, and for both to also appear in any answer from FOLIO. Currently you can use HRID to call and receive a UUID in response.
    • See Loans Array on edge_patron: Currently instance and item only support UUID - would expanding to include HRID as a response be a more common need?

• • • Question: Is it a lot of development work to include new content in the APIs?
      • Not really difficult, but requires someone to actually develop for the use cases.
      • Uwe hopes to define a "lean" but still complete interface, hoping to collect all requests, prioritize, and then look for development time.
      • Generally adding more information to Edge Patron would not be a lot of effort, as long as we can make a good list.
• Preferred service points
  • Patrons must select a service point every time they make an item request, they cannot currently choose a preferred or default location in the discovery layer
  • Edge_patron POST request for a hold includes the UUID (not HRID) of a pickup location
    • • Uwe: In this case, HRID does not make sense. Because it originates inside of FOLIO, UUID should be sufficient.
  • Where does this intersect with RTAC?
    • When a user wants to make a request for an item, all locations are pulled for any item on the record via Edge RTAC. They should then be able to select a service point (via edge_patron) where they want to pick something up.
      • EBSCO Discovery: Currently the service points are hard coded based on UUID into EDS - this should instead be called out to FOLIO. When requesting, the call should be made for possible service points and then the user makes the choice on what they want.
        • Agreement to avoid hard coding this data into the discovery layers.
    • See holds array > pickupLocationId, this seems like it may be already included
  • Setting default locations per user
    • This should be done inside of FOLIO. Perhaps it should be configurable via mod patron interface, but it is not the most urgent need at this time.
• Loans versus Holds
  • In Edge API there is only reference to holds, but is there a difference between placing a hold and requesting an item which has an active loan?
  • Saphira - there may be people who know the answer but they are not on this call EDIT: mod-patron gets the holds from „/circulation/requests“. Each request there contains a requestType in [Hold, Recall, Page]. So it should be possible to have mod-patron also return the requestType.
  • Question: Is the request to separate page, hold, and recall requests?
    • Uwe: Currently they display separately. Is this really needed? Hearing requests from member libraries for more fine grain information when it comes to arrival dates for requesting - things that come in quickly versus things that take more time (ie. something already on loan).
    • If FOLIO doesn't make the distinction internally, is it possible to make the distinction via edge_patron? There should be some due date displaying on items which are checked out via RTAC and notices could be configured to convey some of this information via page or recall notices.
      • Not everyone has considered this need
• Pickup Location Display
  • Patrons can choose a pickup location, but when they make a request it doesn't actually display which one they chose (at least via EBSCO Discovery) which can lead to confusion and then an expired hold.
  • Edge_patron only includes FOLIO UUID of pickup location - EDS is not currently displaying information. Would require another call to mod API to actually display the data in a human readable way.
  • Having a translation between UUID and human readable text in the layer doesn't seem to be a problem at the moment. Important for language translations to have multiple options, so hard coding this leads to complications. Since FOLIO knows this info edge_patron should be able to call for this info.