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

[Bug 38008] New: Presentation CSS on <label> makes it hard to use for radio buttons and Flatpickr
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '25

06 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38008 Bug ID: 38008 Summary: Presentation CSS on <label> makes it hard to use for radio buttons and Flatpickr Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org In the case I'm trying to fix, Cataloging - Inventory, there are radio buttons for Home library or Current library, so the way radio buttons work those phrases should be the <label>s, so that clicking them toggles the buttons themselves. But the presentation of the whole page is geared to CSS for label, with only a little of it for .label, which assumes that whenever you have <fieldset class="rows"> ... <label> you will want that label to float: left and text-align: right, etc. Flatpickr is a somewhat similar problem: the project has decided that people who want to have the id in their dummy <input> which Flatpickr hides and replaces with its input transferred to the Flatpicker input are silly, because you can just wrap a label around the thing it is for, rather than having a sibling label with a for attribute pointing to the id of the input. But because of the floating and text-aligning, etc., of label, if you have <label>Set inventory date to: <input class="flatpickr"/></label> you get a ton of unwanted inherited presentation. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 36749] New: Link field to authorities removes subfield $e in advanced editor
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '25

06 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36749 Bug ID: 36749 Summary: Link field to authorities removes subfield $e in advanced editor Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mnero(a)oslri.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When linking a heading in advanced editor (Ctrl+shift+l), selecting "Choose" will link the heading, adding the $9, but will also delete all $e relationship designator fields. This does not happen in the basic editor. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 39926] New: Blocker users without edit_catalogue permission from deleting the record if no items remain from the batch item deletion tool at the script level
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '25

06 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39926 Bug ID: 39926 Summary: Blocker users without edit_catalogue permission from deleting the record if no items remain from the batch item deletion tool at the script level 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl This is in response to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39848#c14 Bug 39848 blocked this in the template but it would be better if we blocked it higher up, in the script. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 38204] New: Add an API endpoint to list baskets
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '25

05 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38204 Bug ID: 38204 Summary: Add an API endpoint to list baskets Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 37

[Bug 22501] New: OPAC course reserves notes should allow html links
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '25

05 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22501 Bug ID: 22501 Summary: OPAC course reserves notes should allow html links 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 Target Milestone: --- Some libraries have been using the public notes field to point to electronic resources, this functionality has been removed by HTML filtering the content. We should allow the use of a $raw filter on these fields as they can only be entered by staff -- You are receiving this mail because: You are watching all bug changes.

1 32

[Bug 40013] New: Allow custom/plugable filtering options for OPAC ILL table
by bugzilla-daemon＠bugs.koha-community.org 05 Jun '25

05 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40013 Bug ID: 40013 Summary: Allow custom/plugable filtering options for OPAC ILL table Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: tadeusz(a)sosnierz.com QA Contact: testopia(a)bugs.koha-community.org CC: pedro.amorim(a)openfifth.co.uk, tomascohen(a)gmail.com Switching the OPAC ILL table in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39600 to client-side rendering gives us an opportunity to have plugins (or just using OPACUserJS) introduce custom filtering behaviour to the new table. All we need to allow this to happen is to have an editable additional_filters specified in there somewhere. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 35275] New: Include Item Templates in Batch Item Modification
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '25

04 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35275 Bug ID: 35275 Summary: Include Item Templates in Batch Item Modification Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl With the introduction to Item Templates, it would be great to include the template feature in the Batch Item Modification tool. So libraries could easily update a batch of items with the same values within a save Item Template. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 22938] New: Public Notes on an Item that are on Course Reserve to show up on catalogue/detail.pl page
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '25

04 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22938 Bug ID: 22938 Summary: Public Notes on an Item that are on Course Reserve to show up on catalogue/detail.pl page Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Currently, when a public note is added to an item when it is put on Course Reserve, this public note is only visible when the user is seeing this item in the Course Reserve module course-details.pl or the OPAC opac-course-details.pl. It would be very helpful to also see this public note from the detail.pl page for circulation staff. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 39931] New: OPAC Sorting by Publication Year (264$c) Does Not Work Correctly
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '25

04 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39931 Bug ID: 39931 Summary: OPAC Sorting by Publication Year (264$c) Does Not Work Correctly Change sponsored?: --- Product: Koha Version: 24.11 Hardware: PC OS: Windows Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: shahrum.alias(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 182559 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=182559&action=e… Publication Date: Newest to Oldest / Oldest to Newest not indexing properly In Koha version 24.11, sorting search results by publication year (newest to oldest/oldest to newest) in the OPAC does not work as expected, even though the correct data exists in MARC field `264$c`. The issue appears to be related to how the publication year is indexed or handled during OPAC search result sorting. ### Steps to Reproduce: 1. Enter bibliographic records with valid publication years in MARC field `264$c`. 2. Rebuild Zebra/Elasticsearch index. 3. Perform a general search in the OPAC. 4. Attempt to sort by "Publication Date: Newest to Oldest and oldest to newest". #### Expected Result: - Results should be sorted by publication year descending (e.g., 2024, 2023, 2022). #### Actual Result: - Sorting appears incorrect or inconsistent. - Records do not appear in chronological order by publication year. ### Additional Information: - I have verified that the data is present and sortable via direct SQL query using XPath and regex extraction. - Indexing configuration seems to map `264$c` to `publication_date`, but sorting behavior does not reflect this. - Rebuilding the index did not resolve the issue. - This affects user experience in the public OPAC where accurate sorting by publication date is critical. ### Suggested Fix / Enhancement: 1. Ensure that `264$c` is properly mapped in the Search Engine Configuration for use in `publication_date`. 2. Confirm that the value is normalized and indexed as a numeric field (e.g., only the 4-digit year) for proper sorting. 3. Consider adding documentation or warnings if certain MARC subfields are known to cause issues with sorting/indexing. ```If anyone has experienced this issue before or found a solution, please share your insights!``` -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 32506] New: Prevent creation of same fund code within a single budget
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '25

03 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32506 Bug ID: 32506 Summary: Prevent creation of same fund code within a single budget Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org When adding funds to a single budget, staff should not be able to create two funds using the same fund code. This happened at our library and wasn’t discovered until we had received titles in the two duplicate fund codes. We then had to combine everything into the one fund code. Keeping the fund codes unique would prevent confusion and staff time it took to fix our mistake. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1