Requests
(UXPROD-790)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | Q1 2019 | Parent: | Requests |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Cate Boerema (Inactive) | Assignee: | Cate Boerema (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | requests, resourceaccess | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Requests | ||||||||||||||||||||||||||||||||||||||||||||||||
| Analysis Estimate: | Small < 3 days | ||||||||||||||||||||||||||||||||||||||||||||||||
| Analysis Estimator: | Tania Fersenheim | ||||||||||||||||||||||||||||||||||||||||||||||||
| Front End Estimate: | Medium < 5 days | ||||||||||||||||||||||||||||||||||||||||||||||||
| Front End Estimator: | Matt Connolly | ||||||||||||||||||||||||||||||||||||||||||||||||
| Front-End Confidence factor: | Low | ||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimate: | Large < 10 days | ||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimator: | Marc Johnson | ||||||||||||||||||||||||||||||||||||||||||||||||
| Estimation Notes and Assumptions: | Includes the need to handle the impact of a request queue on item status when there isn't a loan
This means that the transitions for a request can happen at any point for an item Assumes no changes to fulfilment of requests after creation Assumes states where creation are allowed are hard-coded for the scope of this feature |
||||||||||||||||||||||||||||||||||||||||||||||||
| Development Team: | Prokopovych | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Purpose: Implement paging requests (requests for not-checked-out items to be retrieved from stacks by staff and either placed on pickup shelf or delivered), including:
|
| Comments |
| Comment by Cate Boerema (Inactive) [ 09/Nov/18 ] |
|
There are some questions we still need to answer (with SIG) about this feature:
Given the remaining uncertainty and the fact that the development scope on this is smaller than originally thought, I think it makes sense to move this out of Q4 and into Q1 2019. |
| Comment by Marc Johnson [ 09/Nov/18 ] |
|
Cate Boerema Tania Fersenheim at the moment, I believe it is only possible to create hold requests when an item is Checked out. (Changing this may impact the scenarios for check in and check out of items when looking at the request queue) Which issues cover the configurable restriction on item status of hold requests? |
| Comment by Cate Boerema (Inactive) [ 09/Nov/18 ] |
Hi Marc Johnson. There isn't a feature for that yet (just learned of it recently). I can put something in the backlog:
|
| Comment by Marc Johnson [ 09/Nov/18 ] |
|
Cate Boerema That's all good, I just wondered if I missed something. Please, don't raise anything prematurely on my behalf. I'm just curious (and now I know I can defer thinking about it). Thank you. |
| Comment by Hkaplanian [ 13/Nov/18 ] |
|
Does this imply that a person that wants to place a hold must determine if the title is available 1st and then make a decision about placing a hold vs request? |
| Comment by Uschi Klute [ 14/Nov/18 ] |
|
Hkaplanian not the patron, but FOLIO
Usually these are functions from the discovery system. In our experience requests are only carried out by staff in exceptional cases. Indeed, I suppose that the staff user must distinguish between the two manifestations of an item (on loan/not on loan) and do the appropriate action. |
| Comment by Cate Boerema (Inactive) [ 15/Nov/18 ] |
Hkaplanian, it depends. If there is only one type of request allowed per status, the system could make the determination, as Uschi Klute suggested. But many institutions allow more than one type of request for, say, checked out items (i.e. recall, hold). In this case, the requester does need to specify the type of request they are making. This is not a big deal when you are talking about recalls vs holds because there are clear implications (do you need it right away or can you wait for it to be checked back in at the normal due date). With holds and pages it is really not clear why you would choose one over the other. Hence my first comment here - I need to revisit this topic with the SIG to determine if we really need paging requests if we make the allowed item states configurable. |
| Comment by Cate Boerema (Inactive) [ 20/Nov/18 ] |
|
Okay, the SIG confirmed that paging requests are needed. Highlights from our discussion:
|