Web client: Hold transit alert not closed triggers wrong hold shelf slip when second item scanned

[Lindsay Stratton]

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

[John Amundson (jamundson)]

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.

[Lindsay Stratton (lstratton)]

I just retested, and *headdesk*. As it turns out, the library had Hold Shelf Slip content in the Hold Transit Slips template.

Scanning a new item over the Transit alert triggered the Hold Transit Slip (with bad content). That the scanner enter is sufficient to trigger a slip print is still a problem. This does not happen in the XUL client.

Lindsay Stratton
Library Automation Services Manager
Pioneer Library System
2557 State Rte 21
Canandaigua, NY 14424

From: "John Amundson" <email address hidden>
To: "Lindsay Stratton" <email address hidden>
Sent: Thursday, November 1, 2018 12:21:57 PM
Subject: [Bug 1801093] Re: Web client: Hold transit alert not closed triggers wrong hold shelf slip when second item scanned

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

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1801093

Title:
Web client: Hold transit alert not closed triggers wrong hold shelf
slip when second item scanned

Status in Evergreen:
New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/evergreen/+bug/1801093/+subscriptions
BQ_END

[Lindsay Stratton (lstratton)]

Not a bug, marking invalid