double-clicking on Submit when placing holds from the TPAC result in duplicate holds

[Jason Etheridge]

I was able to duplicate this in a recent instance of master.

[Jason Etheridge (phasefx)]

I was also using Chrome; did not test in other browsers.

[Jason Stephenson (jstephenson)]

Needs confirmation from other sources with other browsers so a specific fix can be determined.

[Tim Spindler (tspindler-cwmars)]

EG Rel 2.4.3

We were able to reproduce this

A staff member was able to place 19 holds within seconds of each other with just 19 clicks. Here is their process:

1. Log into a patron OPAC account by going to bark.cwmars.org/eg/opac/login
2. search for an item: I usually use ‘CWMARS the movie’ as it is a test item
3. on the search results screen, press the ‘place hold’ button on the right side of the screen
4. on the next screen, click the submit button but press it again after waiting for a second or so
5. the next screen will have a message saying ‘User already has an open hold on selected item’. This is where multiple holds can be placed: click on the submit button and click on it again immediately after as many times as you want. Every time that you click will place another hold on the item for the patron.

He tested it in the following browsers

Chrome Yes
Internet Explorer Yes must click submit on override screen
Firefox No
Opera Yes must click submit on override screen
Safari Yes must click submit on override screen
SeaMonkey No

[Tim Spindler (tspindler-cwmars)]

It may not have been clear but he was able to reproduce this in:

Chrome
Opera
Safari

but not

Firefox or Seamonkey

[Josh Stompro (u-launchpad-stompro-org)]

Hello, I'm seeing evidence that some customers are placing multiple holds like described in this bug report using 2.10.6. But I'm having no luck replicating the problem.

When I test, I never get an override submit button, since our users don't have the hold exists override. I tested with Chrome and IE.

But when I look for duplicate patron placed holds I see 8 instances since the beginning of the year.

Sometimes they are within 20 seconds of each other, sometimes they show the exact same request time for multiple holds.

Query to find holds that look like they were placed by end users where duplicates exist.
select ahr.id, ahr.request_time, ahr.usr, ahr.requestor, ahr1.id, ahr1.request_time, ahr1.usr from action.hold_request ahr
join action.hold_request ahr1 on
  ahr.request_time between ahr1.request_time-'1 minute'::interval and ahr1.request_time+'1 minute'::interval
  and ahr.target=ahr1.target
  and ahr.usr=ahr1.usr
where ahr.request_time > '2018-01-01'::timestamp
and ahr.id!=ahr1.id
and ahr.id> ahr1.id
and ahr1.usr=ahr1.requestor

order by ahr.request_time desc
limit 100;

[Michele Morgan (mmorgan)]

Running Josh's query on our 2.12.4 system retrieves 20 instances of duplicate holds over the past 2 months, so it seems to be happening in our system also. I have not yet attempted to reproduce the problem.

[Dan Pearl (dpearl)]

There are two opportunities in the failing scenario for mischief. 1) The initial submit of the hold, followed within a few seconds by a resubmit, and 2) The final submit to override the restrictions and place the hold, gosh darn it!

In either case, it appears that disabling the Submit in the form's onsubmit attribute is an efficient solution (as it is client-side within the browser). It makes no sense to allow multiple Submits of the form in these contexts.

It works on Concerto in test db for me.

This will likely fix the related webclient bug, too, but we'll see. LP#1780298.

I'll put up a branch shortly.

[Dan Pearl (dpearl)]

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

This does seem to fix the corresponding staff client LP#1780298 as well. No mystery as the code is shared.

[Michele Morgan (mmorgan)]

We put this code on our production server earlier this week and are monitoring for creation of duplicate holds. If this fixes or greatly reduces the occurrence of duplicates, I'll sign off - unless someone else beats me to it.

[Jeff Davis (jdavis-sitka)]

This fix is working for us. Working branch user/jeffdavis/lp1029601_double_click_submit_signoff has a signoff:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jeffdavis/lp1029601_double_click_submit_signoff

[Jason Stephenson (jstephenson)]

I spent some time retesting the branch today on Evergreen 3.2 and I'm happy that it works. John Amundson here also looked at it.

I've pushed the fix to master, rel_3_3, rel_3_2, and rel_3_1 for double clickers everywhere!

Thanks, everyone!