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

[Bug 38184] New: OpacTrustedCheckout module does not show due date
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38184 Bug ID: 38184 Summary: OpacTrustedCheckout module does not show due date Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org To reproduce: 1. Enabled OpacTrustedCheckout system preference 2. Search for an item and get the barcode 3. Go to the OPAC 4. Click the Self-checkout button at the top 5. Enter the barcode and submit 6. Notice that the due date does not show in the modal, even though the due date was correctly set -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 37392] New: Edit item permission by library group is broken
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37392 Bug ID: 37392 Summary: Edit item permission by library group is broken Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major 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: kyle(a)bywatersolutions.com, m.de.rooy(a)rijksmuseum.nl, martin.renvoize(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 29523 The library groups allow to set up library groups within the staff users can edit each others items. This was introduced in 23.05, but is now broken in 23.11. It's not possible for a staff user to edit another libraries items now in some circumstances. Test plan: Set up library group: * Create a library group for library A + B * Action: Limit item editing by group Set up test user: * Create a staff patron with these permissions: * catalogue * fast_cataloguing * edit_items * view_borrower_infos_from_any_libraries * edit borrowers * Home library: library A Set up test items: * Create a record with 3 items with different home libraries: * A * B * C We expect the user will be allowed to edit A and B, but not C. Test: * Test editing the items with the test user, only A is allowed to be edited. * Remove the view_borrower_infos_from_any_libraries permission from test user. * Test editing items now behaves as expected: A + B are allowed, C is not. ----- After some digging to understand the change of behavior noticed between 23.05 and 23.11: I believe commit 2c502d32 to be the culprit. item.can_be_edit uses Patron::can_edit_item_from which calls can_see_things_from. The commit removed the library group specific code and introduced a call to libraries_where_can_see_patrons instead, probably assuming the thing was always a patron record. But here it is an item record. Thinking we should not use "thing" in method names without at least explaining what thing can be... Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29523 [Bug 29523] Add a way to prevent embedding objects that should not be allowed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 99

[Bug 38203] New: Split the purpose of RENEWAL and AUTO_RENEWALS_DGST notices.
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38203 Bug ID: 38203 Summary: Split the purpose of RENEWAL and AUTO_RENEWALS_DGST notices. Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org As bug 29382 points out RENEWAL is sent in parallel with AUTO_RENEWALS_DGST when the autorenewals script runs providing message preferences are set (and RenewalSendNotice is enabled… not mentioned in that bug). We recently enabled AllowRenewalLimitOverride and I configured RENEWAL to use TT code to send appropriately worded notices for renewals of interlibrary loans, notforloan items issued, and for other loan items manually renewed. My (wrong) expectation was that the DGST notice would go out from 01:30 when our autorenewals script runs, and the RENEWAL would go out only and whenever an item was manually renewed. If auto-renewal is enabled then we are wasting useful functionality that could use RENEWAL to notify of (perhaps special cases of) manual renewal if the purpose of the two notices were separated. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 38345] New: Remove support for OpenSearch
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38345 Bug ID: 38345 Summary: Remove support for OpenSearch Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Truth is our test suite has been exploding consistently when trying to launch OpenSearch: * https://jenkins.koha-community.org/job/Koha_Main_OS2/ * https://jenkins.koha-community.org/job/Koha_Main_OS1/ This has some precedent discussion on [issue 429](https://gitlab.com/koha-community/koha-testing-docker/-/issues/429) in `KTD` project issues. We are not going to remove it, I guess. But some noise is needed as people using OpenSearch in production don't seem to care we are not being able to run the test suite, so probably promising some 'OpenSearch support' that we cannot guarantee in any way. And if there's a problem with OpenSearch, we (devs) cannot launch a working environment to fix/test. My two cents on this matter. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 67

