Export Requests search results to csv - additional data elements
Description
Purpose: Users need to be able to export requests in CSV format in order to do more complex sorting and filtering, to use as a picklist for retrieving items from the shelves, to use as a list of requests that have expired and need to be removed from the hold shelf, etc.
This story is to add several data elements that are visible on the Requests screen but not yet available to the API
The additional data elements are: Request expiration date Contributor (formerly author) Call number Enumeration Copy number - spun off into UIREQ-136 Item status - data in column is incorrect Current due date - data in column is incorrect (Number of) Requests - column doesn't exist, but we can wait for this if needed, see note below Requester Patron group - no data in column Pickup location - column exists but unable to test because perhaps can't assign a pickup location yet [Note: now called Pickup service point; still no data; should there be?] Delivery address - no data in column, but maybe OK? Requester's proxy name Requester's proxy barcode
Scenarios
Scenario
Given the Requests screen (the list that results from a search within the Requests app)
When at least one request is displayed
Display and activate the export function
Scenario
Given the Requests screen (the list that results from a search within the Requests app)
When a user clicks export on the Requests (search results) screen
Then the following fields, populated as they are on the Request details page, are exported as CSV for each request:
Request type
Request status
Request expiration date*
Hold shelf expiration date
Position in queue
Item barcode
Title
Contributor (formerly author)
Shelving location (Effective Location)
Call number*
Enumeration*
Copy number (aka Piece identifier SPIN OFF TO A NEW STORY)*CB: Moved into UIREQ-136
Item status* for the paged item, it is showing a status of checked out; this is a separate ticket now
Current due date*
(Number of) Requests*CB: Per we can live without this for a while if it's going to have performance implications [not in the export - is this covered in another story now?]
Requester Name
Requester Barcode
Requester Patron group*
Request Fulfillment preference
Pickup service point (name not the ID)* (column exists but cannot test because we can't assign pickup service points yet)
Delivery address* - column exists; should there be data?
Requester's proxy name*
Requester's proxy barcode*
Scenario
Given the Requests screen (the list that results from a search within the Requests app)
When a user clicks export on the Requests (search results) screen
Then the file will contain every field, even when no data is present for that field (e.g. a request with no proxy will have no Requester's proxy name or Requester's proxy barcode associated with it)
Scenario
Given the Requests screen (the list that results from a search within the Requests app)
When a user has filtered the list of requests
Then the exported csv will contain only the requests in the filtered results list
Implementation note: While this story is specific to exporting requests, we will need the ability to export other types of lists as well in FOLIO (e.g. fees/fines, users, loans). Please consider implementing as a reusable component.
We think this is all fixed now, except the stuff that has been pulled out to separate issues. FINALLY closing this ticket. Hooray!!!!
Aditya matukumalli December 9, 2018 at 9:11 PM
Just added in the fix for this. Should be up on testing in a bit. Thanks.
Cate Boerema December 9, 2018 at 8:23 PM
I'm not able to test this, as I get the following error when I try to export the csv
Cate Boerema December 3, 2018 at 12:53 PM
Sounds good! Thanks!
Marc Johnson December 3, 2018 at 11:44 AM
Edited
I don't see why paging request would impact this story except that we want paging requests that have been created in FOLIO to be included in the export like the other requests.
I don't think this does affect the export story. I believe found orthogonal unexpected behaviour during testing.
If we are saying this is deferred until the page request story , then I suggest this isn't a bug and the behaviour will be implemented during that story?
Purpose: Users need to be able to export requests in CSV format in order to do more complex sorting and filtering, to use as a picklist for retrieving items from the shelves, to use as a list of requests that have expired and need to be removed from the hold shelf, etc.
This story is to add several data elements that are visible on the Requests screen but not yet available to the API
The additional data elements are:
Request expiration date
Contributor (formerly author)
Call number
Enumeration
Copy number - spun off into UIREQ-136
Item status - data in column is incorrect
Current due date - data in column is incorrect
(Number of) Requests - column doesn't exist, but we can wait for this if needed, see note below
Requester Patron group - no data in column
Pickup location - column exists but unable to test because perhaps can't assign a pickup location yet [Note: now called Pickup service point; still no data; should there be?]
Delivery address - no data in column, but maybe OK?
Requester's proxy name
Requester's proxy barcode
Scenarios
Scenario
Given the Requests screen (the list that results from a search within the Requests app)
When at least one request is displayed
Display and activate the export function
Scenario
Given the Requests screen (the list that results from a search within the Requests app)
When a user clicks export on the Requests (search results) screen
Then the following fields, populated as they are on the Request details page, are exported as CSV for each request:
Request type
Request status
Request expiration date*
Hold shelf expiration date
Position in queue
Item barcode
Title
Contributor (formerly author)
Shelving location (Effective Location)
Call number*
Enumeration*
Copy number (aka Piece identifier SPIN OFF TO A NEW STORY)* CB: Moved into UIREQ-136
Item status* for the paged item, it is showing a status of checked out; this is a separate ticket now
Current due date*
(Number of) Requests* CB: Per we can live without this for a while if it's going to have performance implications [not in the export - is this covered in another story now?]
Requester Name
Requester Barcode
Requester Patron group*
Request Fulfillment preference
Pickup service point (name not the ID)* (column exists but cannot test because we can't assign pickup service points yet)
Delivery address* - column exists; should there be data?
Requester's proxy name*
Requester's proxy barcode*
Scenario
Given the Requests screen (the list that results from a search within the Requests app)
When a user clicks export on the Requests (search results) screen
Then the file will contain every field, even when no data is present for that field (e.g. a request with no proxy will have no Requester's proxy name or Requester's proxy barcode associated with it)
Scenario
Given the Requests screen (the list that results from a search within the Requests app)
When a user has filtered the list of requests
Then the exported csv will contain only the requests in the filtered results list
Implementation note: While this story is specific to exporting requests, we will need the ability to export other types of lists as well in FOLIO (e.g. fees/fines, users, loans). Please consider implementing as a reusable component.