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:
parent
1b1c8cacfb
commit
d45d4912e8
1 changed files with 1 additions and 0 deletions
|
@ -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">
|
||||
|
|
Loading…
Reference in a new issue