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

[Bug 36678] New: Include fields with non-filing characters removed when indexing
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36678 Bug ID: 36678 Summary: Include fields with non-filing characters removed when indexing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com Created attachment 165438 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=165438&action=e… Sample record for testing Currently we only remove non-filing characters for sort fields, however, this can make searching difficult. Consider: L'amour de l'art : art contemporain et collections privées du Sud-Ouest. Currently a search for: amour de l'art will return no results in elastic search We should include the form with non-filing characters removed See also bug 21357 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 32565] New: Holds placed when all libraries are closed do not get added to holds queue if HoldsQueueSkipClosed and RealTimeHoldsQueue are enabled
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '25

24 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32565 Bug ID: 32565 Summary: Holds placed when all libraries are closed do not get added to holds queue if HoldsQueueSkipClosed and RealTimeHoldsQueue are enabled Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If HoldsQueueSkipClosed is enabled and a hold is placed on a day when all libraries are closed (e.g. a holiday), that hold doesn't get added to any holds queue, because there are no valid queues to add it to at the time. This did not matter with the build-holds-queue cronjob, because the job would just add it to the queue later; however, if RealTimeHoldsQueue is also enabled, that hold will not get added to the holds queue when the libraries reopen unless something triggers a holds queue update on that biblio record, potentially leading to holds stuck in limbo. The exception is a hold that has copies available at the pickup location - those types of holds will still get added to the holds queue even if all libraries are closed. To recreate: 1. Enable RealTimeHoldsQueue and set HoldsQueueSkipClosed to satisfy holds from libraries only when they are open 2. Add a holiday to the calendar for all libraries for today 3. Place a biblio-level hold on a biblio record and set the pickup location to a library that has available copies 4. Verify that that hold got added to the holds queue 5. Place a bilbio-level hold on a biblio record where there are no other holds and copies are available at another location, but not the pickup location 6. Verify that that hold was not added to any holds queue 7. Remove the holiday (or wait for the next day) and verify that the hold from step 5 is still not on the holds queue This could be solved by adding a check to the real-time holds queue to check whether all libraries are closed, and ignore HoldsQueueSkipClosed when that is the case. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 62

[Bug 35402] Update the OPAC and staff interface to Bootstrap 5
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35402 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |40222 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40222 [Bug 40222] Bootstrap popover components not updated for BS5 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 26467] New: Allow multiple display locations to be added in news tool
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26467 Bug ID: 26467 Summary: Allow multiple display locations to be added in news tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When configuring a news items for display you can leave the display location blank, which adds your news item in all possible display locations OR you can select a single display location. It would be neat if you could select multiple display locations for a news item. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 37964] New: Only show host items when system preference EasyAnalyticalRecords is enabled
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37964 Bug ID: 37964 Summary: Only show host items when system preference EasyAnalyticalRecords is enabled Change sponsored?: --- 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl After Bug 33496, host items are displayed even when system preference EasyAnalyticalRecords is disabled. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 33075] New: Add ability to mark an item as floating
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33075 Bug ID: 33075 Summary: Add ability to mark an item as floating Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Circulation Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 40216] New: 773$w isn't exported by OAI/PMH
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40216 Bug ID: 40216 Summary: 773$w isn't exported by OAI/PMH Change sponsored?: --- Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)mmk-hagen.de QA Contact: testopia(a)bugs.koha-community.org I run into a strange problem and suspect this to be a bug in Koha. We are using Koha 24.11.02. Wenn exporting all records with export_records.pl the field 773$w shows up in the export whichever record has it set. When I get the latest changes by OAI/PMH e.g. 'verb=ListRecords&from=2025-06-16T04:00:00Z&until=2025-06-16T10:00:00Z&metadataPrefix=marcxml' most of the records are missing 773$w, though it should be set. Other subfields of 773 (773$t and 773$x) are exported. Just 773$w is missing. Though, a few records (1 out of 10) has 773$w set. Is there any explaination for it? I compared the two marcxml for a single record in Koha, the one exported by export_records.pl and the one delivered by an OAI/PMH update. They are almost identical except for the missing 773$w and some minor xml formating Let me know if you need more information, e.g. an example of a record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 40215] New: Shareable link in inventory is broken
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40215 Bug ID: 40215 Summary: Shareable link in inventory is broken Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Steps to reproduce: 1 - Make an inventory 2 - Click on shareable link 3 - The link is the first page of inventories. The shareable link should be deactivated here but I did not find any functionality in the code, is there a way I missed ? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 34963] New: Unable to delete notes in suggestions
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34963 Bug ID: 34963 Summary: Unable to delete notes in suggestions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org It doesn't appear possible to delete a note in a suggestion, although it is possible to edit it. To reproduce, create a suggestion record and add a note and non-public note. Edit the suggestion and change the contents of your notes, and save. The notes will both correctly update to your new note text. Now edit the suggestion again and this time completely delete the note. The data does not get deleted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 36420] New: REST API Basic Auth does not support cardnumbers, only userid
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36420 Bug ID: 36420 Summary: REST API Basic Auth does not support cardnumbers, only userid Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com CC: tomascohen(a)gmail.com Every other part of Koha supports logging in either a userid or cardnumber. The REST API should support this for basic auth as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22