Details
-
Story
-
Status: Closed (View Workflow)
-
P2
-
Resolution: Done
-
None
-
-
Core: F - Sprint 58
-
2
-
Prokopovych
Description
Purpose: We have added a number of new item statuses but we have not indicated which request types are allowed for all of these new statuses. The purpose of this story is to extend the Hold to Item Status Whitelist on the backend so that it reflects the current thinking of the SIG. Eventually (aspects of) this whitelist will be tenant-configurable (see UXPROD-1320 for details on that).
User story
As a user who is placing a hold on an item
I want the system to tell me if the item cannot have that type of request on it because of its status
So I don't set up invalid scenarios
This also helps eliminate some scenarios we'd otherwise need to code and test for
Scenarios:
- Scenario
- Given a item
- When a hold request is attempted
- Then the backend should check the whitelist to determine if the request is allowed and, if not, reject it
- NOTE: The UI will disallow creation of invalid combos per
UIREQ-209 - NOTE: The page request to item status combinations are covered in
UIREQ-157 - NOTE: The recall request to item status combinations are covered in
CIRC-207
TestRail: Results
Attachments
Issue Links
- clones
-
CIRC-207 Modify Allowed Recall to Item Status Combos According to Whitelist
-
- Closed
-
- defines
-
UXPROD-272 Requests: Paging requests (Basic)
-
- Closed
-
- has to be done before
-
UIREQ-209 Pre-Filter Request Types Based on Whitelist
-
- Closed
-