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

Bug #1029601 reported by Jason Etheridge on 2012-07-26
This bug affects 12 people
Affects Status Importance Assigned to Milestone

Bug Description

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

Jason Etheridge (phasefx) wrote :

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

Jason Stephenson (jstephenson) wrote :

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

Changed in evergreen:
status: New → Triaged
Tim Spindler (tspindler-cwmars) wrote :

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
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) wrote :

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


but not

Firefox or Seamonkey

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.request_time, ahr.usr, ahr.requestor,, 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.usr=ahr1.usr
where ahr.request_time > '2018-01-01'::timestamp
and ahr1.usr=ahr1.requestor

order by ahr.request_time desc
limit 100;

Michele Morgan (mmorgan) wrote :

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.

Jane Sandberg (sandbej) on 2018-05-19
tags: added: opac
Andrea Neiman (aneiman) on 2018-09-14
tags: added: holds
Dan Pearl (dpearl) on 2018-12-07
Changed in evergreen:
assignee: nobody → Dan Pearl (dpearl)
Dan Pearl (dpearl) wrote :

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) wrote :;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.

tags: added: pullrequest
Changed in evergreen:
assignee: Dan Pearl (dpearl) → nobody
Changed in evergreen:
status: Triaged → Confirmed
milestone: none → 3.3-beta1
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.3.1
Michele Morgan (mmorgan) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers