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

[Bug 33193] New: Book cover image visibility depends on the order of 856 fields
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33193 Bug ID: 33193 Summary: Book cover image visibility depends on the order of 856 fields Change sponsored?: --- Product: Koha Version: 22.11 Hardware: PC OS: Windows Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tuomas.kunttu(a)kouvola.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Book cover link is in Marc field 856 and book description link is in another 856 field. Whether the book cover image is visible depends on the order in which the data is catalogued. Test: 1. System preferences: CustomCoverImages: display and CustomCoverImagesURL: {856$u} 2. Catalogue following data to a record: 856 42 u https://sopimusasiakkaat.booky.fi/description.php?ean=9789518734263 q text z Description 856 42 u https://sopimusasiakkaat.booky.fi/image.php?size=medium&id=9789518734263 q image z Cover image 3. Save and view record 4. Book cover is not visible in record's normal view nor in search results list. 5. Change the order of 856 fields: 856 42 u https://sopimusasiakkaat.booky.fi/image.php?size=medium&id=9789518734263 q image z Cover image 856 42 u https://sopimusasiakkaat.booky.fi/description.php?ean=9789518734263 q text z Description 6. Save and view record 7. Book cover is visible in record's normal view and in search results list. Book cover image should be visible regardless of the order in which the 856 fields are catalogued. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 39763] New: Item search results should include note fields
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39763 Bug ID: 39763 Summary: Item search results should include note fields Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: inkeri.hakulinen+bugz(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org It is possible to add custom search fields to item search. (see bug See https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13823 ) You can even use wildcard characters with such a search. It would be important that those fields would be made visible in the search results, as well. I suppose a common use case is to add public and nonpublic notes to the custom search fields. However, those are not visible at the search results, and thus it's difficult to utilize the search results, and process the results further. I assume there will be some other use cases than note fields, as well. At least add those public and nonpublic note fields, but even better solution would be if you could customize which fields are shown in the results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20344] New: Transferring an item while on hold results in a transfer were the destination is the same as the source
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20344 Bug ID: 20344 Summary: Transferring an item while on hold results in a transfer were the destination is the same as the source Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com 1. Check out an item 2. Place a hold on the specific item with a pickup at a different branch 3. Check in: Confirm hold and transfert 4. Check the branchtransfers table to ensure that the transfert is here SELECT * FROM branchtransfers order by datesent DESC LIMIT 10; 5. Home › Circulation › Transfers 6. Create a transfer identical as the existing one 7. You should see «Item is already at destination library.» 8. Check the branchtransfers table 1. First one should have been canceled «Canceled, new transfer from A to A created» 2. Another one should have been created from A to A 3. These 2 things are the issue. Because doing the same without a hold - doesn't create a new transfer - doesn't cancel the first one -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 43430] New: Advanced editor omits a missing mandatory 008 when editing a record
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43430 Bug ID: 43430 Summary: Advanced editor omits a missing mandatory 008 when editing a record Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- The basic MARC editor renders an empty mandatory 008 when an existing MARC21 record does not contain that field. When the field receives focus, the MARC21 008 plugin initializes its 40 positions and provides the fixed-length controls. The advanced editor only loads fields that are present in the record. If 008 is physically absent, it displays no 008 line even when the selected framework marks 008 as mandatory. The cataloguer therefore cannot use the advanced editor's existing 008 widget and fixed-length controls. To reproduce: 1. Use MARC21 and enable EnableAdvancedCatalogingEditor. 2. In a bibliographic framework, mark tag 008 as mandatory and leave its default value empty. 3. Use an existing record in that framework which has no 008 field. 4. Open the record in the basic editor. An empty 008 input is present; focus it and note that it is initialized to a 40-character value. 5. Open the same record in the advanced editor. The 008 line is absent. The advanced editor should add one empty mandatory 008 and let its existing widget initialize the field just as the basic editor does. Editing an existing record must not reapply a non-empty framework default. Existing blank or populated 008 fields, optional missing 008 fields, new records, and duplication should keep their current behavior. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 36549] New: es_indexer_daemon.pl leaks memory
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36549 Bug ID: 36549 Summary: es_indexer_daemon.pl leaks memory Change sponsored?: --- Product: Koha Version: master 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 background_jobs_worker.pl runs its tasks in child processes which return their memory to the OS when they complete. es_indexer_daemon.pl runs everything in itself which means if it needs to allocate a large amount of memory for an indexing job, it will hold on to that memory allocation for its entire process life. -- I've got an es_indexer_daemon.pl which is using over 1GB of memory. Once it's done with its indexing activity, I'm going to restart it to get it back down to a more reasonable amount of allocated memory. I reckon we should be forking off child processes to do the worker. We don't need many. We just need 1 that is short lived so that it can return the memory back to the OS. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 41788] New: Make holds queue redirection optional
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41788 Bug ID: 41788 Summary: Make holds queue redirection optional Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Pushing https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36455 without an option to not use it has caused issues for libraries with large hold queues. Without having the ability to filter before running the queue, it can take a long time to generate the list, taking up other resources on the server. Once the queue finally renders, staff have to re-run the process with the limitations/filters in place. This needs to be a system preference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 46

