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

[Bug 39287] New: Improve "Show volume" search with a more specialized search index
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39287 Bug ID: 39287 Summary: Improve "Show volume" search with a more specialized search index Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement 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: m.de.rooy(a)rijksmuseum.nl, michaela.sieber(a)kit.edu Currently the rcn index used to search for volumes contains all $w subfields from 7xx and 8xx linking fields. In some cases this is too broad, even tho we are additionally limiting to monographs. Example: Search volumes will also find - records with a 775$w - other edition - records with a matching 780/785$w - preceeding or succeeding ... A specific index for searching volumes (rcn-volumes) should contain: - 773$w (we still need to limit to monographic, because these could also be analytcal links) - 800$w - 810$w - 811$w - 830$w Once the index is defined we can update the XSLT and the method for determining if the "Show volumes" link should be shown to use it and have a correct result list. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 36808] New: Slips should be a message transport type
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36808 Bug ID: 36808 Summary: Slips should be a message transport type Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Currently we create entirely new notices for SLIP type notices when really they're just a different medium and thus should be a message transport type. I propose adding a SLIP message transport type and where appropriate merging the current SLIP notices into their corresponding non-slip counterparts. A 'slip' is just a small form printer and likely to have similar summary detail as an SMS for example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 36809] New: DRY out notice and slip printing
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '25

11 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36809 Bug ID: 36809 Summary: DRY out notice and slip printing Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We have a plethora of slip and notice printing controllers and templates. This makes it difficult to improve the notices tools and not miss area's.. we should really move to one or two definitive scripts and templates for printing slips and notices and remove all the duplicate unmaintained code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 30343] New: Any failed delivery method in overduerules.pl produces a printed notice in attachment.txt
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '25

11 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30343 Bug ID: 30343 Summary: Any failed delivery method in overduerules.pl produces a printed notice in attachment.txt Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Previously we had only used the e-mail delivery method in overduerules.pl. This worked great. When a patron didn't have an e-mail address, a printed notice was added to the attachment.txt file for printed notices. Now we have phone and sms added as delivery methods. However, if ANY of these fail (no SMS number or no primary phone, or in the case of Twilio, if the same notice is sent via e-mail or sms, the phone status shows as deleted to prevent duplication) a printed notice is added to the attachment.txt file for printed notices. There should be option to determine if a printed notice is generated if ANY of the other methods fail, or if ALL of the methods fail. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 38615] New: Cancelling a waiting hold via SIP should include an option to move it to holds with cancellation requests
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '25

10 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38615 Bug ID: 38615 Summary: Cancelling a waiting hold via SIP should include an option to move it to holds with cancellation requests Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org You can cancel a hold via SIP, the hold is immediately canceled. There should be an option ( system preference ) to allow cancelled waiting holds from SIP to move to 'Holds with cancellation requests'. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 40399] New: Add desk ID to statistics and pseudonymized_transactions
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '25

10 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40399 Bug ID: 40399 Summary: Add desk ID to statistics and pseudonymized_transactions Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hebah(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Desks provide a great way for libraries to gauge service point staffing, but that isn't tracked in statistics or pseudonymized transactions. Adding a desk ID to transactions in those tables would make that data meaningful and reportable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 36947] New: Diacritics and upper case letters should not affect how facets get alphabetized
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '25

10 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36947 Bug ID: 36947 Summary: Diacritics and upper case letters should not affect how facets get alphabetized Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: lmstrand(a)gmail.com When you search with Elasticsearch, keywords/names beginning with diacritics such as " Šostakovitš, Dmitri" end up last in facets. The diacritics should be ignored when sorting the facets. Also upper case letters get alphabetized first in the facets, following the lower case letters (facets show A-Z first, then a-z). This is an issue specially with keywords (names, cities, countries). A fix for this would be uppercasing the values and dropping the diacritics when comparing values in sorting. ps. There's a ticket with a patch trying to solve the same thing made when Koha still used Text::Unaccent for Zebra in bug 26614. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 122

[Bug 38494] New: Koha should consider authority heading use in cataloging
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '25

10 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38494 Bug ID: 38494 Summary: Koha should consider authority heading use in cataloging Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P3 Component: MARC Authority data support Assignee: januszop(a)gmail.com Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In MARC 21 authority records, three bytes (008/14-16) indicate what the heading can be used for (main/added entry, subject entry, series entry). Koha should be able to respect the record's intended use in authority search during cataloging, provided that the authority file is well formed. Also, we should be able to decide between more strict but correct behavior and current lax behavior. -- You are receiving this mail because: You are watching all bug changes.

1 49

[Bug 38108] New: Staff interface holdings table - table navigation only shows when "Show filters" is selected
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '25

09 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38108 Bug ID: 38108 Summary: Staff interface holdings table - table navigation only shows when "Show filters" is selected Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In current main (October 2024), the holdings table for a record in the staff interface does not show the standard DataTable navigation elements until "Show filters" is clicked. I think that the standard table navigation elements should be shown by default. To replicate: 1. Go to a record in the staff interface with multiple items (for example record 146, The definitive guide to Catalyst : writing extensible, scalable, and maintainable Perl-based Web applications <staffinterfaceurl>/cgi-bin/koha/catalogue/detail.pl?biblionumber=146). 2. In the holdings table section, note that you have to click on "Show filters" for the standard table navigation elements to display: Showing 1 to 4 of 4 entries ------------------------------------- Show 20 entries First Previous Next Last Search: _______ Clear filter .... Other notes: 1. Behavour for previous versions - note that before 24.05.00 and bug 33568, all items were shown without any pagination, even for hundreds of items: . 24.05.00: navigation only shown once "Show filters" is clicked . 23.11.06: partial table navigation "Showing 1 of 1 entries Search______ Clear filter" . 23.05.14: the same as 23.11.06 2. Bug 33568 - Use the REST API to display items on the staff biblio detail view: totally rewrote the display of the items table -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 55

[Bug 35467] New: NewsLog should be renamed
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '25

09 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35467 Bug ID: 35467 Summary: NewsLog should be renamed 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The system preference NewsLog should indicate that it logs changes from news, html customizations, or pages. It should be renamed accordingly. AdditionalContentsLog ? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28