- 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 28957] Many plugins require the full plugins permission set to run
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28957 --- Comment #17 from Luis Bataller <luis.bataller(a)xercode.es> --- Created attachment 207388 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207388&action=e… Plugin for test plugin permissions Sure Lissete. Here's the test plugin (PermissionsDemo.kpz) to try the new hook. Each method just prints "<method>: OK". * Install the .kpz * Create a staff user with only edit_items permission (no plugins permissions). * Log in as that user and open: 1- /cgi-bin/koha/plugins/run.pl?class=Koha::Plugin::Es::Xercode::PermissionsDemo&method=tool&option=items 2- /cgi-bin/koha/plugins/run.pl?class=Koha::Plugin::Es::Xercode::PermissionsDemo&method=tool 3- /cgi-bin/koha/plugins/run.pl?class=Koha::Plugin::Es::Xercode::PermissionsDemo&method=catalog * Without the patch: all three are denied. * Apply the patch, restart_all: 1- OK (edit_items is enough) 2- denied (falls back to plugins > tool) 3- denied (needs edit_catalogue) * Add edit_catalogue permission to the user: "3" is now OK. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28957] Many plugins require the full plugins permission set to run
by bugzilla-daemon＠bugs.koha-community.org 06 Oct '26

06 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28957 --- Comment #16 from Luis Bataller <luis.bataller(a)xercode.es> --- Created attachment 207387 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=207387&action=e… Plugin for test plugin permissions -- You are receiving this mail because: You are watching all bug changes.

1 0

[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 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

[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 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