February 2025 - Koha-bugs - lists.koha-community.org

[Bug 37779] New: Fix forms that POST without an op in tag moderation
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37779 Bug ID: 37779 Summary: Fix forms that POST without an op in tag moderation Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Tools Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 Blocks: 37728 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 tag moderation, there are two: the fallback form for testing whether a word has been approved or rejected when JavaScript is disabled so the normal AJAX code doesn't run (a brutal thing to write a test plan for), and the Filters form, which by POSTing prevents you from bookmarking the page for all reviews by a particular person, or all rejected tags, or anything else you might want to check without having to recreate the filter. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 37783] New: Fix form that looks like it would POST without an op in reserve/request.tt
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37783 Bug ID: 37783 Summary: Fix form that looks like it would POST without an op in reserve/request.tt Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Circulation Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, gmcharlt(a)gmail.com, jonathan.druart(a)gmail.com, kyle.m.hall(a)gmail.com, oleonard(a)myacpl.org Depends on: 36192 Blocks: 37728 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. One that the patched xt/find-missing-op-in-forms.t points at is the rather odd https://git.koha-community.org/Koha-community/Koha/src/commit/7342209b34d64… which isn't actually a standalone form: if you could submit it any way other than after the JavaScript at #L1851 alters it, it wouldn't actually do anything since it lacks both the op cud-cancel and also the reserve_id that it has to have to cancel a reserve. Assuming there's no real reason to have the JavaScript add the op, we could put it immediately after the [% INCLUDE 'csrf-token.inc' %] where it would usually be, but the funnier alternative is to put it inside the <div id="inputs"> for the test to see, and then since the first thing the JavaScript does is to .empty() that div before it puts it back in, the behavior would be unchanged but the test (and someone casually scanning the code) could see what the op will be without having to know that it will be deleted and then added right back. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 37767] New: Fix forms that POST without an op in Authority types
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37767 Bug ID: 37767 Summary: Fix forms that POST without an op in Authority types Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36192 Blocks: 37728 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 Authority types (the odd name for MARC authority frameworks), that's the "No, do not delete" cancel button when you decide not to go through with deleting a tag, which doesn't need to POST since all it does is take you back to where you were, and the OK button in the page that tells you the tag was deleted when you decide to go ahead, which currently doesn't even show, but when it does, it doesn't need to POST because it's just taking you back to where you were. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 37766] New: Fix forms that POST without an op in MARC bibliographic frameworks
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37766 Bug ID: 37766 Summary: Fix forms that POST without an op in MARC bibliographic frameworks Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: System Administration Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36192 Blocks: 37728 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 MARC bibliographic frameworks, that's the tag search form, which is very much not something that should or needs to POST, and doing so prevents bookmarking or linking to a search for a particular tag, and the cancel "No, do not delete" button in the confirmation page while deleting a subfield, which doesn't need to POST because it doesn't need to send anything other than what's needed to go back to where you were. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 37768] New: Fix form that POSTs without an op in itemtype administration
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37768 Bug ID: 37768 Summary: Fix form that POSTs without an op in itemtype administration Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: System Administration Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36192 Blocks: 37728 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. For itemtype administration, that's the "No, do not delete" cancel button when you decide not to delete an itemtype, which doesn't need to POST anything since it's just taking you back to the list of itemtypes Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 37765] New: Fix forms that POST without an op in systempreferences
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37765 Bug ID: 37765 Summary: Fix forms that POST without an op in systempreferences Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: System Administration Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36192 Blocks: 37728 There are two forms that have action="post" but do not send an op (so it can't be checked for whether its value starts with 'cud-') in systempreferences. Because of bug 37728, they weren't caught earlier. One is simple, the "No, do not delete" button while starting to delete a local preference. It doesn't need to post, and changing it to a get has no behavior change. The other is slightly more complicated: the "Yes, delete" button is supposed to then show a page saying "Data deleted" with a button to take you "Back to system preferences" but changing the op to cud-delete_confirmed left the part of the template unused, because it still thinks that delete_confirmed will be true when it needs to show that. Once the script sets delete_confirmed, the "Back to system preferences" button can just be a get. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 37409] New: Edit button for items in course reserves list doesn't work
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37409 Bug ID: 37409 Summary: Edit button for items in course reserves list doesn't work Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: maxeinergl(a)gcc.edu QA Contact: testopia(a)bugs.koha-community.org In a course reserve list in the staff interface, the edit button on individual items in the list doesn't actually offer the ability to edit the item's reserve information. Instead, it goes back to the typical "Add Items" screen where the user can enter a barcode or biblionumber. Through clicks here you can get to a place to edit, but it is the same as if you click "Add reserves" on the course details and enter a barcode/biblionumber already on the list. I don't believe this is the expected behavior when clicking the Edit button. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 37197] New: Batch patron modification from reports fails by using GET instead of POST
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37197 Bug ID: 37197 Summary: Batch patron modification from reports fails by using GET instead of POST Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression Severity: major Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 When you SELECT cardnumber FROM borrowers you get a Batch operations menuitem to send the results to Patron batch modification, but because of what looks like it might be an accidental change in https://git.koha-community.org/Koha-community/Koha/commit/8a20e0cb6a0efd6b9… they are sent in a GET with the op show (which no longer exists) rather than a POST with cud-show. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 37192] New: The item editor Action menu Print label fails because the op to add to a label batch is now cud-add
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37192 Bug ID: 37192 Summary: The item editor Action menu Print label fails because the op to add to a label batch is now cud-add Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression Severity: major Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: isabel.pineda(a)ds.edu.sv Depends on: 36192 Steps to reproduce: 1. Search the catalog for anything with results, click Edit items on any bib with an existing item. 2. Click the Actions menu at the left of any item, select Print label That 500 error you just saw happened because the Print label action opens a popup at /cgi-bin/koha/labels/label-edit-batch.pl?op=add&number_type=itemnumber&number_list=633 which used to create a new label batch with that item in it, but now falls through the code past the "$op eq cud-add" because other parts of the label batch UI want to POST things to add so the op changed to cud-add, and the attempt to add winds up in code that thinks you are editing an existing batch, and makes crashing assumptions about what will be defined. Given that we don't believe that creating a label batch is worthy of CSRF protection, and we don't believe that removing an item from an existing batch is worthy of CSRF protection, I would argue that we should just make the if for add be elsif ($op eq 'cud-add' || $op eq 'add') rather than go through all the gyrations necessary to open a popup and have it immediately and silently POST a form just to add an item to a newly created batch. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 37187] New: 2 problems with label batches
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37187 Bug ID: 37187 Summary: 2 problems with label batches Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: isabel.pineda(a)ds.edu.sv QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl After updating from version 23.11 to 24.05, I found 2 problems with label batches: 1. In the item view of a book, the option "Actions > Print label" is not working anymore. I have to go to the Cataloging module to create a new label batch from there. 2. I cannot delete label batches anymore: The "Delete"-button in the list of label batches is not working. And inside the label batch, the button "Delete label batch" is not working either. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25