UXPROD-2565 - Getting issue details... STATUS

Problem(s):

User must navigate to inventory to place a request on newly ordered items. This requires additional permissions and breaking up the acquisitions workflow or risking that items are requested before a hold can be place for the desired user.
Title level requests will automatically pull an item that is created by the orders app.
When creating multi-line POLs a library may be waiting on approval for the full PO. The requested item is associated with one POL and user must remember to go back and create request once orders is approved and Opened. Because Item is not generated until the order is opened.

Use Cases & Requirements:

Requirement	Status	Use cases
Automatically create a request for the on-order material so that it can't be taken by someone else. Prevent Title level request queue from picking up this item.	VERIFIED	At Duke when a patron requests that we order a title, we would flag it as a rush order and capture the patron ID on the order record. Upon arrival a hold is put on the item so that it can't be loaned to anyone else. The hold action needs to happen immediately at the time of order creation to preserve the "first dibs" priority of the original requestor so that they don't get bumped if a request sneaks in as soon as the item is created.
Allow requests to be created for a general user. Possibly system user or a specified generic user account (Requests require a user ID so we can not allow free text when generating request)	VERIFIED	The library does occasionally place holds at point of order without knowing the specific user id. In some cases the requester information could be in a separate system (Eg. Iliad) and a default user is used to identify that this item should be treaded a certain way in the workflow ultimately having a person update the request information so the item is put aside for the correct user. Library is ordering at vendor site and vendor does not have user ID. Allowing requester to NOT be a "user" account would be valuable.

Proposed workflow:

Functionality Potentially Impacted by Changes:

Functional area	Records	Potential impact	Suggested Regression Testing

Questions:

Question	Status	Conclusion	Comments
It seems we may need to add an option for the Fulfillment preference after all?	OPEN	User must indicate the Fulfillment preference for Pickup service point to be required. So we must add this field as well. It will be a select list.	Re the step "User must select a pickup service point," we're using delivery requesting so there may not be a pickup service point. It seems like there's an extra step needed in there for fulfilment preference, then service point or delivery address selection.
Regarding Hold vs. Recall can an assumption actually be made here or would it need to be a setting?	OPEN	The only type of request needed here is a Hold request.	There are patron that ask to be notified but not have a hold placed. This is potentially a note that would be added to the request or to the POL if a request was not being created.
Another use case: alerting a user to a newly-available, ordered eBook, which does not have an item record. Is there a way to create a patron request for that? Should that perhaps be a separate feature? Should all requests be "title level requests"	OPEN		At 5C if the request comes from a prof from University A the library would not want to give a different item to that user. They would want the item they are buying to be given to the user. Ie. they want the item that their group is buying to be loaned to that user rather than taking something from another library. For the most part it is not critical that a user is assigned to the specific item they are ordering. Just that the get the item as soon as possible.
Are there ever multiple requesters. Would the POL need to accommodate multiple requesters?		Only one requester should be possible. However, only require a user ID if the user actually wants a request created.	Users could always add additional requests as needed. In current systems this is often handled in a note field.

Work Breakdown Structure:

Features:

UI Stories

MOD Stories

key	summary	type	created	updated	due	assignee	reporter	priority	status	resolution

Refresh

Browser not supported