Support moving request above page
Description
Environment
Potential Workaround
Attachments
- 31 Jul 2019, 07:20 AM
- 31 Jul 2019, 07:19 AM
- 31 Jul 2019, 07:14 AM
has to be done after
Checklist
hideTestRail: Results
Activity
Michal Kuklis July 31, 2019 at 5:34 PM
@Cate Boerema, @William Welling and @Marc Johnson I'm honestly completely lost here 
I'm hoping what has to happen from the UI perspective is similar to what will happen in https://folio-org.atlassian.net/browse/UIREQ-294#icft=UIREQ-294. Namely the server side validation will fail and some extra information will be provided to the front end.
William Welling July 31, 2019 at 12:56 PM
@Marc Johnson I am not sure what the desired approach will be.
Here is my take:
The backend should have validation preventing a request to jump a paged request. If the datetime of the request being moved is before the paged request, it currently jumps it in the queue. This is a problem and cascades other status change issues. It should be prevented before persisting any changes. The frontend has both request queues and can perform similar validation and prompt for the desired status of the request being jumped. The backend move request API can afford for this desired status change be part of its request body and apply to desired request status to the request being jumped.
Marc Johnson July 31, 2019 at 8:57 AM
@Jeremy Huff @William Welling @Michal Kuklis please can you help me understand the approach we are intending to take here?
Bullet point 3 of the then section of scenario 1 suggests that the UI will be able to determine when this scenario is going to happen, in order to provide the modal prompt.
How will the UI know that this situation has / is about to occur?
Cate Boerema July 31, 2019 at 7:40 AM
@Michal Kuklis I am assigning this to you since you have the background here. Hope that's okay.
Details
Details
Assignee
Reporter
Labels
Priority
P4
Purpose: To handle the case of moving a request from source item to target when the moved request will jump a page request on the target item. This has some special handling needs and so was deprioritized for the first version of the move requests feature.
Scenarios:
Scenario
Given Request A is a Hold or Recall that was created at 10:00 on Item X
When Request A is moved to Item Y which has item status = Paged because it has also been requested (Request B, created at 10:30 am, Request status = Open - Not yet filled)
Then:
Request A should go to the top of the request queue for Item Y because it was created first and Request B has not yet begun fulfillment (this was working as of 2019-07-31)
Request A should automatically be changed to a Page request (popup should display letting user know)
Request B should be changed from Page request to Recall or Hold
A popup should display after the first popup allowing a user to choose which one
If selected type is allowed per request policy, success confirmation should display
If selected type is not allowed per request policy, see https://folio-org.atlassian.net/browse/UIREQ-294#icft=UIREQ-294 for desired behavior
Item status for Item X should not be impacted by the move of Request A (because only the presence of Page requests impacts item state and Request A was not a page request when it was created on Item X) (this is covered by https://folio-org.atlassian.net/browse/CIRC-411#icft=CIRC-411)
Scenario
Given Request A is a Page that was created at 10:00 on Item X
When Request A is moved to Item Y which has item status = Paged because it has also been requested (Request B, created at 10:30 am, Request status = Open - Not yet filled)
Then:
Request A should go to the top of the request queue for Item Y because it was created first and Request B has not yet begun fulfillment (this was working as of 2019-07-31)
Request A should remain a Page request (no popup needed here)
Request B should be changed from Page request to Recall or Hold
A popup should display after the first popup allowing a user to choose which one
If selected type is allowed per request policy, success confirmation should display
If selected type is not allowed per request policy, see https://folio-org.atlassian.net/browse/UIREQ-294#icft=UIREQ-294 for desired behavior
Item status for Item X should become Available if the request queue on Item X is now empty per https://folio-org.atlassian.net/browse/CIRC-333#icft=CIRC-333 (this was working as of 2019-07-31)