Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.


NoTitle / Key

Who entered (optional)

DescriptionOpen questionsCovered by edge:patron

Rank

Tickets, facts and comments by the investigatorsPriority item
1UUID 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)

Cornell: R4



2OAuthWhen the discovery system needs to handle with institutional accounts which are different from the accounts within FOLIO (library accounts), OAuth is the proper way to empower the discovery system as broker.
May easily extended by an wrapper. (e.g. with SSO / Shibboleth as authorization server


3SSO / 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.


Björn Muschall: not only a matching point (ID) ist needed but Folio should act as shibboleth service provider like the Doscovery layer itself.

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.

4Authenticate user (with HRID and password)Patron should be authenticated against egde-patron using HRID and password. Currently only possible using OKAPI's /authn/login endpoint

GBV: R1

New topic  , to be discussed


5Select 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)

GBV: R3

Possibly related to

At Cornell, we provide a list of pickup locations for the user to select from, based on a lookup of service points in FOLIO, then submit the selected UUID as part of the request.


6View 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
Cornell: R4

See line in this table "Human-readable pickup locations in patrons existing requests"

n
7View 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 missingCornell: R4

KG: Number of renewals -

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-2758

n
8View 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
9Cancel existing requests

Patrons should be able to cancel pending delivery requests.


GBV: Possible with edge-patronCornell: R3
nn
10Display number of renewals left for an itemMatt 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

Cornell: R4

Laura: R4

GBV: R3

KG: Number of renewals -

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-2758

y
11Indicate 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:

  • patron is locked
  • the maximum number of renewals is reached


Chalmers: R2 

Laura: R2/R1

GBV: R3

KG: Maybe handle by -

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-2758
and also a requirement to improve error messaging for patron blocks. 

Chalmers: See "Granular error messages" below.

y
12Human-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

Cornell: R4

Laura: R2

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

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-2756
? Maybe translation can be handle by the discovery/opac layer provider? 

y
13

Course reserves






14Trending itemsmoved to Brainstorm page for the courses interface




15Proxy supportLower 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

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-3930
?


16Title v. Item Level Requestsjmulvaney@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

Cornell: R4

17"Batch" Requestjmulvaney@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


18Batch Renewaljmulvaney@library.umass.edu Patrons should be able to renew multiple loans in a single actionHigh prio

Chalmers: R3

Cornell: R4

Laura: R4

KG: Need to outlines some use cases and under avg number of loans / extreme cases

  • Batch size? 
  • Handling successful/unsuccessful renewal 
  • Understand happy path 
  • Understand edge cases 
  • What to inform OPAC/Discovery layers ?
  • Or evaluate making parallel calls rather than batch
y
19Batch CancelingPatrons should be able to cancel multiple holds in a single action

Cornell: R4

20Check Out/Renewal via Terminalsjmulvaney@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'.
For self-check station there exists edge/mod_sip2



KG: It appears renew is not supported -

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keySIP2-121
  


21

Hold shelf expiration date

Patron should be able to see hold shelf expiration date for a request that is awaiting pickup. 

Chalmers: R1

Cornell: R4

Laura: 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).
"
holdShelfExpirationDate" is in requests API

y
22Change pickup locationPatron should be able to change pickup location for an open request.


KG: Would need a PUT endpoint... and a feature for prioritization. 
23Granular error messages

Patron should understand what went wrong. There are a number of different use cases.

Uwe: Collection of examples:

  • Patron is locked
  • Patron is partly locked
  • no renewal because of the item is recalled
  • no renew because the maximum no of renewals is reached
  • no recall because the items recall queue is full
  • ...
  • technical issues, "try later"
  • ...


Chalmers: R2

Cornell: R4

Laura: R3


KG: There maybe opportunities to improve messaging probably need 

  • A feature to investigate which messaging can be improved by FOLIO 
  • Implement issues.folio.org/browse/UXPROD-2422?
  • Implement
    Jira Legacy
    serverSystem JiraJIRA
    serverId01505d01-b853-3c2e-90f1-ee9b165564fc
    keyUXPROD-2758
    ?
  • It will still be up to the discovery/opac provider to expose this information. 

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
24Patron 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

Laura: R4

GBV: R2

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

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyEDGPATRON-104
?

y
25Patron block

Patron should be able to see if they have a patron block.
(The field "Message to patron" could be shown.)

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?



GBV: R3KG: Seems reasonable to return this information in the GET patron response. 
26Change patron infoPatron should be able to edit selected information, e.g. email address.

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

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyEDGPATRON-104
?



27Patron 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. )




28Delivery request supportPatron interface should support delivery requests (indicate whether the patron is enabled for delivery, list their available delivery addresses, and know their default)

Chalmers: R5

Laura: R5


 KG:

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyUXPROD-3646
?

(y)
29Set/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

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODUSERS-254

BM: However,

Jira Legacy
serverSystem JiraJIRA
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keySIP2-89
which should apply/use this field via SIP2 still open.

Authenticate user (with HRID and password)Patron should be authenticated against egde-patron using HRID and password

.

Currently only possible using OKAPI's /authn/login endpoint
GBV: R1

New topic  , to be discussed