Display Popup When Requested Item is Marked Missing, Withdrawn, Claimed Returned or Declared lost

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

Priority

Fix versions

Development Team

Prokopovych

Assignee

Charlotte Whitt

Solution Architect

Parent Field Value

None

Parent Status

None

Attachments

3
  • 12 Oct 2020, 07:54 AM
  • 07 Oct 2020, 09:02 PM
  • 07 Oct 2020, 08:52 PM

Checklist

hide

TestRail: Results

Activity

Show:

Emma Boettcher November 11, 2020 at 6:58 PM

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

Cate Boerema October 12, 2020 at 7:56 AM
Edited

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, . 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. , 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.

Emma Boettcher October 9, 2020 at 4:18 PM

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. the functionality to make Order closed stories non-requestable is part of https://folio-org.atlassian.net/browse/UXPROD-2253#icft=UXPROD-2253. I think you're right though that showing requests on unreceived items in the Orders app still requires BE work.

Cate Boerema October 9, 2020 at 4:12 PM

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

Dennis Bridges October 8, 2020 at 4:20 PM

and 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.

Done

Reporter

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

Front End Estimate

XL < 15 days

Front End Estimator

Rank: 5Colleges (Full Jul 2021)

R2

Rank: Cornell (Full Sum 2021)

R1

Rank: Grand Valley (Full Sum 2021)

R1

Rank: Chicago (MVP Sum 2020)

R4

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created April 28, 2020 at 9:10 AM
Updated December 16, 2020 at 1:39 PM
Resolved November 12, 2020 at 11:09 AM
TestRail: Cases
TestRail: Runs