Tpac - placing holds and barcode scanners

[Ben Shum]

When using the staff client to place a hold using Tpac, the interface asks for the patron's barcode to begin. As one enters this information, it detects user preferences, etc. for the hold and updates the same page accordingly. However, if a staff member uses a barcode scanner to read the barcode and scan it into the place hold field, the auto-return from the scanner can automatically trigger the attempt to place the hold without giving staff the opportunity to review options and/or change hold settings (such as notification options / pickup library, etc.) This skips them straight to hold success or failure and they have to find the hold via view holds on the title or via the patron record itself to set options as actually desired.

In contrast, the workflow in JSPac hold placement was three screens:

1 - Enter recipient barcode
2 - Set hold options
3 - Hold successfully placed (or not) message

That initial screen added extra clicks to the process, but allowed staff to use barcode scanners without incident.

For Tpac, I'm not sure what the best approach would be to solving this particular user problem yet, just reporting for now.

[Sarah Childs (sarahc)]

Related problem: When you enter the barcode it loads user preferences, but doesn't display the user's name.

The Set hold options screen in the JSPac displayed the name of the patron, giving staff the chance to confirm that the hold is being placed for the correct person.

If you are keying in the patron number, and miskey (or correctly enter a wrong number mistakenly provided by a patron) a valid number, you won't know that the hold was placed for the wrong person until the complaints roll in.

[Thomas Berezansky (tsbere)]

I don't consider the patron's name not showing up to be closely related enough to warrant sharing this ticket. I suggest that be opened as a new ticket.

The branch below should prevent enter from submitting from that entry box, though.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/no_hold_autosubmit

[Sarah Childs (sarahc)]

OK--here's the new bug report. https://bugs.launchpad.net/evergreen/+bug/1053635

To me they were related because both problems were the result no longer having the intervening confirmation screen.

[Ben Shum (bshum)]

Tested Thomas' fix and works for us. Thanks!

Sign-off: user/bshum/no_hold_autosubmit

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/no_hold_autosubmit

[Lebbeous Fogle-Weekley (lebbeous)]

Thanks to all three of you. Pushed to master and back through rel_2_2.