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

[Bug 28297] New: can't save system preference and field not marked as modified when changing value
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '26

18 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28297 Bug ID: 28297 Summary: can't save system preference and field not marked as modified when changing value Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com == Test plan == 1. Search any syspref that has a text input 2. input a value, like 3, you see "modified" 3. save 4. refresh (tech note: the <input> will now have value=3) 5. input 5, you see "modified" 6. save (tech note: the <input> still has value=3, this is the cause) 7. input 3, you don't see "modified" (this in wrong) 8. save 9 "nothing to save", this is wrong -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 42317] New: [CVE-2014-1626] Require MARC::File::XML > 1.0.2
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '26

18 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42317 Bug ID: 42317 Summary: [CVE-2014-1626] Require MARC::File::XML > 1.0.2 Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CVE-2014-1626 notes vulnerabilities in MARC::File::XML in versions less than 1.0.2. Looking at Koha's cpanfile we say that we require at least version 1.0.1, but that should be updated to 1.0.2 or even 1.0.5 since in practice only 1.0.5 is really available via CPAN or Debian repos. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 43095] New: Patron card creator dies on CODE39MOD and CODE39MOD10 barcode types (missing Algorithm::CheckDigits import)
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '26

18 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43095 Bug ID: 43095 Summary: Patron card creator dies on CODE39MOD and CODE39MOD10 barcode types (missing Algorithm::CheckDigits import) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: chris.nighswonger(a)veritassuperaitsolutions.com Reporter: chris.nighswonger(a)veritassuperaitsolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- C4::Patroncards::Patroncard::_draw_barcode() calls CheckDigits('code_39') and CheckDigits('siret') for the CODE39MOD and CODE39MOD10 barcode types (Patroncard.pm lines 434 and 437), but the module never imports Algorithm::CheckDigits. Compare C4::Labels::Label, which has: use Algorithm::CheckDigits qw( CheckDigits ); at line 7. C4::Patroncards::Patroncard has no such line. Both CheckDigits() calls sit *outside* the internal eval that guards the PDF::Reuse::Barcode call (the eval begins at line 440), so selecting either checksum barcode type in a patron card layout dies at runtime: Undefined subroutine &C4::Patroncards::Patroncard::CheckDigits called at C4/Patroncards/Patroncard.pm line 434. To reproduce: create a patron card layout with barcode type CODE39MOD (or CODE39MOD10) and print/export a batch, or run the extended t/db_dependent/Patroncards/t_Patroncard.t from Bug 41719, whose draw_barcode() subtest exercises all five supported barcode types and fails on these two. The fix is a one-line import. This was surfaced by the rendering test coverage work on Bug 41719, which will depend on this bug so its barcode-type coverage passes. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 43104] New: When manually transferring an item with a hold "Cancel hold and attempt transfer" option does not transfer item
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '26

17 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43104 Bug ID: 43104 Summary: When manually transferring an item with a hold "Cancel hold and attempt transfer" option does not transfer item Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Depends on: 36762 Target Milestone: --- To recreate: - have an item at Branch A - place a hold on it for pickup at Branch B - without checking the item in to capture it, attempt to manually transfer the item to Branch C - the offered options include "Cancel hold and attempt transfer." Click this options - observe that your hold has been cancelled but the item has not been transferred I suppose maybe this is the intended behavior and "Cancel hold and attempt transfer" really means "Cancel the hold so that I may subsequently attempt the transfer in a separate action." But it would make more sense to just go ahead and transfer the item as the user requested. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36762 [Bug 36762] Item not transferred correctly when there is a pending hold -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 40744] New: Don't give noisy warning when PatronSelfRegistration is turned off
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '26

17 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40744 Bug ID: 40744 Summary: Don't give noisy warning when PatronSelfRegistration is turned off Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz We have several instances on one server. Some are using patron self registration, others do not. Now when cleanup_database.pl is run, we get a warning in the logs: Self-registrations cannot be removed, system preference PatronSelfRegistrationDefaultCategory is not set This is unnecessary, as for the libraries in question PatronSelfRegistration is OFF and PatronSelfRegistrationExpireTemporaryAccountsDelay is set to 0. The pref description says: NOTE: This system preference requires the misc/cronjobs/cleanup_database.pl cronjob. Ask your system administrator to schedule it. No patrons will be deleted if you set the pref to zero or make it empty. So we are telling the script, it's OK, we don't want any deleted, and still get the noisy warning. This is unnecessary. The warning should only be given when PatronSelfRegistrationExpireTemporaryAccountsDelay is not empty or 0 and the PatronSelfRegistrationDefaultCategory is empty at the same time. We might also want to check for PatronSelfRegistration. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 54

[Bug 42194] New: Sharing a report to Mana does not give feedback
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '26

17 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42194 Bug ID: 42194 Summary: Sharing a report to Mana does not give feedback Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Mana-kb Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: alex.arnaud(a)biblibre.com After successfully sharing a report to Mana, the user is redirect to an empty page. It should be redirected to the list of report with a message telling that the report was correctly sent. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 34478] Full CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '26

17 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |42194 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42194 [Bug 42194] Sharing a report to Mana does not give feedback -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41878] New: No logs for grouping existing holds or ungrouping a hyperhold
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '26

17 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41878 Bug ID: 41878 Summary: No logs for grouping existing holds or ungrouping a hyperhold Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com When grouping existing holds into a hyperhold or when ungrouping a hyperhold, the actions aren't logged, which is going to make troubleshooting extremely difficult (or impossible, depending on the issue). Hold groups are assigned an ID which shows in logs as hold_group_id when other changes are made to the hold, but grouping/ungrouping itself isn't logged. To replicate: -Place 2 or more holds for a patron (regular, not grouped) -Find the reserve_id for one of the holds, and view it in Tools > Logs. There will be an entry for the hold's creation. -From the patron's account, select the holds and click 'Group selected' -Run the log for the reserve_id, and note that there was not an entry generated by putting the hold into a group -Suspend the hold, then view the log for that reserve_id. Note that the log entry for the suspension now includes the hold_group_id. -From the patron's hold tab, click on the number in the 'Hold group' column, then select 'Ungroup hold' -Run the log for the reserve_id, and note that there is no new entry for ungrouping the hold -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 42369] SQL Injection in reports/bor_issues_top.pl via the Filter request parameter (unvalidated string context, no placeholders)
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '26

17 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42369 --- Comment #10 from Fridolin Somers <fridolin.somers(a)biblibre.com> --- I see it in main (26.11) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42735] SQL Injection in reports/issues_stats.pl via PeriodTypeSel / PeriodDaySel / PeriodMonthSel / Filter parameters (unvalidated string context, no placeholders)
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '26

17 Jul '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42735 Fridolin Somers <fridolin.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to main |Needs documenting -- You are receiving this mail because: You are watching all bug changes.

1 0