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

[Bug 39295] New: Patron card creator infinite loop during template/layout incompatibility
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39295 Bug ID: 39295 Summary: Patron card creator infinite loop during template/layout incompatibility Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org To reproduce: 0. Change Koha test user's firstnameto "Firstname" and surname to "Lastname" 1. Create a template: Units: PostScript Points Page height: 60pt Page width: 60pt Card height: 60pt Card with: 60pt Top page margin: 10pt Left page margin: 10pt Number of columns: 1 Number of rows: 1 Gap between columns: 10pt Gap between rows: 10pt 2. Create a layout: Units: US inches Field 1: Text: Library Name Font: Times-Roman Font size: 12 pt Text alignment: Left Lower left X coordinate: 100in Lower left Y coordinate: 100in Field 2: Text: <firstname> <surname> Font: Times-Roman Font size: 10pt Text alignment: Left Lower left X coordinate: 5in Lower left Y coordinate: 5in 3. Create a batch for borrowernumber 51 (if using "koha" test user in ktd) 4. Export using the above template and layout 5. Note that an infinite loop is triggered If you use strace, the syscalls produced during the loop will look like this: [pid 935276] newfstatat(AT_FDCWD, "/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf", {st_mode=S_IFREG|0644, st_size=705684, ...}, 0) = 0 [pid 935276] newfstatat(AT_FDCWD, "/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf", {st_mode=S_IFREG|0644, st_size=705684, ...}, 0) = 0 [pid 935276] newfstatat(AT_FDCWD, "/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf", {st_mode=S_IFREG|0644, st_size=705684, ...}, 0) = 0 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 37392] New: Edit item permission by library group is broken
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37392 Bug ID: 37392 Summary: Edit item permission by library group is broken 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 29523 The library groups allow to set up library groups within the staff users can edit each others items. This was introduced in 23.05, but is now broken in 23.11. It's not possible for a staff user to edit another libraries items now in some circumstances. Test plan: Set up library group: * Create a library group for library A + B * Action: Limit item editing by group Set up test user: * Create a staff patron with these permissions: * catalogue * fast_cataloguing * edit_items * view_borrower_infos_from_any_libraries * edit borrowers * Home library: library A Set up test items: * Create a record with 3 items with different home libraries: * A * B * C We expect the user will be allowed to edit A and B, but not C. Test: * Test editing the items with the test user, only A is allowed to be edited. * Remove the view_borrower_infos_from_any_libraries permission from test user. * Test editing items now behaves as expected: A + B are allowed, C is not. ----- After some digging to understand the change of behavior noticed between 23.05 and 23.11: I believe commit 2c502d32 to be the culprit. item.can_be_edit uses Patron::can_edit_item_from which calls can_see_things_from. The commit removed the library group specific code and introduced a call to libraries_where_can_see_patrons instead, probably assuming the thing was always a patron record. But here it is an item record. Thinking we should not use "thing" in method names without at least explaining what thing can be... Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29523 [Bug 29523] Add a way to prevent embedding objects that should not be allowed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 99

