Web client: Hold transit alert not closed triggers wrong hold shelf slip when second item scanned
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Web client, 3.0.13
We have discovered an issue combining staff error with hinky hold transit alert behavior, resulting in inexplicable hold shelf receipts and chaos.
1) Item 1 is scanned in check in at Lib A, it is to be routed to Lib B for a hold
2) The hold transit alert is not closed
3) Item 2 is scanned while the alert is still displayed
4.a) The auto-enter of the scanner triggers a *Hold shelf Slip* for Item 1, as if it were printed from hold pick up Lib B (apparently using that library's hold shelf receipt template?!)
4.b) Item 2 is given the hold slip 'corresponding' to Item 1 and placed on the hold shelf at Lib A
4.c) Item 2 is not checked in
4.d) The *transit* for Item 1 stays correct and the hold is not made available
4.e) Lib B is wondering where the in transit hold item item has gone
tags: | added: circ-holds transits |
I have not been able to duplicate this on either 3.0.13 or 3.2.1.
Here are the steps I took and what I noticed:
1) Item 1 is scanned in check in at Lib A, it is to be routed to Lib B for a hold
2) The hold transit alert is not closed
3) Item 2 is scanned while the alert is still displayed
4) The auto-enter of the scanner triggers a press of the on-screen "Print" button. A Hold Transit Slip is printed for Item 1
5) Item 2 is not checked in. I expected this because the scanner's return feature was used to print the previous slip
By default, the Hold Transit Slip looks very similar to the Hold Shelf Slip. I would check your Print Template for Hold Transit Slip and see if that is what is printing in step 4.a)
I saw the same behavior with and without Hatch installed.