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

Bug #1801093 reported by Lindsay Stratton
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
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

Revision history for this message
John Amundson (jamundson) wrote :

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.

Revision history for this message
Lindsay Stratton (lstratton) wrote : Re: [Bug 1801093] Re: Web client: Hold transit alert not closed triggers wrong hold shelf slip when second item scanned

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

tags: added: circ-holds transits
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers