Requests (UXPROD-790)

[UXPROD-2285] Filter requests by item effective location Created: 27/Feb/20  Updated: 07/Feb/24

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: Quesnelia (R1 2024)
Parent: Requests

Type: New Feature Priority: P3
Reporter: Siska Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: IC_review, delegate_candidate, requests, requests_printing, requires-discussion, round_iv, volaris-candidate
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: JPEG File Item effective location.JPG     Microsoft Word RequestsCSV.csv     PNG File UI Screen 2.png    
Issue links:
Cloners
clones CHAL-80 Ability to filter requests based on l... Closed
Defines
is defined by CIRC-1959 Populate itemEffectiveLocationId fiel... Open
is defined by CIRCSTORE-466 Add itemEffectiveLocationId to reques... Open
is defined by CIRCSTORE-467 Data migration for itemEffectiveLocat... Open
is defined by CIRCSTORE-468 Data migration for itemEffectiveLocat... Open
is defined by CIRCSTORE-469 Keep request search index up to date Open
is defined by UIREQ-579 Add Filter for Item Effective Locatio... Open
is defined by CIRC-1886 Backend code change for - Add Item se... Blocked
Relates
relates to UXPROD-4688 Add "Item effective location" as an o... Open
relates to CIRC-1930 Create design documentation for UXPRO... Closed
relates to UXPROD-4470 Filter requests by Retrieval service ... Draft
relates to UXPROD-4404 Requests: Deter Duplicate Pick Slip P... Draft
Potential Workaround: Request CSV export (example attached) contains column for item effective location. You could export and then filter the CSV.
Release: Quesnelia (R1 2024)
Epic Link: Requests
Front End Estimate: Large < 10 days
Front End Estimator: Khalilah Gambrell
Front-End Confidence factor: 80%
Back End Estimate: XXL < 30 days
Back End Estimator: Khalilah Gambrell
Back-End Confidence factor: 80%
Development Team: NLA
Kiwi Planning Points (DO NOT CHANGE): 13
PO Rank: 99
PO Ranking Note: 2020-10-05: This is one of the most highly ranked remaining Requests features
Rank: Chalmers (Impl Aut 2019): R3
Rank: Chicago (MVP Sum 2020): R1
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R1
Rank: hbz (TBD): R1
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R4

 Description   

Description

Current situation or problem: Currently in FOLIO, there is not a way to filter Requests by Item effective location. The FOLIO community, including Chalmers, NLA, and Library of Congress, want to be able to filter based on item effective location for request.

In Scope

  • Add a filter accordion containing all Item effective locations in Requests app. to "Search & filter" pane below Pickup service point

              -Filter should contain an auto-complete filtered multi-select menu of all of the locations

              -Accordion should enable operator to select one or more locations

Out of scope

Use case(s)

Libraries field many requests across several retrieval locations. Circulation staff wants to be able filter on Item effective location (retrieval service point) in order to view patron requests that will be retrieved at particular locations as efficiently as possible, easily adjust queues, and use location filters to see which branches may need extra copies of physical items.

Proposed solution/stories

Links to additional info

Questions

to adjust queues and see which branches need extra copies.

 

Notes:

From Chalmers: When looking at Requests the staff wants to be able to filter based on location (effective location for requested item) to adjust queues and see which branches need extra copies.



 Comments   
Comment by Cate Boerema (Inactive) [ 07/May/20 ]

Hi Michal Kuklis and Bohdan Suprun could you please add estimates for this feature? Thanks much!

Comment by Bohdan Suprun (Inactive) [ 07/May/20 ]

Hi Cate Boerema,

Request storage and inventory storage are separate ones, this feature have to be implemented as duplicating the location in the request storage.

The estimate will depend on whether we need to keep the location in sync with inventory storage. The effective location applies additional challenges since it is derived property, so we need observe holdings records as well as items.
a) If yes, then we need a design first, most likely it will be based on pub/sub, draft estimate should be 20-30 days.
b) If no, it should be pretty quick feature, about 5 days.

I'll set the pessimistic estimate.

Comment by Cate Boerema (Inactive) [ 11/May/20 ]

Thanks Bohdan Suprun! We have a tech debt item filed already for using PubSub to keep the item barcode in synch with the request record (see UIREQ-650 Open ). We could reword that item so that it covers item barcode and any other item data that may be replicated in requests (including effective location, if we get to this feature first). If we did that, could we use the lower estimate on this?

By the way, the estimate on UIREQ-650 Open is 8 points.

Comment by Bohdan Suprun (Inactive) [ 12/May/20 ]

Hi Cate Boerema,

I think it make sense to use the single story for all properties that have to be synced. UIREQ-650 Open have to be re-reviewed after it, because effective location requires special handling which is different to barcode or title.

I'll set 5 days estimate.

Comment by Cate Boerema (Inactive) [ 17/Jun/20 ]

Sergiy Sergiyenko could you please add a frontend estimate for this? Thanks!

Comment by Sergiy Sergiyenko [ 17/Jun/20 ]

Hi Cate Boerema.

