Apply Payment button can be triggered by RFID items

Bug #1183964 reported by Steven Chan on 2013-05-24
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned
2.3
Undecided
Unassigned
2.4
Undecided
Unassigned

Bug Description

On the staff client/patron interface/bills tab, the Payment Received
input is auto-focussed. Upon a user entering an amount and then
pressing Enter, the amount is distributed amongst the bills listed and
the Apply Payment button is auto-focussed. If the user then presses
Enter, the amount is applied.

However, for a workstation with an RFID reader, if items using RFID are
nearby, Enter may be accidentally triggered, resulting in unwanted
payment transactions.

The fix is to remove the focus on the Apply Payment button. The user
should now click the button or use the keyboard shortcut.

Evergreen version 2.2

Steven Chan (schan2) wrote :
Ben Shum (bshum) on 2013-05-24
Changed in evergreen:
status: New → Triaged
importance: Undecided → Medium
Jason Etheridge (phasefx) wrote :

The intent with the auto-focus was to make for quick data entry. Type numbers, press enter, looks sane, press enter. As much as I'm starting to hate the proliferation of configuration options, this may need one. Unless folks would prefer a speedbump here anyway. No easy way to disable the RFID reader until needed?

Steven Chan (schan2) wrote :

> The intent with the auto-focus was to make for quick data entry. Type
> numbers, press enter, looks sane, press enter.

We appreciate the intent, however, we also have to consider workstations
with RFID readers and the automatic data entry they will incur.

> As much as I'm starting to hate the proliferation of configuration
> options, this may need one.

I think such an option would be too 'microscopic' in nature, although I
see there are other such options already in use. I think this is one
reason there is such a proliferation.

> Unless folks would prefer a speedbump here anyway.

It might be useful; hitting the last Enter might be too easy to do,
leading to unintentional entry.

> No easy way to disable the RFID reader until needed?

The reader seems to be active all the time, or at least earlier than
expected, and there being no easy way for circ staff to alter the
reader's activity.

Jason Boyer (jboyer) wrote :

There is another option that doesn't effect the button itself. There are soft and hard limits for the In House Use function (you get an "Are you sure?" over the soft limit, and an "I don't think so" over the hard limit). Similar settings could be made for accepting payments without effecting the workflow of normal transactions. Defaults of 1000 and 10000 would make the problem disappear for most currencies.

Ben Shum (bshum) on 2013-08-22
no longer affects: evergreen/2.2
Kathy Lussier (klussier) wrote :

I vote for an option on this one so that it doesn't disrupt the workflow for non-RFID workstations. Maybe it can be a workstation setting that then gets toggled just on those workstations using RFID. Since there is ongoing discussion on the approach, I'm going to remove the pullrequest tag from the bug.

Also, another workaround for those who use RFID readers is to set the "Uncheck bills by default in the patron billing interface" to True. If set, and the user follows the steps Steven outlined above, the user will get a message saying no bills have been selected. Staff then needs to manually select the bills before hitting the Apply Payment button.

tags: removed: pullrequest
Jason Boyer (jboyer) wrote :

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

Here is a fix that corrects the problem and also offers additional benefits. This adds 2 OU settings, a warning amount and a maximum payment amount. Any payment accepted over the warning must be verified by staff, and no client payments will be accepted over the maximum amount. Default values of 1000 and 100000 are built in to the code to prevent accidentally accepting a barcode as an amount, but not inconveniencing staff for normal transactions.

Changed in evergreen:
milestone: none → 2.next
Jason Boyer (jboyer) wrote :

An added caveat: I have not yet tested this Web Client code. I'm going to do that ASAP, but at this point in time I don't have a test setup in place. If I or other testers run into any issues this branch will be updated.

Jason Boyer (jboyer) wrote :

Update: I finally tested that web client code and it was only about 60% baked. Now it's fully armed and operational, and the above branch force-pushed.

Also of note: there are 3 commits at the end of that branch: 1 adds the settings to the db, the next adds XUL client support, and the last adds web client support.

To test:
1. Load patron (any client), try to apply a payment of 10000000, it will be accepted without question.
2. Apply patch, create settings
3. Load patron again, try to apply payment < 1000, no alert.
4. Apply payment 1000 < X > 100000, you should be asked to verify that the amount is correct.
5. Apply payment over 100000, you will be told that the system will have none of this nonsense.
6. Change the OUS ("Payment amount threshold for Are You Sure? dialog.", "Maximum payment amount allowed."), repeat steps 3-6

Upon successful completion of step 6, rock out.

Further tests and signoffs appreciated.

Jason Boyer (jboyer) on 2016-01-19
tags: added: pullrequest
Jason Boyer (jboyer) on 2016-02-12
tags: added: webstaffclient
Jeanette Lundgren (jlundgren) wrote :

I plan to test on Friday's Bug Squashing Day...

Changed in evergreen:
assignee: nobody → Jeanette Lundgren (jlundgren)
Jeanette Lundgren (jlundgren) wrote :

Followed test plan, tested multiple threshold amounts and settings. Everything worked as described. All tests successful.

I have tested this code and consent to signing off on it with my email address, <email address hidden>, and name, Jeanette Lundgren

Changed in evergreen:
assignee: Jeanette Lundgren (jlundgren) → nobody
tags: added: signedoff
tags: added: billing
removed: bills
Kathy Lussier (klussier) on 2016-05-13
Changed in evergreen:
assignee: nobody → Kathy Lussier (klussier)
Kathy Lussier (klussier) wrote :

Jason,

It looks like this branch now has some merge conflicts. Can you resolve those?

I was hoping to test this today, but I'm removing myself as assignee since I just remembered that I need my web client test environment restored before I can fully test it. I'll try to take a look at it once we're able to get the web client installed again.

Kathy

Changed in evergreen:
assignee: Kathy Lussier (klussier) → nobody
Jason Boyer (jboyer) wrote :

That branch has been force-pushed and is now based on master as of today. (Also it's just 1 commit rather than 3, there really wasn't much point in that.)

Mike Rylander (mrylander) wrote :

Pushed to master. Thanks, Jason!

Changed in evergreen:
status: Triaged → Fix Committed
status: Fix Committed → Triaged
status: Triaged → Fix Committed
Ben Shum (bshum) on 2016-08-09
Changed in evergreen:
milestone: 2.next → 2.11-beta
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers