Requests
(UXPROD-790)
|
|
| 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: |
|
||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||
| Potential Workaround: | Cate Boerema: Use the requests CSV export which has all the data needed by most institutions. OR, when we get |
||||||||||||||||||||
| 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 Output: Bib information, item call #, item location, item barcode, etc and be based on a service point's associated locations. Note:
|
| 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 ] |
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:
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
|
| 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. |