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

[Bug 34136] New: Add ability to render a report using a notice template
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34136 Bug ID: 34136 Summary: Add ability to render a report using a notice template Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Sometimes it is useful to display the results of a report in a non-table format. We should be able to create notice templates to render reports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 43190] New: Staff with only fast_cataloging permission no longer directed to 'Add item' screen when creating a Fast Add record from checkout
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43190 Bug ID: 43190 Summary: Staff with only fast_cataloging permission no longer directed to 'Add item' screen when creating a Fast Add record from checkout Initiative type: --- Sponsorship --- status: Product: Koha Version: 26.05 Hardware: All OS: All Status: NEW Keywords: regression Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- In 26.05, a staff member who only has the Fast cataloging (fast_cataloging) permission under the Edit catalog (Modify bibliographic/holdings data) (editcatalogue) umbrella is no longer directed to the Add item screen after creating a Fast Add bib from the checkout screen. To recreate: -Find/create a staff member with full circulation permissions, and only fast_cataloging from the editcatalogue group. -As that staff member, try to check out a nonsense barcode to a patron. -Click the '+Add record using fast catalog' button. -Add bib information, then save the record. -Note that you're returned to the bib detail screen for the bib you just created instead of the 'Add item' screen. From here, the staff member can only add an item by clicking Edit > Manage items. On that screen, the barcode they originally entered isn't pre-populated, and they aren't returned to the checkout screen once the item is added. Staff with the top-level editcatalogue permissions don't appear to have a change in behavior from 25.11: from using '+Add record using fast catalog' at checkout, they can create a fast add bib and then are directed to the 'Add item' screen with the barcode pre-populated. Once they save the item, they're returned to the checkout screen, and the item checks out automatically. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 41419] New: Error javascript "undefined" is not valid JSON when showing the order edit modal in orderreceive.tt
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41419 Bug ID: 41419 Summary: Error javascript "undefined" is not valid JSON when showing the order edit modal in orderreceive.tt Initiative type: --- Sponsorship --- status: 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: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org to reproduce 1. Go to Acquisitions → New vendor, enter a name, check Vendor is Active, and click Save. 2. Click the name of the vendor you just created in the table. 3. Click New → Basket, enter a basket name, and click Save. 4. Click Add to basket → From a new (empty) record. Enter a title, add an item, and click Save. 5. Click Close basket. 6. Click Receive shipments, enter a number in the Vendor invoice field, and click Next. 7. Click Receive for the created line. 8. Open the browser console. 9. In the modal, tick the Receive? checkbox and click Confirm. 10. Go to the previous page → The console shows the error: "undefined" is not valid JSON at JSON.parse (<anonymous>) was shown 11. Apply the patch 12. Go to Acquisitions → Search for the vandor created on step 2 13. Repeat step 3, 4, 5, 6, 7, 8, 9, 10 → There is no js error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 32209] New: Item subfields required even when supplied for each order
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32209 Bug ID: 32209 Summary: Item subfields required even when supplied for each order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When using MarcItemFieldsToOrder to populate order information while staging records you can set things up to supply an itemtype, however, if the itemtype field is required, you still must select one on the items tab To recreate: See bug 32166 - use file and settings to add to basket form a staged file Note you must still populate the itemtype on the second tab -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 26129] New: Add a new 'configurations' table
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26129 Bug ID: 26129 Summary: Add a new 'configurations' table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org This table should be designed from the beginning to allow global and per-library configuration entries. It would replicate the circulation_rules schema, but adapted to be a(n eventual) replacement for system preferences. This came up on my development for an SMTP configuration page, in which I originally added an smtp_servers page, that could really be generalized like this for other uses. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 97

[Bug 38621] New: [% today %] variable unavailable in report templates
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38621 Bug ID: 38621 Summary: [% today %] variable unavailable in report templates Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I tried adding a date to a report template, but it doesn't seem to work. I was told on MM that this is a bug. To recreate: 1. Create a report notice template with [% today %] 1.1. Go to Tools > Notices and slips 1.2. Click New notice > Reports 1.3. Enter a code and a name 1.4. Click Email 1.5. Enter a subject 1.6. In the message body, add some info with [% today %], here is what I used [% USE KohaDates %] [% today | $KohaDates %] [% FOREACH d IN data %] [% d.title %] [% END %] 1.7. Click Save 2. Create a report that works with this template 2.1. Go to Reports > Create from SQL 2.2. Enter a report name 2.3. In the SQL field, enter a report that would work with the template, this is what I used SELECT * from biblio limit 1 2.4. Click Save report 3. Click Run with template > Template name --> The date doesn't appear I also tried with a the simple [% today %] without the USE and without the KohaDates filter, but it doesn't show the date either. If I don't put the USE but use the filter, the template simply doesn't work (when you click Run with template > Template name, the report is displayed as normal in table form). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 36154] New: Add images to the lists and loan histories
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36154 Bug ID: 36154 Summary: Add images to the lists and loan histories Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthias.le-gac(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Display images in lists and loan histories in both OPAC and the staff interface, similar to when conducting a search. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 76

[Bug 37440] New: Add option to never default to Cataloging Search
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37440 Bug ID: 37440 Summary: Add option to never default to Cataloging Search Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Staff find the Cataloging Search interface unhelpful. It offers relatively little functionality that is not available in the default search interface and is broadly less familiar and therefore less desirable. While one is in the Cataloging module, the header defaults to Cataloging Search but also offers Search the Catalog. We'd love to have the option to make Search the Catalog the default with Cataloging Search available as an option should we ever want it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 37438] New: Add option to define header quick action preference on Place a Hold page of staff interface
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37438 Bug ID: 37438 Summary: Add option to define header quick action preference on Place a Hold page of staff interface Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When looking at a biblio record, the header bar generally defaults to "Search catalog" but changes to "Check out" when one places a hold. Our staff have found themselves generally more likely to want to perform another search after a hold, rather than perform a checkout. As such, this default action is adding an extra click after every hold. To recreate: 1 - find a bib record, look at it (/cgi-bin/koha/catalogue/detail.pl?biblionumber=XXX) 2 - observe that while you're on the Normal tab the header offers "Search catalog" 3 - click to MARC, ISDB, Items, Checkout History, Modification Log, or Rota 4 - observe that the header continues to default to Search 5 - click Holds (/cgi-bin/koha/reserve/request.pl?biblionumber=XXX) 6 - Now the header defaults to "Check out" We'd love a system preference to allow us to change this default so that the header defaults to Search for all parts of the bib record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 23562] New: Only one authorities search in header
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23562 Bug ID: 23562 Summary: Only one authorities search in header Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In authorities module, header contains 4 authorities search, from "main heading $a" to "entire record". This is more a search option than really different searches. I propose to merge them into only one with a select for where to search. This allow to always keep current search options. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15