What's needed to display proper actions(buttons) and information to an item 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 _(optional)	Description	Open questions	Rank	Tickets, facts and comments by the investigators	Priority item?
1	Individual availability (Availability in different contexts)	Uwe Reh	Different media types have different types of availability. To respect this, this availability should only published with the context. One Item might be (un)available for: Physical access in the house Online Access in the house Physical access at home for members of the institution (loan) Online access at home for members of the institution (remote, proxy) Sequestered access for digital use (Controlled Digital Lending) Physical access at home for members of other institutions (ILL) Copy access at home for members of the institution (ILL) Online access at home for every one (license free remote access) Compare https://github.com/TAMULib/GIFMButtonService		Meeting: R3 As general reminder of completeness.
2	Limitations	Uwe Reh	The general availability of an item may be limited by some reasons. e.g. physical items: "Only against an deposit", "Not on Mondays", "Please ask" online resources: "Moving wall license, not the current year", "Concurrent license, only from IP range, ..."		Uwe: R2 (perhaps solved by displaying notes)	see #10 see #4	y
3	Pickup Locations	Uwe Reh	Sometimes items need to be restricted to as subset of all possible pickup Locations. (e.g. only into a reading room or only limit to the the pickup locations of one department/area) see UXPROD-2689		Uwe: R3, but needs UXPROD-2689	see #23
4	Additional information	Uwe Reh	To decide which item to request, a patron might need additional information. (e.g. "First three pages are missing", "Today's newspaper as handout, might be lost.")		Uwe: R3 (Visibility of notes)	see #2 see #10
5	HRID	Uwe Reh	API should accept UUID and HRID for the requested instances. API should provide UUID and HRID for the items.		Uwe: R1 for request R2 for resonse Chalmers: ? Demian: R2 (VuFind would be less efficient/flexible without this capability) Laura: R2/R3 GBV: R1		y
6	Direction to other systems - not available	(OLD ACCOUNT) Erin Nettifee	If an item is not available, we want to be able to direct the patron to another request path. E.g., if all the copies of book X are unavailable, provide a button that sends the patron to an ILL system to request a copy from another library. Uwe: Is the redirection to an ILL system a task of the availability interface or a task of the discovery system? Should the availability interface be able to list all alternatives like ILL, buy request, AEON, ...?		Meeting: R4/R5
7	Direction to other systems for requesting	(OLD ACCOUNT) Erin Nettifee	If an item can be used but the patron needs to request it in another system, the discovery layer should be able to support that. E.g., library uses FOLIO to circulate its main collections but AEON to provide access to special collections, the discovery system must know that an item should present the AEON request path and not the FOLIO request path.		Meeting: R4/R5
8	Provide a simple way of determining which delivery methods are available for a given item/patron combination	Matt Connolly	Determining whether an item can be paged, recalled, or put on hold requires (I think) making two API calls (to the request-policy and request-policies endpoints) and filtering the results by item status (e.g., charged or available). It would be great to be able to simplify this on the discovery system side. Uwe: one possible context of my 1st. point simplification sounds nice but we should not overlap the APIs for items and for patrons. RTAC should provide 'Limitations', 'Pickup Locations' ans 'Additional information' for patron groups (roles) and PATRON should provide the role of the particular patron. (see "Patron aware" information)	Does this overlap with the need to be able to have a list of valid pick up locations (based on patron and item information) when the patron makes a request for the item?	Chalmers: R4 Uwe: R2 GBV: R3	see: #17 KG: This seems like a patron interface requirement. Uwe: This wish addresses both 'rtac' like 'parton'. Or something in between like a 'PaRtac' The problem is, 'availability' is not only related to an holding/item. The 'availability' is also influenced by the circulation rules (parameter: patron's group, ...) and individual settings (locked users, patron's option: delivery service, ...) Certainly UXPROD-2422, UXPROD-2758 and CIRC-214 are related to this question too. In our consortium we are currently working on problems like this. If possible, I'll share a white paper with use cases in the next days.	y
9	Estimate delivery ~~time~~ day	Matt Connolly	If an item can be requested, provide an estimated delivery time (number of days) for that type of request. This might be a simple setting in Circulation, or it could factor in material type, location, existing requests for the item, etc. Uwe: Also for recalls	Uwe: Is Folio itself providing this informations? e.g. as property of a location Phil: could depend on user too. Uwe: so it is related to #8	Uwe: R2/R3	see: #15
10	Terms of use	Robert Scheier	Terms of use info. from FOLIO Licenses need to be available in Discovery, e.g., concurrent use, ILL, etc. Uwe: see #2 (Limitations)			KG: This functionality is already available - UXPROD-1755 - Getting issue details... STATUS Uwe: If I got it right, the information is available in the UI but not rtac's response see #2 see #4
11	Serial Data Display (Items)	jmulvaney@library.umass.edu	Relevant data from Enumeration, Chronology, and Volume fields should be clearly and uniformly displayed to patrons. Uwe: (Additional information)		Laura: R2 (R3 if this can easily be solved via additional API calls)	KG: Is it preferred that we always returned this information and not have the current conditional logic What gets returned in edge-rtac response?
12	Serial Data Display (Items)	Robert Scheier	Piggybacking on Jack's comment above, volumes should display in sequential order. Right now in FOLIO and VuFind the order is not sequential if you add items out of order.		Laura: R2 (R3 if this can be easily solved via additional API calls)	see #18 KG: MODRTAC-95 BTW - how else should sort RTAC results by?
13	Requests when no items	Marie Widigson kristin.olofsson	Offer an alternative solution to request instances that have no items. Uwe: no items? → buy request? Journal with just one holding but no items (instance → holding → item) Marie: Thinking of e.g journals records that doesn't have items. Be directed to a form/to an e-mail where I can request a specific issue.		Chalmers: R1	KG: Is this possible by creating a custom link on your OPAC/Discovery service layer? Uwe: Yes a custom Link, might be a workaround for this and a lot of other needs mentioned in this spreadsheet. But when the Discovery layer is a hosted service (not self maintained by the library) the library should be able to tunnel such a link
14	Allow title level/item level request depending on instance type.	Marie Widigson kristin.olofsson	Assuming title level request is default, enable item level request when appropriate, e.g. serials, journals. (For this type of instance only show item level request.) Marie: Thinking of e.g journal records that has items. Possibility to select a specific issue to request. Tod: Here is an example of multiple copies of a monograph: https://catalog.lib.uchicago.edu/vufind/Record/667120 Here is an example of multiple copies of a multi-volume monograph: https://catalog.lib.uchicago.edu/vufind/Record/203893 Tobias Gostomsky : A different Use-Case: We sometimes have media in different branch libraries and no transport between libraries. Customers are not always interested in placing a TLR everywhere, but e.g. only in a specific location.		Chalmers: R2 Laura: R2/R1		y - especially for folks using TLR
15	:See number of unfilled requests	Marie Widigson kristin.olofsson	The patron should see the number of unfilled title level requests on an instance, before placing the request (not having to be logged in. Based on this information he/she can make the decision if it's worthwile to place a request or not. Uwe: Queue length? Shortest 'Estimate delivery time of all items? (item request == queue size * x - Title requeset == min of items ?) Marie: The queue length. The number of current open requests. (Not delivery time, it's very hard to estimate.) The number of title level requests can be found in FOLIO UI so I imagine it should not be too difficult to get.		Chalmers: R3 Laura: R3 for title level R1 for item level	see: #9	y
15a	See number of already existing holds for checked-out items	Antje Niemann Marie-Saphira Flug	If title level request is unset: With this information - in combination with the due date of the checked-out item - the patron can decide, if it is worthwhile to place a hold.		VZG: R2
16	Display adjusted item statuses	Marie Widigson kristin.olofsson	Several item statuses are very hard to understand for the patron (e.g. "Aged to lost" & "Claimed returned"). The best would be to add a "discovery display name" already in FOLIO where the library could rename statuses for the discovery layer and have these displayed to the patron instead. (See UXPROD-2636). Uwe: Like in the Patron page? Status-id and status-text in one language? A second best option may be to add a "translation table" for item status ID:s to library specified statuses in the discovery (e.g. "Aged to lost" & "Claimed returned" should be be displayed in the discovery as "Unavailable".)			Marie: This seems to be captured by (OLD ACCOUNT) Erin Nettifee in UIIN-1170 - Getting issue details... STATUS See also https://folio-org.atlassian.net/browse/TCR-9
17	"Patron aware" information	Brooks Travis	RTAC should provide information relevant to the specific authenticated patron (if available) in the RTAC response (i.e. is this item loanable, the initial loan period, requestability, lost item charges, and late fine rate). Ability to retrieve preferred pickup location, preferred fulfillment method, delivery addresses, block status when attempting to place a request would also be helpful. Uwe: IMHO RTAC should be agnostic on the patron. Please, "specific authenticated patron" only as option. BTW. Shouldn't "Lost item fees and late fees" be part of the master data in the patron interface? The same goes for "Preferred pickup location, preferred fulfillment method, shipping addresses and blocking status".	patron group vs. individual patron id	GBV R4	#see #8 UXPROD-2422
18	Sorting of monographs items	Marie Widigson kristin.olofsson	RTAC should sort the holdings and items for a monograph with equivalent items by a defined logic. For example all holdings for Main library at the top, all available items at the top. This need may be different by different institutions and therefore customizable. (Currently in RTAC API response, our items are sorted in a for us seemingly random order.)			see #12 KG: MODRTAC-95 BTW - how else should sort RTAC results by? Homework: Each institution enters their thoughts on fields to be used for monograph sorting in MODRTAC-95. A customizable primary and secondary sort option could be good.
19	Handling of many items		RTAC seems to be slow 1,600 items, Colorado Revised Statutes			see: #20 edge-rtac > add paging logic with system level parameter? cache support? streaming? Understand differences with inventory APIs and edge-rtac Has improved with EDS classic (Chalmers) BUT it is still slow regardless of number of items returned. edge-patron slowness with renewing 200 loans Runs fairly quickly- https://library.villanova.edu/Find/Record/90816 -
20	Performance		General problem?		GBV: 1 ?	see #19	!!
	Retrieve both holdings and Item information at the same time	Brooks Travis	Some institutions wish to use both holdings and items and this currently requires two calls to RTAC. Perhaps especially relevant for serials information.	Question to all What field(s) that could be used to drive what is returned in RTAC? Material type (item in Germany and FRBR always instance) Mode of issuance ( instance) Nature of content (instance) Awareness of holdings statements and item Uwe: RTAC is called, to get availability information about a known instance. So I don't see any need for any attributes of the instance. (Material, insurance, subject, etc. is already known). On the other hand, RTAC cannot provide too much information about the 'holding' and 'item'. Locations, licences, restrictions, pickup locations, additional info, etc. Short, everything which is asked in the other rows	Chalmers: R3 Laura R3 GBV: R2	KG: We definitely need to do this and I think it may help with the above request too	y
21	Create a fake item record to support electronic resources	Khalilah Gambrell	Discussed in 2/7/2024 meeting
22	Single request for multiple items	Björn Muschall	For performance reasons we would be in favour of having a single request/response for multiple items. E.g. all items visible via AJAX. Uwe: Isn't RTAC Batching that what you are looking for?	Björn Muschall Can you provide a example or scenario of the problem that your description would solve?
23	Remove patron choice of pick-up location and default to effective location's service point.	Kara Hart	Allow institution to remove display of pick-up locations for patron when making a request. For institutions that want the request's pick up location to be the effective location's service point. For institutions that cannot transport materials to other service points for request pickup. (Currently our staff have to change pickup locations of items in FOLIO when patrons choose a different pickup point, before we can process the requests)	Hey Kara Hart Doesn't this logic belong in the discovery layer? 2. Are you really looking for just a list of valid pick up locations for the specific item? There is a Jira for "specify the list of pickup locations for a request" - UXPROD-2689 - Getting issue details... STATUS Uwe: I assume, this is the same need as "Pickup Locations" (above). Before being able to provide a list valid locations in the API, UXPROD-2689 has to be solved first. BTW. The 'patron's choice' should be marked as the list's default value.	Uwe: R3 (as part of #3 'pickup locations')	see #3
23	Allow for a request to be processed as a recall even if a hold is also allowed	(OLD ACCOUNT) Erin Nettifee	Currently, if a request is associated with a policy that allows for a hold and a recall, the request will always be placed as a hold. This is undesirable if institutions want recalls to occur if the item is out on loan, because recalls trigger notices and due date changes while holds do not. Most institutions with this configuration find that the high majority of requests are ones where recalls are appropriate, but there are still use cases for holds (e.g., if staff are placing them for processing needs but don't need to require the patron to bring it back early.)	Sorry for asking, but is this a demand for the (discovery) APIs or rather one for the librarian's UX view on FOLIO?

Browser not supported