Implementing a filter option based on effective location (markup and functionality) by analogy with the Inventory App can take about 10 days.
Pessimistic estimate - 15 days.

Comment by Cate Boerema (Inactive) [ 17/Jun/20 ]

Thanks Sergiy Sergiyenko!

Comment by Andy Horbal [ 06/Aug/21 ]

This has surfaced as a major need for Cornell now that we are live with FOLIO. To add a bit of detail, we want to have the full call number included on the display, and for it to be sortable by call number. So, that means:

  • List must be filterable by owning library and location
  • List must be sortable by call number
  • List must be sortable AND filterable by request date

The most important of these requirements is the filterability by library and location.

We'd also like to just be able to print pick slips which have come in since the last time we printed them for a given location, but my assumption is that this will require a separate feature.

Comment by Marc Johnson [ 09/Aug/21 ]

Brooks Travis Holly Mistlebauer Charlotte Whitt

I've removed the high level estimates for this work. They were made prior to the Elastic Search based search PoC and so are likely redundant depending upon when / whether we decide to integrate that work. Any estimates are likely dependent upon the decisions that I think the MM SIG and Capacity Planning group are discussing about that work at the moment.

cc: Zak Burke

Comment by Debra Howell [ 05/Jan/22 ]

Brooks Travis Any updates for this ticket? cc Andy Horbal

Comment by Brooks Travis [ 05/Jan/22 ]

Debra Howell Nothing at the moment. This was fairly low on the Kiwi pointing exercise, and there are still significantly higher-ranked features that the relevant dev teams are working on for Lotus. As Marc mentions above, the "how" of implementing this is definitely in-question. Presently, all of the request filters are based on data stored in the request-storage record, but the data being displayed is coming from the business logic module (mod-circulation) and includes data that is being fetched from the user, item, and instance records. Item location/library are two of those pieces of data, along with call number. If we wanted to implement this using the current filtering approach, it would require a schema upgrade in mod-circulation-storage and a potentially time-intensive DB migration at upgrade to populate the necessary data into the storage record (depending on the number of existing requests in the target system and the approach to handling "closed" requests).

Andy Horbal Can you provide some more information about the workflow(s) this functionality would be in support of, so I can provide some additional context for the feature?

Comment by Andy Horbal [ 05/Jan/22 ]

Brooks Travis Absolutely! Here's the information included by the staff member who submitted this as an enhancement request:

"We need to be able to view requests by effective location (which I assume feeds from the permanent and temporary locations). It is impossible to see how many pending requests are in the queue when you have staff moving on and off the desk and the only way we can view open requests by location (not service point) is to print preview. We currently have to schedule call slips so that we don't mistakenly reprint request slips. Also, sorting by service point is not useful at all since that is where the book is being delivered, not where the book needs to be pulled from."

Please don't hesitate to let me know if you have any questions! One thing I might add to this is that this would allow users to view requests for service points other than the one they're logged in under, and would also provide the ability to filter and sort those requests, which is not currently available. I can also provide as many additional details as you may need.

Comment by Brooks Travis [ 05/Jan/22 ]

Andy Horbal Thanks. Have they looked at using the CSV export functionality after applying basic request status and or other relevant filters to provide the more advanced sort and filter functionality? It's not necessarily a permanent solution, but I'd think it could fill some gaps while we sort out the implementation for this.

Comment by Andy Horbal [ 05/Jan/22 ]

Right, okay, of course, so let's strike my comment about sorting requests! This functionality is available via .CSV export. It wouldn't be a great workaround for anything else I mention in these comments, though. The people who will be using this feature are frontline staff at a circulation desk, so exporting and manipulating an Excel file is much less desirable than being able to filter and sort in app, and I don't think it would help at all with the printing pick slips functionality I mentioned on 8/6.

Comment by Ross Tyner [ 05/Jan/22 ]

I would add that this is a high priority for Okanagan College. We have four libraries, each located in a different city, and we send a lot of books from campus to campus. Staff in each campus library need to be able to see at a glance the holds/requests for items located in their library so they know to pull the item(s) from their shelves. As Andy mentioned, the CSV is a workaround we're using for now, but it is not efficient for dealing with high volumes of holds/requests.

Comment by Brooks Travis [ 06/Jan/22 ]

Ross Tyner are you all not using the paging slips that FOLIO generates?

Comment by Ross Tyner [ 07/Jan/22 ]

Brooks Travis I've looked into this and our staff are using the paging slips, which have been modified to include the effective location as well as the specific location. Therefore, I would say that this feature is now a "nice to have" rather than a "need to have" for us.

Comment by Holly Mistlebauer [ 07/Mar/22 ]

This feature is marked DRAFT until Brooks Travis has a chance to review it for validity.

Comment by Debra Howell [ 03/Aug/22 ]

Brooks Travis Any updates on this ticket? Possible release or anything? 

Comment by Khalilah Gambrell [ 13/Jul/23 ]

Comment from Jared Nagel  - Does this include permissions? Or related permissions tickets. Possible need to restrict views to specific people/reading rooms. Want to filter by retrieval point.

Generated at Fri Feb 09 00:22:41 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.