Bug 37783: Fix form that looks like it would POST without an op in reserve/request.tt

We intend not to have forms with method="post" without an op variable (so we
can check that the op starts with "cud-" as part of the CSRF protection), but
because of bug 37728 some were missed.

In reserve/request.tt the modal for cancelling a hold looks like it is a form
that will do a POST without an op input, but in fact it requires JavaScript to
work at all, and with JavaScript it clears out the div where it stashes inputs
and then inserts one with the op cud-cancel.

To persuade the test at xt/find-missing-op-in-forms.t that there is an op,
and to let a casual skimmer of the code see what that op will be, without
actually changing the behavior in any way, we can just stick the op in the
div which the JS will .empty() out before sticking the same thing back in.

Test plan:
1. Search for any record with an item, click Place hold, place two holds
2. In the row for the second hold, click the trash can icon to delete
3. Nothing changed from normallly cancelling a hold, did it? It shouldn't
   have.

Sponsored-by: Chetco Community Public Library

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de>
This commit is contained in:
Phil Ringnalda 2024-08-29 18:17:12 -07:00 committed by Katrin Fischer
parent 1b1c8cacfb
commit d45d4912e8
Signed by: kfischer
GPG key ID: 0EF6E2C03357A834

View file

@ -1443,6 +1443,7 @@
<form id="cancel_modal_form" method="post" action="request.pl">
[% INCLUDE 'csrf-token.inc' %]
<div id="inputs">
<input type="hidden" name="op" value="cud-cancel">
</div>
<div class="modal-body">