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

[Bug 37938] New: Budgeted cost in new order form isn't honoring OrderPriceRounding
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37938 Bug ID: 37938 Summary: Budgeted cost in new order form isn't honoring OrderPriceRounding Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org To test: 1) Enable syspref OrderPriceRounding 2) in acquisitions, search vendors, pick one, look for an existing basket 3) Start creating an order line with vendor price 18.90 and a discount of 5 %. (don't submit) 4) "Budgeted cost" is 17.95. => this is wrong, it should be 17.96 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 41708] New: Actual costs on Receiving isn't honoring OrderPriceRounding
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41708 Bug ID: 41708 Summary: Actual costs on Receiving isn't honoring OrderPriceRounding 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: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org 1. Create a Test Vendor with the following settings: - Vendor is active - List prices include tax - Tax rate 7% - Discount 5% 2. New basket with the test vendor (not a standing order), create items when placing an order. 3. Add order, add from an existing record. 4. Select an item type, add item. 5. Select a fund. 6. Vendor price in the accounting details: 27.90 7. Save. Close basket. 8. Receive shipments - Receive a new shipment, add a vendor invoice 9. Receive the placed order a) no shipping costs b) click on Receive at the item c) The actual cost is 26.505. This is correct so far. d) The imaginary invoice shows 26.50. So we delete the last 5 in 26.505. 10. click "Confirm." 11. In the now displayed overview "Already Received," the actual costs are shown as 26.51 instead of the 26.50 that the vendor charged. (The same result is obtained if you explicitly overwrite the last 5 in step 9d with a 0, i.e., enter 26.500.) 12. Finish receiving. 13. Change the system preference “OrderPriceRounding“ to „Round“ or „Don’t round“, depending on what it was before. Repeat all steps. The (faulty) result for the Actual cost should be the same (which shouldn’t be the case). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 35114] New: Total on basketgroup can be different than basket details total
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35114 Bug ID: 35114 Summary: Total on basketgroup can be different than basket details total Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hello :) This patch aims rather to clarify and avoid display errors concerning the total of the basket. When totals are displayed on the basketgroup.pl view the total is calculated relative to the rounded estimated cost (ecost) - tax included or excluded. While on the basket.pl view in detail, the logic is to take the unit price (tax included or excluded) OR then the estimated cost - tax included or excluded. This can cause a slight difference of cents depending on whether the unit price is calculated or not compared to the estimated price calculated. All this depending on the rounding or not of the third decimal for the fields not calculated (OrderPriceRounding activated or not). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 20153] New: Add new column "source" in the authorities pages's result
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20153 Bug ID: 20153 Summary: Add new column "source" in the authorities pages's result 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: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl hi, It would be nice if we could add a new column in the results page of a search in authority's module.In this new column we could se the subfield 040 $a who show the Organization that performed the original cataloging. With this new column with this new column titled "source", like the column in the z39.50 search, we would not need to go back to the authority record to see if it's a locally created authority or if it's imported. Patrick. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 37744] New: MARC21slimUtils.xslt show-series has a wrong search index 'au' for 810$a
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37744 Bug ID: 37744 Summary: MARC21slimUtils.xslt show-series has a wrong search index 'au' for 810$a Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: olli-antti.kivilahti(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Using Elasticsearch 810$a is not indexed in Elastic search mappings as an 'author'-index -field. 810 is mapped to the 'author-name-corporate'-index. 'author-name-corporate'-index is the correct index for 810-field. TEST PLAN: - Create a record with Fields 810$a and 810$t - A Series-link is generated in the biblio detail.pl and search results XSLT-views. - The link has a bad search query: (title-series:"Value from 810$t") (author:"Value from 810$a") -- 'author'-search doesnt find anything as the 810$a is not indexed to 'author'-index. - This patch changes the 'author'-search to 'author-name-corporate'-search, and the search returns results. Alternatively: It might be desirable to add 810$a to the 'author'-index. There is a specific search for 'author-name-corporate' using the advanced search. Related to: Bug 37743 - MARC21 810$t is used in XSLT templates but is not editable by default. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 25386] New: Internal server error when duplicate/too long barcodes are used in acquisition
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25386 Bug ID: 25386 Summary: Internal server error when duplicate/too long barcodes are used in acquisition 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When creating items on order or on receive there is a duplicate check for barcodes that usually detects if you are trying to reuse an already used barcode and prevents you from saving. But if you have used a barcode too long before and are not running with 'strict', the barcode will have been cut off at 20 characters. Now trying to create the next item with a too long barcode, where the 20 first characters match, will not trigger the duplicate warning, but instead an internal server error. The bad part is that the order will still be created/received, but the items are not. To test: - Edit an item in your catalog to have a barcode with 20 characters - Create a new basket in acq with either "create items on order" or "on receive" - Start the ordering process, when you get to the create items step - Enter your 20 character barcode, try to safe - Verify the duplicate message is triggered on saving - Add some characters to the end of your barcode - Verify on saving there is an internal server error - The order is created, but there are no new items -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 34231] New: Allow different input formats for monetary values
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34231 Bug ID: 34231 Summary: Allow different input formats for monetary values Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, jonathan.druart+koha(a)gmail.com, michaela.sieber(a)kit.edu, tomascohen(a)gmail.com There are several bugs already about this, but after discussing with Joubu and Tomas today I think it deserves a fresh start. On bug 30718 Jonathan wrote: > "Show the user a readable date (as per altFormat), but return > something totally different to the server." > > It's actually an option we want to use for all our dates, that will > reduce a lot the overhead in our controllers. And we should use the same approach for dealing with monetary amounts in patrons/account and in the acquisition module. Using a client side solution we avoid having to touch the .pl scripts and it will also make it easier to work with the API. We'd have 2 input fields, one hidden, with the 'raw' data in the expected database format, and one visible input field for entering and displaying the 'formatted' data. When sending the data to the server, only the 'raw' data will be processed. To explain the need/use case: At the moment we don't have any validation on input fields in the acquisition module and that leads to input errors that can have dire consequences. 1,00 might be turned into 100 or 1000 or just end up as an empty field. We also only allow the 'US' format with decimal dot, but not the French/German format of decimal comma. This is also a usability issue as keyboard with German layout don't have a . in the number block, only a comma. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 41688] New: Refund modal and amount as NaN, rejected comma separator
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41688 Bug ID: 41688 Summary: Refund modal and amount as NaN, rejected comma separator Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: thibaud.guillot(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk Hello @ll The problem here is on the refund modal, when retrieving the default value before being modified it is NaN because in some cases for decimal separators with comma, the recovery fails due to formatting a value already formatted in js. After a quick search I think it's a return of bug 31513 fix -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 42720] New: Add REST API equivalents for svc/report and opac/svc/report
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42720 Bug ID: 42720 Summary: Add REST API equivalents for svc/report and opac/svc/report Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com We should have equivalent functionality as svc/report in the REST API. Perhaps some time in the future we could deprecate the old version. Having a REST equivalent would come with better better authentication, documentation, http responses ( somewhat fixed by bug 42596 ) and other things. It could have pagination for example. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 21266] New: Missing doc-head-close and cssinclude in sco-main.tt
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21266 Bug ID: 21266 Summary: Missing doc-head-close and cssinclude in sco-main.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Custom stylesheet themes set in the OpacAdditionalStylesheet are not applied to the sco-main.tt page because this page is missing the following lines of code in the header: doc-head-close cssinclude -- You are receiving this mail because: You are watching all bug changes.

1 49