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

[Bug 9031] Overdue items crossing DST boundary throw invalid local time exception
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '26

06 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9031 Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=39748 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41345] New: Regression: Clicking the 'Ignore' button on hold found modal for already-waiting hold does not dismiss the modal (again)
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '26

06 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41345 Bug ID: 41345 Summary: Regression: Clicking the 'Ignore' button on hold found modal for already-waiting hold does not dismiss the modal (again) 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 To recreate: 1 - place a hold 2 - check in an item that can fill the hold 3 - in the hold found modal, click Ignore 4 - the modal dismisses and nothing changes on the hold (this is the desired behavior) 5 - check in the item again, click Confirm Hold, confirm your hold is now Waiting 6 - check in the item again, confirm the modal says "Item is already waiting" 7 - click Ignore, confirm modal reloads 8 - click Ignore, confirm modal reloads 9 - click Ignore, confirm modal reloads -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 40951] New: Optionally show reserve_id to users in the staff interface
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '26

06 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40951 Bug ID: 40951 Summary: Optionally show reserve_id to users in the staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com, trevor.diamond(a)mainlib.org The action logs for holds use the reserve_id for "object," which makes the reserve_id necessary for most searching one might want to do in that log. Unfortunately, there's no way to see that reserve_id in the staff interface without a report. For users who spend a lot of time looking at hold logs, it'd be helpful to be able to see the reserve_id from a patron's hold history and a biblio's list of current holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 40112] New: Problem when adding an authority after perform Link authorities automatically in a bibliographic record
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '26

06 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40112 Bug ID: 40112 Summary: Problem when adding an authority after perform Link authorities automatically in a bibliographic record Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org There's a problem when adding an authority following perform Link authorities automatically in a bibliographic record. When we add a subject authority, if there is more than one general subdivision ($x), the second one is not transposed in the authority addition form. When added manually, it does not maintain the position it was assigned when added after registration. To test: 1.Create a bibliographic record 2.Enter a subject authority 650: $aHealth services $xReform $zQuebec (Province) $xHistory 3.Click on Link authorities automatically (No matching authority found) 4.Click on the small + to add an authority 5.In the add authority form, on field 150, it show's only these : $aHealth services $xReform $zQuebec (Province) 6.Add a $xHistory and position it after $zQuebec (Province) 7.Save -->The authority will be displayed as follows: $aHealth services $xReform $xHistory $zQuebec (Province) This is not the correct order. It should be displayed as follows: $aHealth Services $xReform $zQuebec (Province) $xHistory -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 8937] Translation process removes CDATA in RSS XML
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '26

06 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8937 Hammat wele <hammat.wele(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41361] New: Incorrect markup in category code confirmation modal
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '26

06 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41361 Bug ID: 41361 Summary: Incorrect markup in category code confirmation modal Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 32581 Bug 32581 introduced a new modal asking whether to update the patron's expiration date when changing the patron category. This modal uses older Bootstrap markup and doesn't work right. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32581 [Bug 32581] Update dateexpiry on categorycode change -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 8937] Translation process removes CDATA in RSS XML
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '26

06 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8937 Hammat wele <hammat.wele(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #194708|0 |1 is obsolete| | --- Comment #14 from Hammat wele <hammat.wele(a)inlibro.com> --- Created attachment 194718 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194718&action=e… Bug 8937: Translation process removes CDATA in RSS XML During template translation, CDATA sections in RSS templates are not handled consistently. When parsing RSS content containing Template Toolkit directives inside CDATA blocks, the CDATA markers (<![CDATA[ ... ]]>) are only preserved only for the <title> tag. To reproduce 1. Install the other language (i used fr-CA here) 1.1. gulp po:update fr-CA 1.2. /misc/translator/translate install fr-CA 2. open and compare files that contain <!CDATA in description example: ./koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-opensearch.tt ./koha-tmpl/opac-tmpl/bootstrap/fr-CA/modules/opac-opensearch.tt 3. In the fr-CA file the description tag ==> the <!CDATA is removed 3. Apply the patch 4. Repeat step 1.2, 2 and 3 ==> the <!CDATA is not removed -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8937] Translation process removes CDATA in RSS XML
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '26

06 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8937 Hammat wele <hammat.wele(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8937] Translation process removes CDATA in RSS XML
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '26

06 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8937 --- Comment #13 from Hammat wele <hammat.wele(a)inlibro.com> --- Created attachment 194708 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=194708&action=e… Bug 8937: Translation process removes CDATA in RSS XML During template translation, CDATA sections in RSS templates are not handled consistently. When parsing RSS content containing Template Toolkit directives inside CDATA blocks, the CDATA markers (\<![CDATA[ ... ]]>) are only preserved only for the <title> tag. To reproduce 1. Install the other language (i used fr-CA here) 1.1. gulp po:update fr-CA 1.2. /misc/translator/translate install fr-CA 2. open and compare files that contain <!CDATA in description example: ./koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-opensearch.tt ./koha-tmpl/opac-tmpl/bootstrap/fr-CA/modules/opac-opensearch.tt 3. In the fr-CA file the description tag ==> the \<!CDATA is removed 3. Apply the patch 4. Repeat step 1.2, 2 and 3 ==> the \<!CDATA is not removed -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8937] Translation process removes CDATA in RSS XML
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '26

06 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8937 Hammat wele <hammat.wele(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs(a)lists.koha-commun |hammat.wele(a)inlibro.com |ity.org | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0