[Bug 39095] New: Clicking Cancel on opac-user for article requests does not respond
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39095 Bug ID: 39095 Summary: Clicking Cancel on opac-user for article requests does not respond Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Seeing this under 22.11 and 23.11. Master looks the same btw. The last column is dtr controlled. You must expand. At that moment the button Cancel appears under the table. Clicking Cancel does not trigger the click event? -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 39462] New: (bug 37870 follow-up) Default values from framework are inserted into existing record while editing
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39462 Bug ID: 39462 Summary: (bug 37870 follow-up) Default values from framework are inserted into existing record while editing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, m.de.rooy(a)rijksmuseum.nl Depends on: 37870 Due to changes made by the commit 0472b56a671, when editing an existing bibliographic record a default value is inserted while it should not, according to ApplyFrameworkDefaults systempreference. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37870 [Bug 37870] UI/Form/Builder/Item.t and Biblio.t are still failing randomly (cn_source sort) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 39304] New: Jenkins not failing when git command fails
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39304 Bug ID: 39304 Summary: Jenkins not failing when git command fails Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Test Suite Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org We edited the config and it broke the git repo: 13:32:35 koha_1 | error: unable to normalize alternate object path: /srv/jenkins/workspace/Koha_Source/.git/objects 13:32:35 koha_1 | fatal: not a tree object 13:32:35 koha_1 | [12:29:31] xt/check_makefile.t So tests were not running correctly -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 39750] New: Wrong transfer breaking check in when using branch transfer limits
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39750 Bug ID: 39750 Summary: Wrong transfer breaking check in when using branch transfer limits Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation 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, kyle.m.hall(a)gmail.com To recreate: 1 - Enable UseBranchTransferLimits based on 'Collection code' 2 - Disable transfers for FIC from: CPL -> FFL CPL -> IPT FFL -> CPL FFL -> IPT IPT -> CPL IPT -> FFL 3 - Set library to IPT 4 - Checkin an FFL item 5 - It generates a transfer home 6 - Set library to CPL 7 - Check the item in 8 - 500 error, and in logs: ==> /var/log/koha/kohadev/plack-error.log <== Exception 'Koha::Exceptions::Item::Transfer::Limit' thrown 'Transfer not allowed' -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 38203] New: Split the purpose of RENEWAL and AUTO_RENEWALS_DGST notices.
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38203 Bug ID: 38203 Summary: Split the purpose of RENEWAL and AUTO_RENEWALS_DGST notices. Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org As bug 29382 points out RENEWAL is sent in parallel with AUTO_RENEWALS_DGST when the autorenewals script runs providing message preferences are set (and RenewalSendNotice is enabled… not mentioned in that bug). We recently enabled AllowRenewalLimitOverride and I configured RENEWAL to use TT code to send appropriately worded notices for renewals of interlibrary loans, notforloan items issued, and for other loan items manually renewed. My (wrong) expectation was that the DGST notice would go out from 01:30 when our autorenewals script runs, and the RENEWAL would go out only and whenever an item was manually renewed. If auto-renewal is enabled then we are wasting useful functionality that could use RENEWAL to notify of (perhaps special cases of) manual renewal if the purpose of the two notices were separated. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 39014] New: Storing a guarantee fails due to TrackLastPatronActivityTriggers "creating a patron"
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39014 Bug ID: 39014 Summary: Storing a guarantee fails due to TrackLastPatronActivityTriggers "creating a patron" Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lmstrand(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Adding a new guarantee and storing it fails with "Creating a patron" selected in TrackLastPatronActivityTriggers when guarantors are set to be mandatory. Feature was added in ticket 23486. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 73

[Bug 38345] New: Remove support for OpenSearch
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38345 Bug ID: 38345 Summary: Remove support for OpenSearch Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Truth is our test suite has been exploding consistently when trying to launch OpenSearch: * https://jenkins.koha-community.org/job/Koha_Main_OS2/ * https://jenkins.koha-community.org/job/Koha_Main_OS1/ This has some precedent discussion on [issue 429](https://gitlab.com/koha-community/koha-testing-docker/-/issues/429) in `KTD` project issues. We are not going to remove it, I guess. But some noise is needed as people using OpenSearch in production don't seem to care we are not being able to run the test suite, so probably promising some 'OpenSearch support' that we cannot guarantee in any way. And if there's a problem with OpenSearch, we (devs) cannot launch a working environment to fix/test. My two cents on this matter. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 67

[Bug 37796] New: Generated issue has incorrect number in pattern when receiving
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37796 Bug ID: 37796 Summary: Generated issue has incorrect number in pattern when receiving Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 170927 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170927&action=e… Incorrect number on generated issue Discovered while testing Bug 35646 To Replicate 1. Follow Bug 35646 and create a numbering pattern for {MonthName} {Year}. 2. Test the pattern for a 1/month frequency, subscription start date on the first day of the month. See that the numbering pattern increments correctly for the month names and year. 3. Find a serial in the catalog and add a new subscription. 4. On the second page of the subscription configuration, select the numbering pattern for MonthName Year. 5. Test the prediction pattern and see everything increments correctly. 6. Save the subscription. 7. Receive. See the the first issue displays correctly for the month name and year. 8. Mark the issue as arrived and generate the next issue. See the next issue does not have the correct month name and year. (image attached). 9. Mark the next issue Arrived and generate the third issue. The date published and number continue to increment incorrectly. Possibly connected to bug 20653, though this example is not irregular. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44