Implement request status "Closed - Unfilled"
Description
Environment
Potential Workaround
Attachments
clones
has to be done after
has to be done before
relates to
Checklist
hideTestRail: Results
Activity
Cate Boerema March 9, 2019 at 4:54 PM
This works perfectly, !! Thanks so much to you and the rest of the Vega team. I am going to mark this closed
I did find one related issue: . I am not sure if it would be best fixed by Vega or the Core Functional team. What do you think?
Khalilah Gambrell March 7, 2019 at 9:06 PM
, is it okay to move this story to done?
Cate Boerema February 25, 2019 at 9:15 AM
Okay, I just read the comments on and it seems the preferred approach is to remove closed items from the request queue. I can update the scenarios.
Cate Boerema February 25, 2019 at 8:58 AM
Given that the requests that could generally expire could be in any position in the queue, it could be a while before the next check in following expiry (unlike for my understanding of pickup expiration). Do we want closed requests to remain in various positions in the queue for an extended period of time?
I think this is fine, as long as the system effectively ignores the requests that are "Closed - Unfilled". Let me know if you have concerns or other ideas for how to handle this.
Marc Johnson February 20, 2019 at 1:52 PM
Thanks for clarifying this.
In transit
I agree that Open - In transit is a border case.
To me, when a request enters Open - In transit it has started being fulfilled. Hence, it is appropriate to not expire it.
As an example, if the item had been checked in at the chosen pick up service point, it would have moved directly to Open - Awaiting Pickup and not be subject to general expiration. To me it follows that, we wouldn't want the expiration rules to be different just because a different patron checked the item in elsewhere?
When to remove the request from the queue
Please see the conversation on for context, starting with this comment.
Given that the requests that could generally expire could be in any position in the queue, it could be a while before the next check in following expiry (unlike for my understanding of pickup expiration). Do we want closed requests to remain in various positions in the queue for an extended period of time?
Purpose: To enable requests to expire based on the Request expiration date, which results in the new request status "Closed - Unfilled"
User story:
As a user who needs a book by a certain date but, after that date, the book will no longer be useful to me
I want to set an expiration date for my request
So that, if the date passes and I still haven't received the book, my request will automatically close (as I really no longer need it)
Scenarios:
Scenario
Given a request with request status = "Open - Not yet filled"
When the request's "Request expiration date" passes
Then:
The request status should change to "Closed - Unfilled"
The request is removed from the queue for the item by
removing it's position
re-positioning all other requests in the queue accordingly
The item status of the associated item should not change
No edit button or other edit option should appear (closed requests should never be editable)
Scenario
Given requested item A with request status "Closed - Unfilled"
When item A is checked in
Then check in should behave as it would if the closed request weren’t present - I will add some test scenarios to elaborate on how that logic should work)
Test Scenarios (to elaborate on scenario 2 above)
This functionality already works, we just need to make sure it still works in this new scenario
Scenario
Given a requested item A with Item status = Checked out AND Request X is in position 1 of the request queue and Request Y is in position 2 of the request queue
When Request X becomes "Closed - Unfilled" AND Item A is checked in at Service Point 1
Then:
Item status will change to Awaiting pickup if Request Y has pickup service point Service Point 1
Item status will change to In transit if Request Y has pickup service point other than Service Point 1
Scenario
Given a requested item A with Item status = Checked out AND Request X is in position 1 of the request queue AND there are no other requests in the request queue for that item
When Request X becomes "Closed - Unfilled" AND Item A is checked in at Service Point 1
Then:
Item status will change to Available if Item A's Effective location is related to Service Point 1
Item status will change to In transit if Item A's Effective location is not related to Service Point 1
Scenario
Given a requested item A with Item status = Paged AND Request X is in position 1 of the request queue AND there are no other requests in the request queue for that item
When Request X becomes "Closed - Unfilled" AND Item A is checked in at Service Point 1
Then:
Item status will change to Awaiting pickup if Item A's Effective location is related to Service Point 1
Item status will change to In transit if Item A's Effective location is related to a service point other than Service Point 1