[Bug 42033] New: Add diff support to patron restriction and circ message action logs
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42033 Bug ID: 42033 Summary: Add diff support to patron restriction and circ message 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 Several MEMBERS action log calls in Koha do not pass the $original parameter to logaction(), so no structured diff is generated in the action_logs.diff column. Affected calls: 1. Koha/Patron/Debarments.pm - CREATE_RESTRICTION (~line 89): logaction( "MEMBERS", "CREATE_RESTRICTION", $borrowernumber, $restriction ) (no $original; $restriction hashref is the new state) 2. Koha/Patron/Debarments.pm - DELETE_RESTRICTION (~line 113): logaction( "MEMBERS", "DELETE_RESTRICTION", $borrowernumber, $restriction ) (no $original; $restriction hashref is the state being deleted) 3. Koha/Patron/Message.pm - MODCIRCMESSAGE (~line 58): C4::Log::logaction( "MEMBERS", "MODCIRCMESSAGE", $self->borrowernumber, $self->message ) (passes new message text; should also pass original for diff) 4. Koha/Patron/Message.pm - ADDCIRCMESSAGE (~line 60): C4::Log::logaction( "MEMBERS", "ADDCIRCMESSAGE", $self->borrowernumber, $self->message ) 5. Koha/Patron/Message.pm - DELCIRCMESSAGE (~line 74): C4::Log::logaction( "MEMBERS", "DELCIRCMESSAGE", $self->borrowernumber, $self->message ) This bug covers updating these calls to pass structured data so the diff mechanism can generate proper before/after comparisons. 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 12

[Bug 17921] New: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17921 Bug ID: 17921 Summary: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Items that shouldn't be displayed in the OPAC are displayed in the shelf browser The links work as expected (redirect to opac-blocked or 404) but we should not display them in the first place -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 43378] New: Wrong hold can be selected when LocalHoldsPriority set to GiveLibraryAndGroup
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43378 Bug ID: 43378 Summary: Wrong hold can be selected when LocalHoldsPriority set to GiveLibraryAndGroup Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests 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, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Target Milestone: --- In C4::Reserves::CheckReserves: if ( !$local_hold_match && $LocalHoldsPriority eq ('GiveLibraryAndGroup') ) { # If there's no match at the library level, check hold groups $local_hold_group_match = Koha::Libraries->find( { branchcode => $local_holds_priority_item_branchcode } )->validate_hold_sibling( { branchcode => $local_holds_priority_patron_branchcode } ); } Then: # See if this item is more important than what we've got so far if ( ( $res->{'priority'} && $res->{'priority'} < $priority ) || $local_hold_match || $local_hold_group_match ) { next Then: last if $local_hold_match || ( ( $LocalHoldsPriority eq 'GiveLibraryGroup' ) && $local_hold_group_match ); That last condition needs to OR "eq 'GiveLibraryAndGroup'" - otherwise we are setting local_hold_group_match, but not exiting the loop, and we pick the local hold group match with the highest priority -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 43150] New: Deleting holidays on range may sometimes delete too many holidays
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43150 Bug ID: 43150 Summary: Deleting holidays on range may sometimes delete too many holidays Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: emmi.takkinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Noticed while working on bug 24782. When modifying holidays on range sometimes those modifications would seep into other holidays that aren't on given timeperiod. Tested some more and this can also happen with deleting holidays on range too. This really tricky to reproduce and it doesn't occur all the time, but here's one way to make this happen. 1. Make sure you have plack running. 2. Create three single holidays on a range. 3. Now delete last two of the just added holidays, use " Delete the single holidays on a range." tool. => Note that all holidays were deleted. => Add holidays for different timeperiods and delete them, note how deleting may affect holidays out of given timeperiod. We had a same problem with adding new holidays and it was fixed on bug 38357. This seems to be a same problem, @holiday_list is not reseted to an empty array so previously created/deleted/modif holidays are never cleared from plack workers memory. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8