What's needed to empower a patron to perform his allowed actions and to maintain his account in a discovery system.
This intended as a unstructured collection of needs, wishes, use cases, etc.
Please add any thoughts. Don't care about duplicates or potential already supported functions.
In the upcoming discussion it's much easier to drop a point than to find a missing one.
| Title / Key | Who entered (optional) | Description | Open questions | Covered by edge:patron | Tickets, facts and comments by the investigators | Priority item | |
|---|---|---|---|---|---|---|---|
| UUID vs. HRID | The Discovery system might have to operate with the HRIDs instead of UUIDs. To support this, the interface should be able to handle UUIDs and HRIDs | Query: GBV: Calling edge-patron using the patron’s HRID is possible. (Documentation seems to be stale) Response: Instanceid and itemid are only provided as UUID | Demian: R2 (VuFind would be less efficient/flexible without this capability) | ||||
| May easily extended by an wrapper. (e.g. with SSO / Shibboleth as authorization server | |||||||
| SSO / Shibboleth | Institutions that use SSO / Shibboleth to facilitate login to university services need FOLIO to be able to provide appropriate information to the discovery system so that a patron can authenticate to their account.
| Uwe: How could a patron interface support this? from Erin: FOLIO needs to provide a match point (username, externalId) that can be used to know that the SSO account being signed into corresponds to a particular FOLIO user account | |||||
| Select a pickup location | When placing an request or an hold the patron should be able to select a preferred location to pickup the item. | GBV: One service point’s UUID can be included in the POST request to edge-patron when placing a hold. Getting all available service points is not possible Uwe: The list of available locations (by Item) should be provided by rtac. | Demian: R1 (VuFind can't present pickup locations without a list – of course, it could cheat and use Okapi, but if we want EDGE-only requests, we need this) | Possibly related to | |||
| View existing requests | Patrons should be able to view information about existing item- and title-level requests, including status and place in line (queue number) | GBV: Hold information given by edge-patron includes requestDate, expirationDate, status, queuePosition, pickupLocationId. RequestType and name of the pickupLocation are missing and possibly some more | See line in this table "Human-readable pickup locations in patrons existing requests" | n | |||
| View existing charged items | Patrons should be able to view information about items they have checked out (due date, title, author, etc.). | GBV: Possible with edge-patron. Information of the number of renewals left missing | KG: Number of renewals - UXPROD-2758 - Getting issue details... STATUS | n | |||
| View existing fines (paid and unpaid) | Patrons should be able to view information about their fine history - paid and unpaid fines that are on their account. | GBV: Possible with edge-patron | n | ||||
| Cancel existing requests | Patrons should be able to cancel pending delivery requests. | GBV: Possible with edge-patron | n | ||||
| Display number of renewals left for an item | Matt Connolly | Patrons should be able to see an indication of the number of renewals left for an item | GBV: Renewal possible, answer includes new dueDate, not the number of renewals left Need to be aware that the loan policy (where number of renewals allowed lives) is re-fetched when the user attempts to renew the loan. It’s possible it would not be the same as the value currently stored on the loan. | Chalmers: R3 | KG: Number of renewals - UXPROD-2758 - Getting issue details... STATUS | y | |
| Indicate items that can't be renewed | If an item in a patron's account can't be renewed, it would be helpful to indicate that fact and the reason why (e.g., another patron has recalled it). Uwe: Other possible reasons could be:
| Chalmers: R2 | KG: Maybe handle by - UXPROD-2758 - Getting issue details... STATUS and also a requirement to improve error messaging for patron blocks. Chalmers: See "Granular error messages" below. | y | |||
| Human-readable pickup locations | If a requested item is available for pickup, the patron should be able to see pickup location for a request. The display name of the pickup location should be also provided. (Currently this requires an additional API call to translate UUID into location name via the service-points API.) | Can this be done in multiple languages (i.e. "Front desk" would be different in a language other than English) or are there Folio limitations that would prevent this currently? | Folio has only one textfield for service points/ locations GBV: UUID is included in request information, description is missing | Chalmers: R1 | Not the same as The point is to avoid an additional call to lookup a string representation for the pick up point on an existing request KG: Maybe related to UXPROD-2756 - Getting issue details... STATUS ? Maybe translation can be handle by the discovery/opac layer provider? | y | |
Course reserves | |||||||
| Trending items | moved to Brainstorm page for the courses interface | ||||||
| Proxy support | Lower priority - a discovery layer should recognize if someone has a proxy relationship to another user, and if so, provide information about that proxy relationship. | Uwe: how could this be supported by mod_parton? | KG: Maybe related to UXPROD-3930 - Getting issue details... STATUS ? | ||||
| Title v. Item Level Requests | jmulvaney@library.umass.edu | Patrons should be able to request specific FOLIO items (ie. a specific vol./issue) as well as the "first available" (ie. if you hold multiple copies of the same titles) | https://github.com/vufind-org/vufind/pull/2479 Morning Glory | ||||
| "Batch" Request | jmulvaney@library.umass.edu | Patrons should be able to request multiple FOLIO items on a record at once (ie. for serials or multi-part monos) | Uwe: Seems to be supported | ||||
| Batch Renewal | jmulvaney@library.umass.edu | Patrons should be able to renew multiple loans in a single action | High prio | Chalmers: R3 | KG: Need to outlines some use cases and under avg number of loans / extreme cases
| y | |
| Batch Canceling | Patrons should be able to cancel multiple holds in a single action | ||||||
| Check Out/Renewal via Terminals | jmulvaney@library.umass.edu | Patrons should be able to check out and renew items via a self service terminal (self-check station) | Uwe: Did i got this wrong? For me, this seems not to be 'Discovery system'. | KG: It appears renew is not supported - SIP2-121 - Getting issue details... STATUS | |||
Hold shelf expiration date | Patron should be able to see hold shelf expiration date for a request that is awaiting pickup. | Chalmers: R1 | KG: This information is available in the edge-patron GET patron details response. A support ticket should be created for applicable OPAC/Discovery provider. See below code snippet "expirationDate": { "type": "string", "format": "date-time", "description": "The date when the request expires" }, https://s3.amazonaws.com/foliodocs/api/edge-patron/r/edge-patron.html#patron_account__id__get Marie: There are two different expiration dates handled by a request. We need the Hold shelf expiration date exposed for a book awaiting pick up (the last day to pick up from hold shelf). If I'm not mistaken, "expirationDate" is the request expiration date (the date after which the patron does not find the request interesting anymore). | y | |||
| Change pickup location | Patron should be able to change pickup location for an open request. | KG: Would need a PUT endpoint... and a feature for prioritization. | |||||
| Granular error messages | Patron should understand what went wrong. There are a number of different use cases. Uwe: Collection of examples:
| Chalmers: R2 | KG: There maybe opportunities to improve messaging probably need
Chalmers: For us it's partly solved in classic EDS by using a middleware with mapping of error messages, but we would prefer to handle the messages using APIs. We worked with Magda Z on this a couple of years ago and have some examples in this document (updated 2020) | y | |||
| Patron info | Show patron contact information and other info so patron can see if we hold out-of-date info about them. Björn Muschall: Also administrative patron information like patron group is important for limitations/scopes on particular services (permission). | Chalmers: R4 | KG: I think this item requires a conversation with SME/PO that is familiar with authentication. Also a conversation with discovery providers. BTW - does anyone know the status of EDGPATRON-104 - Getting issue details... STATUS ? | y | |||
| Patron block | Patron should be able to see if they have a patron block. Björn Muschall: Patron block is also used as indicator whether a user is allowed to log in to his/her account or not (including reason why not) | Uwe: Including the reason? | KG: Seems reasonable to return this information in the GET patron response. | ||||
| Change patron info | Patron should be able to edit selected information, e.g. email address. | KG: I think this item requires a conversation with SME/PO that is familiar with authentication. Also a conversation with discovery providers. BTW - does anyone know the status of EDGPATRON-104 - Getting issue details... STATUS ? | |||||
| Patron alias / anonymous request identifier | Patron should be able to see their anonymous request identifier that they need to look for at the hold shelf when they pick up their request. (When UXPROD-2435 / the Anonymized ID token- part of UXPROD-1830 is implemented. ) | ||||||
| Delivery request support | Patron interface should support delivery requests (indicate whether the patron is enabled for delivery, list their available delivery addresses, and know their default) | Chalmers: R5 | KG: UXPROD-3646 - Getting issue details... STATUS ? | (y) | |||
| Set/Change PIN (SIP2 self-checkout, lending kiosk) | Patron should be able to initially set and change SIP2 PIN via Discovery account interface. | Isn't this a subtopic of 'Change patron info' | BM: SIP2 PIN field implemented in MODUSERS-254 - Getting issue details... STATUS BM: However, SIP2-89 - Getting issue details... STATUS which should apply/use this field via SIP2 still open. |