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

[Bug 38309] New: Cannot delete additional fields
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38309 Bug ID: 38309 Summary: Cannot delete additional fields Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To recreate: 1 - Browse to Administration->Additional fields 2 - Click 'Invoices (aqinvoices)' 3 - Click 'New field' 4 - Fill out form and save 5 - See the new fiellisted 6 - Click 'Delete', confirm 7 - Screen goes blank 8 - Try to click 'Additional fields' in breadcrumb, no action 9 - Click 'Administration' in breadcrums 10 - Go to Additional fields->Invoices 11 - Your field is still there -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 37961] New: Inventory followup fails by POSTing without an op or csrf_token
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37961 Bug ID: 37961 Summary: Inventory followup fails by POSTing without an op or csrf_token Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Keywords: regression, rel_24_05_candidate Severity: major Priority: P1 - high Component: Tools Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 After you upload a file or textarea of barcodes to inventory, the next step is a list of the things that were missing, with checkboxes to check when you find them, and buttons to Mark seen, which send a POST to /cgi-bin/koha/tools/ajax-inventory.pl without an op param (since it doesn't have an $op) and without a csrf_token, so the POST fails with a 403. 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 16

[Bug 37914] New: Forms for budget planning filters and export should GET rather than POST
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37914 Bug ID: 37914 Summary: Forms for budget planning filters and export should GET rather than POST Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Acquisitions Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 Blocks: 37728 Because of the bug 36192 CSRF protection, we intend not to have forms that POST without a param named 'op' with a value starting with 'cud-'. Because of bug 37728, a few were missed, including the 'Filters' form that lets you switch between planning budgets by month or by itemtype or by library, and the 'Export' form that lets you save your planning as a .csv file. Neither one has any need to POST, they can just be the GET they naturally are. 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 37959] New: Item circulation alerts table appears to be broken
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37959 Bug ID: 37959 Summary: Item circulation alerts table appears to be broken Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com To replicate: 1. Click on a cell in the table. The cell changes to save "Saving..." and then appears to become stuck. Nothing ever happens. Refreshing the page returns to the table to its original state. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 37887] New: OPAC password recovery needs to use a cud- op while POSTing new password
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37887 Bug ID: 37887 Summary: OPAC password recovery needs to use a cud- op while POSTing new password Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: OPAC Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 Blocks: 37728 The intention of the CSRF protection from bug 36192 was that any form that used method="post" would have to have a param named 'op' which started with 'cud-' but the test that verifies they do missed the case of a template with more than one form. Bug 37728 corrects that, but to land, the things that currently fail the test need to be fixed. In opac-password-recovery.tt that's the fairly critical step where the user sets a new password. Luckily, getting there requires the uniqueKey that's sent in the recovery email, and if someone has access to that you've already lost the game, so it's not really a security issue, just something that needs to be fixed. 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 14

[Bug 37853] New: Returning to your account at the end of changing your password in the OPAC doesn't need to POST a form
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37853 Bug ID: 37853 Summary: Returning to your account at the end of changing your password in the OPAC doesn't need to POST a form Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: OPAC Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 Blocks: 37728 The end of the UI flow of changing your password in the OPAC is a page which tells you your password was changed (good, you need to know it's time to log out and back in to change your saved password, or that it's time to scribble out the old one on a Post-it and write down the new one), and then offers to take you back to your account with a button in a form which does a POST to opac-user.pl without an op and with your borrowernumber, which is double-bad. We intend not to allow POST without an op, and once the test is fixed in bug 37728 this will fail, and there's no need for the borrowernumber since it will be completely ignored by the script, which will instead get it from your cookie or make you log in. Instead of a form+button+POST, it should just be a link. 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 13

[Bug 37827] New: Switch OPAC download list form from POST to GET
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37827 Bug ID: 37827 Summary: Switch OPAC download list form from POST to GET Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: OPAC Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 Blocks: 37728 We meant to not have any forms that post without an op starting with cud-, but because of bug 37728 we missed a few, like the hidden form to download a list in the OPAC. There's no visible reason why it even needs a form to submit, rather than just having the menu be a list of links the way the staff client does it, but that's a problem for another bug. Here, we just need to switch it from a post to a get, so we can land the fix to the test for things posting without a cud- op. 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 13

[Bug 37794] New: Fix form that POSTs without an op in Holds to pull
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37794 Bug ID: 37794 Summary: Fix form that POSTs without an op in Holds to pull 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: gmcharlt(a)gmail.com, kyle.m.hall(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 Holds to pull, that's the form that lets you choose different start and end dates. Having it do a GET instead doesn't add much bookmark or link benefit, since the params are actual dates rather than something like -5d, but at least it lets you refresh the page without a browser warning about repeating a POST. 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 37785] New: Remove dead code in tools/letter.tt that looks like a form that would POST without an op
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37785 Bug ID: 37785 Summary: Remove dead code in tools/letter.tt that looks like a form that would POST without an op 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 tools/letter.tt that's two forms, https://git.koha-community.org/Koha-community/Koha/src/commit/4f52463551632… which is shown IF ( add_validate or copy_validate) and one a bit further down at #L594 which is shown IF ( delete_confirmed ). To someone that knows how are templates work, that would sound like either the op which wants to show them would be add_validate or copy_validate or delete_confirmed, or more likely in the current era it would be cud-add_validate etc., which either sets the param add_validate, or was broken by the change to cud-ops. These two are different, though. If you look back through blame history for every change to letter.pl for the ops in question, they have never, ever, let their op be defined for a template to show a confirmation message. Currently they do "$op = q{}; # we return to the default screen for the next operation", if you go back to the dawn of time, prior to rel_3_0 moved to HEAD, they started out doing "print $input->redirect("letter.pl");". I'd like to have a better term than "dead code" for something which has been unreachable since it was copy-pasted from some other template, but I can't come up with an inoffensive one. 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 13

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

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37769 Bug ID: 37769 Summary: Fix forms that POST without an op in currency 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. In Currency and exchange rate administration, that's the "OK" button that takes you back to the list when you try to delete a currency in use by a vendor, which doesn't need to POST, and the OK button in the confirmation page after you delete a currency, which currently doesn't actually show at all, but when it does doesn't need to POST since it just takes you back to the list of currencies. 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