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

[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

[Bug 37080] New: Cannot delete a MARC bibliographic framework
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37080 Bug ID: 37080 Summary: Cannot delete a MARC bibliographic framework Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl On current main (and 24.05) you cannot delete a MARC bibliographic framework. Reported on chat (13 June 2024) for 24.05.00 and reproduced on main. Steps to reproduce: 1. Go to Koha administration > Catalog > MARC bibliographic frameworks. 2. For a framework, select Actions > Delete. 3. Message displayed: "Confirm deletion of framework '' ()?" (with options under this - "Yes, delete this framework" and "No, do not delete") (note that the URL has the framework code /cgi-bin/koha/admin/biblio_framework.pl?op=delete_confirm&frameworkcode=ACQ) 4. Click "Yes, delete this framework". 5. Error message displayed: "An error occurred when deleting this framework. Check the logs for details." 6. Nothing in the logs that seems of any help (/var/logs/koha/kohadev/* - where kohadev is the instance name). Other observations: 1. If you create a new framework (without adding any MARC structure) and attempt to delete, you get the same error. So not related records using the framework. 2. No JavaScript or other browser console errors using the browser's web development tools. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 37093] New: 403 Forbidden Error when attempting to search for Mana Reports
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37093 Bug ID: 37093 Summary: 403 Forbidden Error when attempting to search for Mana Reports Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Mana-kb Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com CC: alex.arnaud(a)biblibre.com We are running 24.05 and have found then when we attempt to search the Mana kb for a report, we are getting a 403 Forbidden Error. Steps to reproduce: 1. have mana set up 2. Go to reports, create a new report from mana 3. Use a term to search 4. receive a 403 forbidden error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 37069] New: Authorities pagination on OPAC broken by CSRF
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37069 Bug ID: 37069 Summary: Authorities pagination on OPAC broken by CSRF Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 36597] New: Cannot delete circulation desk
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36597 Bug ID: 36597 Summary: Cannot delete circulation desk Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: major Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36192 Our CSRF work introduced a problem with deleting circulation desks: The "delete_confirm" does not need "cud-" because it's a GET operation leading to a POSTed deletion after the confirmation is submitted. 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 12