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

[Bug 40078] New: C4::Scrubber should allow for list (ul/ol and li) HTML tags
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '26

10 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40078 Bug ID: 40078 Summary: C4::Scrubber should allow for list (ul/ol and li) HTML tags Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org We added support for some additional tags support in the 'note' type scrubbed fields, but we didn't expose lists. I see no security risk with allowing those tags, please correct me if I'm incorrect there, so I think we should allow these too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 40077] New: C4::Scrubber should allow for list (ul/ol and li) HTML tags
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '26

10 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40077 Bug ID: 40077 Summary: C4::Scrubber should allow for list (ul/ol and li) HTML tags Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org We added support for some additional tags support in the 'note' type scrubbed fields, but we didn't expose lists. I see no security risk with allowing those tags, please correct me if I'm incorrect there, so I think we should allow these too. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 40717] New: Notes scrubber is too strict for some cases
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '26

10 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40717 Bug ID: 40717 Summary: Notes scrubber is too strict for some cases Change sponsored?: --- 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: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 31165 added scrubbing to course reserves public note Many libraries use the public note to link to courses on their website, other resources, etc. Additionally bug 33337 talks about scrubbing patron public notes, but those are also used sometimes for links, such as other patrons that can check out their items but not guarantaurs. I recommend changing it to something like what Lucas did on Bug 38960 https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=183774&action=d… which allows for some links but is not all links: a => { href => qr{^(?:https?://|/cgi-bin/|mailto:|#)}i, class => qr/^[\w\s\-_]+$/, title => 1, target => qr/^_(?:blank|self|parent|top)$/, rel => qr/^(?:nofollow|noopener|noreferrer|noindex|bookmark|tag|prev|next|up|alternate|author|help|license|search)$/, property => qr/^[\w\s]+$/, typeof => qr/^[\w\s]+$/, resource => qr/^[#\w\-_]+$/, }, -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 42042] New: Add HTML Customization option for patron account Messaging page
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42042 Bug ID: 42042 Summary: Add HTML Customization option for patron account Messaging page Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries would like to provide additional information about messaging, which might be required by third-party messaging services. It would be nice if there was an HTML customization option to add some custom text above the Your messaging settings table. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 40792] New: Do not fill hold requests when issuing non-holdable items
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40792 Bug ID: 40792 Summary: Do not fill hold requests when issuing non-holdable items Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com It is a regression from bug 38650 that issuing non-holdable items now fills holds. The subroutine C4::Reserves::MoveReserve would previously only do anything if there where a hold that had been filled with the specified item, which mean that the item issued was holdable. But bug 38650 opened up the possibility to fill the borrowers hold even if the issued item is not holdable. I suggest a check that the item issued is holdable if the biblio is reserved by the borrower. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 42045] New: Add ability to transfer order lines from one bib to another
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42045 Bug ID: 42045 Summary: Add ability to transfer order lines from one bib to another Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: catrina(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org While orders can be transferred from one basket to another, they cannot be transferred from one bib to another. Use case: staff adds to a basket from an existing bib but they select the Large Print version, instead of the Regular Book version. There is no way to move the order now, other than cancelling the Large Print version and recreating the orderline on the Regular Book bib. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 40275] New: Add Koha::Patrons->find_by_identifier()
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40275 Bug ID: 40275 Summary: Add Koha::Patrons->find_by_identifier() Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org As suggested by Frido in some other context, I file this bug to introduce the mentioned sub. I resurrected the idea after tracking down some warnings in SIP, and identifying bug 36575 introduced them by calling `->find` without passing a primary key. This kind of errors/warns: ``` [2025/06/30 13:03:23] [24253] [ERROR] [undef]@[undef]: DBIx::Class::ResultSource::_minimal_valueset_satisfying_constraint(): Unable to satisfy requested constraint 'primary', missing values for column(s): 'borrowernumber' at /kohadevbox/koha/Koha/Objects.pm line 98 C4::SIP::Trapper::__ANON__ /kohadevbox/koha/C4/SIP/Trapper.pm (70) ``` Instead of solving it locally, I propose to introduce a sane and tested method, and reuse it anywhere this pattern is being used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 42041] New: CatalogModuleRelink disregards ConsiderHeadingUse
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42041 Bug ID: 42041 Summary: CatalogModuleRelink disregards ConsiderHeadingUse Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl CatalogModuleRelink will link authorities that were previously linked regardless if ConsiderHeadingUse is enabled or not. This is perhaps working as it should. However, if a library decided they do want to enable ConsiderHeadingUse in order to clean up inappropriately linked headings, CatalogModuleRelink will interfere. To replicate: 1. Check system preferences and ensure ConsiderHeadingUse is set to don't, AutoLinkBiblios is set to do, CatalogModuleRelink is set to do. 2. Import an authority that is not currently in use, such as a subject authority for $a Application software $xDevelopment. 3. Edit a bibliographic record and add a heading to match the authority. 4. Save. See the authority links to the heading. 5. Change the system preference ConsiderHeadingUse to Do. Leave the remaining system preferences as previously set. 6. Refresh the page for the bibliographic record. See the heading relinks to the authority. 7. Delete the heading and save the record. 8. Edit the authority and change 008/15 to not appropriate. 9. Edit the bibliographic record and add the heading back and save. See that the heading re-links to the authority because it was previously linked. 10. Delete the heading in the bibliographic record and save. 11. Change the system preference CatalogModuleRelink to don't. 12. Edit the bibliographic record and add the heading back. Save. See the heading does not relink/link because the authority says it is not appropriate as a subject heading. 13. Edit the authority and update 008/15 to appropriate. 14. Edit the record and save. See the heading now links. >From what I can see, Koha is working the way it should based on the system preferences. Since CatalogModuleRelink might interfere with ConsiderHeadingUse, what should happen in an existing catalog in regards to linking? Should the recommendation be to disable CatalogModuleRelink when ConsiderHeadingUse is set to do? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 28761] New: Item status shows incorrectly on opac-course-details.pl
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28761 Bug ID: 28761 Summary: Item status shows incorrectly on opac-course-details.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: - create a course in course reserves, add an item to it. - confirm your item shows Available for its status on opac-course-details.pl - give your item a notforloan status - reload opac-course-details.pl, confirm its still "available" - give your item a restricted user status - reload opac-course-details.pl, confirm its still "available" - give your item a lost, damaged, or withdrawn status - reload opac-course-details.pl, these statuses *are* reflected Filing a separate bug for the staff client. -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 42029] New: Add diff support to RECALLS action logs
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '26

09 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42029 Bug ID: 42029 Summary: Add diff support to RECALLS action logs Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org Blocks: 37940 The action logging for the RECALLS module (Koha/Recall.pm) currently logs status-change actions (OVERDUE, EXPIRE, CANCEL, FILL) with simple string messages such as 'Recall status set to overdue'. These calls do not pass the $original parameter to logaction(), so no structured diff is generated in the action_logs.diff column. This bug covers updating the four logaction() calls in Koha/Recall.pm to pass the pre-change recall state as the sixth argument ($original), enabling before/after comparison in the action log viewer. Affected calls: - RECALLS/OVERDUE (Koha/Recall.pm ~line 437) - RECALLS/EXPIRE (Koha/Recall.pm ~line 454) - RECALLS/CANCEL (Koha/Recall.pm ~line 470) - RECALLS/FILL (Koha/Recall.pm ~line 486) Since Koha::Recall is a Koha::Object subclass, $self->unblessed can be captured before the status change and passed as $original. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37940 [Bug 37940] [OMNIBUS] All modification logged via action logs should include original to create JSON diff -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0