Reporting Feature Requests (UXPROD-1910)

[UXPROD-1867] Build reports based on custom lists Created: 05/Nov/18  Updated: 07/Dec/21

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Reporting Feature Requests

Type: New Feature Priority: TBD
Reporter: Angela Zoss Assignee: Nassib Nassar
Resolution: Unresolved Votes: 0
Labels: ldp-platform, reporting, round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Epic Link: Reporting Feature Requests
Back End Estimate: XXL < 30 days
Back End Estimator: Nassib Nassar
Development Team: Reporting
Kiwi Planning Points (DO NOT CHANGE): 13
PO Rank: 68
Rank: Chalmers (Impl Aut 2019): R4
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: FLO (MVP Sum 2020): R1
Rank: GBV (MVP Sum 2020): R4
Rank: hbz (TBD): R4
Rank: Lehigh (MVP Summer 2020): R2
Rank: MO State (MVP June 2020): R1
Rank: TAMU (MVP Jan 2021): R2
Rank: U of AL (MVP Oct 2020): R4

 Description   

Requester: Angela Zoss (Duke)
Example: Use Folio to create a saved list of items, and then be able to select from these lists when reporting. For context, this is how Alma works. You can manually curate a list, save a search that represents a changing list, or upload IDs from a file to create a list. You can then limit any of your jobs to work on this list. (Apparently possible in ALMA.)
Priority: Apparently needed very frequently; user is currently making do in Aleph by building custom SQL queries with lengthy WHERE x IN (......) clauses. This is important for custom reports with a lot of criteria.



 Comments   
Comment by Kristin Martin [ 08/Nov/18 ]

In theory this would be useful functionality, but it's necessity is unclear because we don't know how the technical implementation of reporting would be done. For now, we are rating as "Wait a year."

Comment by Tod Olson [ 15/Apr/19 ]

Questions/comments from the Reporting SIG:

  • Is the scope just selecting within FOLIO through some kind of UI, or would it include building our own lists in a spreadsheet (or other document) and import them?
  • It sounds like we're talking about less technical people building lists to be operated on, is that right?
  • This sounds similar to part of the LS Tools rewrite: LS Tools is ETL with three basic steps: (1) select records to operate on, (2) transform the records somehow, and (3) reload the records. Building the custom lists seems like the same "select records" step where the operation will be to report on the selected records and to be knit together through the workflow engine.
Comment by Angela Zoss [ 16/Apr/19 ]

I added this before I really understood the LDP architecture (I thought we were building a reporting app, not just a database), so now I would say it might be a feature institutions could look for when they are selecting a reporting application to use to connect to the LDP. Still, there might be FOLIO-internal processes where this would be important to think about.

When thinking about the use cases, this has come up for Technical Services (e.g., there is a long list of barcodes from a vendor, I think, and they need to pull a report on all items) and for Access and Delivery Services (there is a list of users with a particular affiliation or group membership, and they need to either batch edit records - maybe not our problem - or pull a report).

If someone is doing work on a big group of items in a FOLIO module, then yes, maybe we would want to figure out a way to have that list of items sent to the LDP for a query, or vice versa. And yes, with that I think it might relate to the workflow engine issue, since that would be coordinating events across different parts of the FOLIO ecosystem.

Comment by Jenn Colt [ 16/Apr/19 ]

I would agree that this is similar to what we're looking for in replacing LSTools. As I was collecting LSTools-related issues for us to look at, this issue also seemed connected to this one for batch export, where you would want to take a list you created and use it to pull MARC records out of source record storage. https://folio-org.atlassian.net/browse/UXPROD-978

Comment by Sharon Beltaine [ 15/Jul/19 ]

Ranking reviewed at Reporting SIG Meeting 7/15/19. Need to review again to better understand need and functionality.

Comment by Sharon Beltaine [ 22/Aug/19 ]

For Cornell, we use this functionality in MS Access to get data from Voyager every day. For instance, we use Make Table to save a particular dataset and refer it in another query. We also may save a subquery for a custom dataset and then use this same subquery again in subsequent query (we use this subquery as "input" in a subsequent query).

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