[Bug 37796] New: Generated issue has incorrect number in pattern when receiving
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37796 Bug ID: 37796 Summary: Generated issue has incorrect number in pattern when receiving Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 170927 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170927&action=e… Incorrect number on generated issue Discovered while testing Bug 35646 To Replicate 1. Follow Bug 35646 and create a numbering pattern for {MonthName} {Year}. 2. Test the pattern for a 1/month frequency, subscription start date on the first day of the month. See that the numbering pattern increments correctly for the month names and year. 3. Find a serial in the catalog and add a new subscription. 4. On the second page of the subscription configuration, select the numbering pattern for MonthName Year. 5. Test the prediction pattern and see everything increments correctly. 6. Save the subscription. 7. Receive. See the the first issue displays correctly for the month name and year. 8. Mark the issue as arrived and generate the next issue. See the next issue does not have the correct month name and year. (image attached). 9. Mark the next issue Arrived and generate the third issue. The date published and number continue to increment incorrectly. Possibly connected to bug 20653, though this example is not irregular. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 44

[Bug 19704] New: OPACs most popular feature is displaying links to items set to be hidden in the opachiddenitems syspref which gives 404 errors when links are clicked
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19704 Bug ID: 19704 Summary: OPACs most popular feature is displaying links to items set to be hidden in the opachiddenitems syspref which gives 404 errors when links are clicked Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org When a library item has multiple bibliographic records and associated items with differing item types (e.g. fiction and express fiction and non-fiction) the Most popular feature is displaying links to items which are set to be hidden in the opachiddenitems syspref. When the user clicks on the link to these items a 404 error is displayed to the user. Therefore the most popular feature is incorrectly displaying links to hidden items. -- You are receiving this mail because: You are watching all bug changes.

1 35

[Bug 17704] New: OAI-PMH compatiblity with Ubuntu Xenial and Debian Stretch
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17704 Bug ID: 17704 Summary: OAI-PMH compatiblity with Ubuntu Xenial and Debian Stretch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Actually OAI-PMH in Koha uses HTTP::OAI lib from version in Jessie 3.27. This module is not compatible with version 4.03 which is in Ubuntu Xenial and Debian Stretch. You get the error : Can't call method "start_element" on an undefined value at /usr/share/perl5/HTTP/OAI/Response.pm line 114 This is because the method HTTP::OAI::Response::generate() has changed, it needs an argument $driver. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 60

[Bug 30913] New: Show itemtype notforloan with ILS-DI service GetRecords
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30913 Bug ID: 30913 Summary: Show itemtype notforloan with ILS-DI service GetRecords Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Discovery services like EBSCO's EDS use the GetRecords ILS-DI service, but the "notforloan" there only includes item-level notforloan and not item-type notforloan. In theory, they should use GetAvailability for availability but I can see why they'd use GetRecords since it has so much more information and that way they can do 1 API call instead of 2. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 21731] New: t::lib::QA::TemplateFilters missing built-in TT filter "xml" causes false warnings
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21731 Bug ID: 21731 Summary: t::lib::QA::TemplateFilters missing built-in TT filter "xml" causes false warnings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org I'm getting the following warning from the QA script: missing_filter at line 15 ( <div style="white-space:pre">[% record | xml %]</div>) I clearly do have an xml filter there. Josef has said it's because it's missing from t::lib::QA::TemplateFilters. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 34021] New: Add option to search within results on the opac interface
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '26

16 Jan '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34021 Bug ID: 34021 Summary: Add option to search within results on the opac interface Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org related: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27546 In 22.11 has been added the option of searching within results of a search, it should be nice to add also to opac. Or even it could be improved with the chance of search within subcollections.. It should be great if a search could be filtered by default via itypetype, ccode or anyother value in item or perhaps and biblio and koha keeps the filter in all searches of a user does. For example: if a library have a special collection of old books, and a user starts a search limiting by collection, let the filter on and being able to search within results now a facet filter od ccode limitation is lost when launch a search BR -- You are receiving this mail because: You are watching all bug changes.

1 27