Requests (UXPROD-790)

[UXPROD-923] Requests in-app report: Requests Pick List Created: 13/Jun/18  Updated: 10/Jan/23

Status: Draft
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Requests

Type: New Feature Priority: P4
Reporter: Cate Boerema (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: appreport, requests, round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: Microsoft Word RequestsAppCurrentCSVExport-PagesOnly.csv    
Issue links:
Cloners
is cloned by UXPROD-1138 Requests Pick List: CSV Export Closed
Relates
relates to UXPROD-867 Reporting: In-App Reports Open
relates to UXPROD-1280 Paging Requests Individual Staff Slip Closed
Potential Workaround: Cate Boerema: Use the requests CSV export which has all the data needed by most institutions. OR, when we get UXPROD-1280 completed, that may be a preferred solution for some institutions. See comment below - it seemed at least a few institutions could live without this feature but the rankings haven't been updated.
Epic Link: Requests
Analysis Estimate: Medium < 5 days
Analysis Estimator: Tania Fersenheim
Front End Estimate: Medium < 5 days
Front End Estimator: Tania Fersenheim
Front-End Confidence factor: Low
Back End Estimate: XL < 15 days
Back End Estimator: Tania Fersenheim
Estimation Notes and Assumptions: estimates based on other appreport features
Development Team: Vega
PO Rank: 74
PO Ranking Note: 2020-10-04 - CB: Making my PO rank same as the calculated total rank for now.
2019-07-12: Reduced rank relative to calculated because of the workarounds (see above)
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R4
Rank: Duke (Full Sum 2021): R2
Rank: 5Colleges (Full Jul 2021): R4
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R2
Rank: Grand Valley (Full Sum 2021): R1
Rank: hbz (TBD): R1
Rank: Hungary (MVP End 2020): R1
Rank: Lehigh (MVP Summer 2020): R2
Rank: Leipzig (Full TBD): R1
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R1
Rank: U of AL (MVP Oct 2020): R2

 Description   

Purpose: Libraries that allow requests on not-checked-out items (e.g. Paging Requests, Remote Storage Requests, Resource Sharing Requests) will want to run a report periodically - at least daily and often multiple times per day, non-checked-out items that have been requested and need to be retrieved from the stacks by staff (paging requests, remote storage requests, resource sharing requests - any type that can be placed on not-checked-out items). The report will need to contain bib information, item call #, item location, item barcode, etc and be able to be limited to a service point's associated locations CB: Per RA SIG discussion on 2019-05-02, we do not need to limit by service point for location. Everyone preferred to be able to limit by Library.

Output: Bib information, item call #, item location, item barcode, etc and be based on a service point's associated locations.

Note:

  • The need for this report varies from institution to institution. Some institutions' workflow requires individual print/call slips in addition/instead: UXPROD-1280 Closed
  • Once UIREQ-262 Closed (Add Library Column to Request CSV) is completed, most, if not all, of the data needed for this report is already included in the Requests app CSV export (see attached). So, in lieu of a purpose-built report, institutions could use the csv export as follows:
    • Use filters in FOLIO to limit to only requests where type = page and status = open-not yet filled
    • Export csv of search results
    • Filter csv export by Library to get those items you are responsible for picking up 2019-10-14 CB: Check in with SIG on this before developing because Darcy asked this same question for pick slips today and the SIG wanted those filtered by service point
    • Print csv export and pick up items on report
  • Follow up: Chalmers decided not to use the CSV export for their picklist and, instead, created a custom solution that would be worth looking at when designing this FOLIO report. See this comment for details: https://folio-org.atlassian.net/browse/CHAL-18?focusedCommentId=75703&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel


 Comments   
Comment by Cate Boerema (Inactive) [ 17/Sep/18 ]

Tania Fersenheim, aren't we attempting to meet this need via the csv export? Also, shouldn't we tag this as Q4 since it's needed for go-live by Chalmers?

Comment by Tania Fersenheim [ 17/Sep/18 ]

Cate Boerema - without the ability to filter requests searches by item location and other data elements, the csv export is only a temporary solution. We still need a full fledged in app report for pick list.

Comment by Cate Boerema (Inactive) [ 17/Sep/18 ]

Cate Boerema - without the ability to filter requests searches by item location and other data elements, the csv export is only a temporary solution. We still need a full fledged in app report for pick list.

But the exported file can be filtered by any of the data elements it contains... Anyway, this feature is needed for Chalmers to go live. I think the temporary solution will have to do for Q4. If you think it's important to keep the full-blown solution separate from the temporary one, we need to create a new feature for one of them. Here's what I'd do:

  1. Rename this feature "Requests Pick List: In App Report"
  2. Create a new feature called "Request Pick List: CSV Export"
  3. Adjust the descriptions of the features to reflect the difference in solutions
  4. Make sure the stories are linked to the correct features
  5. Reach out to Chalmers to see if the csv export will do for Q4 and, if so, change their rank for the in-app report version to something besides go live
  6. Make sure the fix versions for the features correspond with the above

Does that make sense to you?

Comment by Cate Boerema (Inactive) [ 26/Sep/18 ]

Tania Fersenheim I think it may make sense to re-estimate this feature given we now already have a csv export and we just need to add some additional fields to it (to accomplish the "Request pick list: csv export". Let's discuss in our meeting later.

Comment by Tania Fersenheim [ 26/Sep/18 ]

NB: As Cate Boerema and I discussed today, the csv can be filtered by any of the data elements, and that should be workable for the short term, but a busy library or institution will eventually have so many open requests that exporting and filtering will become unwieldy. The bigger the institution, the sooner the export will become unwieldy.

Comment by Theodor Tolstoy (One-Group.se) [ 16/Oct/18 ]

Ranking this one down since the CSV will be enough

Comment by Anya [ 29/Mar/19 ]

Comment from the March Meeting : need a csv at min- need pull slip

Comment by Anya [ 10/Jun/19 ]

Hi Cate Boerema and Tania Fersenheim in the capacity plan this ticket is marked for "Fix Version/s: Q1 2020" Could I change this status on this ticket to reflect that?

Comment by Cate Boerema (Inactive) [ 02/Jul/19 ]

Discussed this in the RA SIG in the feature re-ranking. See discussion at 46:41 of this recording: https://drive.google.com/file/d/15RbACU90Ln4JAazWSz0iM4ZSYia6mIaK/view?usp=sharing

Main question was whether this report was needed or if people could live with the lite version of this report which is already in place (the Requests CSV UXPROD-1138 Closed plus the Location and Library columns which were subsequently added UXPROD-1803 Closed )

  • Per David Bottorff, Chicago could live with the csv because they have an external system anyway for this now that pulls data together from multiple systems (e.g. when it was last touched etc) which they need because most of what they are getting for page requests are things people couldn't find. So, assuming they will still use such a system, the csv export will suffice. Would be nice if we could add "last touched" info. OR, if the LDP was real-time (or near real-time), Chicago wouldn't even need this report.
  • Per Mark Canney, Lehigh can live with the csv export
  • Per Andrea Loigman, Duke can live with the csv as long as the individual pick slips ( UXPROD-1280 Closed ) is available (because they prefer those anyway)
Comment by Darcy Branchini [ 06/Dec/19 ]

Cate Boerema, I see that you reference everyone preferring it to be limited by library instead of service point, but we just implemented the individual pick slips (staff slips), and at the time I reviewed requirements with them (which was recently - Nov 2019), they preferred service point. That's how it's been implemented. It seems that this would be a relatively easy feature to do as long as it's following the same logic as individual pick slips.

Comment by Cate Boerema (Inactive) [ 09/Dec/19 ]

Darcy Branchini I love how asking the same question will get you completely different answers over time...

I agree, a purpose-built pick list report would probably not be too difficult to develop especially if it leveraged the logic and code implemented for the individual pick slips.

Comment by Holly Mistlebauer [ 07/Mar/22 ]

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

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