Requests (UXPROD-790)

[UXPROD-2411] Display Popup When Requested Item is Marked Missing, Withdrawn, Claimed Returned or Declared lost Created: 28/Apr/20  Updated: 16/Dec/20  Resolved: 12/Nov/20

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: R1 2021
Parent: Requests

Type: New Feature Priority: TBD
Reporter: Cate Boerema (Inactive) Assignee: Charlotte Whitt
Resolution: Done Votes: 0
Labels: round_iv, test-case-written, ui-only
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PNG File screenshot-1.png     PNG File screenshot-2.png     PNG File screenshot-3.png    
Issue links:
Defines
is defined by UIIN-1294 Show requests at status change: Missi... Closed
is defined by UIU-1890 Show requests at status change: Decla... Closed
is defined by UIU-1891 Show requests at status change: Claim... Closed
Epic Link: Requests
Front End Estimate: XL < 15 days
Front End Estimator: Sergiy Sergiyenko
Development Team: Prokopovych
PO Rank: 26
PO Ranking Note: 2020-10-05: Marking the PO rank same as the calculated ranks. This is ui-only work and, as such, may get prioritized for Iris (as we often have a bit of front end capacity for such features). I have decided not to artificially inflate the PO rank to account for this, as there are other ui-only features we may end up pulling in opportunistically: https://issues.folio.org/issues/?filter=12500
Rank: Chicago (MVP Sum 2020): R4
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: Grand Valley (Full Sum 2021): R1

 Description   

Per RA SIG meeting on 2020-04-27:

  • If you mark an item declared lost, claimed returned, missing, withdrawn, order closed (CB: Will be moved to new feature) and there are open requests on the item:
    • There should be a popup letting you know
    • It should be possible to not move forward with the item status change (some institutions might tell staff that, when there are requests, they shouldn't proceed with the status change)
    • There should be a link to the requests app (pre-filtered to show the relevant request(s))
    • You can then move the request(s) to another item or cancel it/them

Scope of this issue is to implement this popup for all four status changes: Missing, Withdrawn, Claimed Returned or Declared lost



 Comments   
Comment by Cate Boerema (Inactive) [ 28/Apr/20 ]

Hi Sergiy Sergiyenko and Bohdan Suprun could you please put estimates on this feature when you have the chance? Thanks!

Comment by Bohdan Suprun (Inactive) [ 28/Apr/20 ]

Hi Cate Boerema,

No BE changes required for this feature.
Once we're marking item as missing or withdrawn we're updating request, that is being fulfilled, with status Open - Not yet filled.

Is it still required?

Comment by Cate Boerema (Inactive) [ 29/Apr/20 ]

No BE changes required for this feature.

Oh, good to know there is no backend needed for this feature, Bohdan Suprun.

Once we're marking item as missing or withdrawn we're updating request, that is being fulfilled, with status Open - Not yet filled.

Is it still required?

Yes it's still needed, as the request will essentially be orphaned at that point in that it will be associated with an item that is not expected to become available. Someone at the library needs to look at the orphaned requests and either cancel them or move them to another item. The popup described in this feature will let them know they need to do that.

Thanks for looking at this, Sergiy Sergiyenko and Bohdan Suprun!

Comment by Cate Boerema (Inactive) [ 04/May/20 ]

Hi Sergiy Sergiyenko thank you for your frontend estimate. I just added a new requirement (bullet 2 in the description) and added an additional status change that also needs a popup like this (order closed). Please increase your estimate, if needed.

Thanks!

Comment by Sergiy Sergiyenko [ 04/May/20 ]

Hi Cate Boerema.
In my opinion, the implementation of a condition/flag that does not allow to proceed with the item status change shouldn't increase the complexity, and, as a result, an additional estimate is not needed.

Comment by Cate Boerema (Inactive) [ 05/May/20 ]

Thank you Sergiy Sergiyenko!

Comment by Cate Boerema (Inactive) [ 07/Oct/20 ]

Hi Emma Boettcher. Is there any chance you have time to write stories for this feature? It's ui-only so I'd love to get it dev-ready. It straddles our areas so I thought it might be fair to ask for your help

Comment by Emma Boettcher [ 07/Oct/20 ]

Cate Boerema Sure, should be simple for most of these. Most of the statuses in the story have modals requiring confirmation anyway, so it could be added like so:

Claimed returned also has a bulk action, but requests shows up in the table for that, so could link the requests count where it displays there.

Order closed is trickier - I'm not sure this would be ui-only for that. The modal for closing doesn't reference the particular items when you're closing the order, and I believe most orders are closed without needing to cancel requests (if the order is closed because all items are received).

Comment by Cate Boerema (Inactive) [ 08/Oct/20 ]

That's looks great! Thank you!

Gotcha on the Order closed scenario. We could create a separate UXPROD for it, but maybe we should get Dennis Bridges's thoughts first.

Comment by Dennis Bridges [ 08/Oct/20 ]

Cate Boerema and Emma Boettcher If i'm understanding this correctly, I think it might be best to show the popup in the orders app before allowing the user to close the order. This way they would need to deal with the request on "Unreceived items" first. However, if there is an item with status "Order closed" in inventory that is not suppressed or deleted I suppose someone could put an additional request on it. Unless the request app is able to recognize this status and prevent it. Both of these things would likely require some BE horse power.

Comment by Cate Boerema (Inactive) [ 09/Oct/20 ]

Thanks for presenting these stories today, Emma Boettcher. Is it safe to say this is "Analysis complete" or are there more stories to be written?

Comment by Emma Boettcher [ 09/Oct/20 ]

Cate Boerema This feature still needs Order closed stories, unless you wanted to break that out into a separate feature because it requires backend work and the others don't. Dennis Bridges the functionality to make Order closed stories non-requestable is part of UXPROD-2253 Closed . I think you're right though that showing requests on unreceived items in the Orders app still requires BE work.

Comment by Cate Boerema (Inactive) [ 12/Oct/20 ]

If i'm understanding this correctly, I think it might be best to show the popup in the orders app before allowing the user to close the order. This way they would need to deal with the request on "Unreceived items" first.

That makes sense to me, Dennis Bridges. So I guess this use case is about notifying users so they can handle (e.g. move, cancel) existing requests on unreceived items when an order is closed.

However, if there is an item with status "Order closed" in inventory that is not suppressed or deleted I suppose someone could put an additional request on it. Unless the request app is able to recognize this status and prevent it. Both of these things would likely require some BE horse power.

And this use case is about preventing new requests on "order closed" items. It looks like the request app should already prevent this. See the request whitelist here: https://docs.google.com/spreadsheets/d/1jaID-HGft3q4YzJq6Ycy2ejWByAIvou3Zyyw4ko87YI/edit#gid=0

I think it does make sense to split out the order closed use case from this feature because (1) it might require backend and (2) it would be best implemented by Thunderjet. Dennis Bridges, do you want to write that feature? I think you best understand the workflow.

For now, I will remove the references to Order closed from this feature.

Comment by Emma Boettcher [ 11/Nov/20 ]

Cate Boerema I've tested all stories for this one, and believe it can be closed, but I'll let you make the final call.

Generated at Fri Feb 09 00:23:44 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.