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

[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 43519] New: Direct links to article request form still work when the feature is disabled
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43519 Bug ID: 43519 Summary: Direct links to article request form still work when the feature is disabled Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- When ArticleRequests are turned off, the page in the OPAC should no longer be reachable by direct link. .../cgi-bin/koha/opac-request-article.pl?biblionumber=xxx There is also no error on saving the form. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 43513] New: Add .mailmap entries for Lawrence O'Regan-Lloyd
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43513 Bug ID: 43513 Summary: Add .mailmap entries for Lawrence O'Regan-Lloyd Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: loreganlloyd(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- My first patch was pushed with my GitHub handle as the author name, so docs/history.txt and docs/contributors.yaml both record me as "lawrenceol-clams" rather than my name. Also, I also have another a second email address that I plan to use for Koha contributions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[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 43625] New: Modal for compare in logs says "Compare preference values" but it isn't only used for preferences
by bugzilla-daemon＠bugs.koha-community.org 24 Sep '26

24 Sep '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43625 Bug ID: 43625 Summary: Modal for compare in logs says "Compare preference values" but it isn't only used for preferences Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- To recreate: Turn on report log Make a report Change a report Change the report again go to tools->log viewer run the tool, Click the compare button in the info column on the 2 most recent changes and hit 'compare' Observe the modal says "Compare preference values" instead of "Compare report values" Do the same for a notice, go edit it twice, run the logs, select the 2 most recent and compare and observe the same message. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[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