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

[Bug 24655] New: RoundFinesAtPayment can leave partial cent credits on patrons account
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24655 Bug ID: 24655 Summary: RoundFinesAtPayment can leave partial cent credits on patrons account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Create a manual invoice for 1.4286 for a patron 2 - Enable RoundFinesAtPayment 3 - Pay 1.43 on the patrons account 4 - The fine is paid off, however, if you view the accountlines in the DB the patron has a credit of .0014 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 27054] New: Round fines at charging
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27054 Bug ID: 27054 Summary: Round fines at charging Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We currently have the option to round fines at payment. However, there are still places where Koha can charge partial cent fines. We should give the option to round fines at charging. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 37937] New: Budgeted cost tax exc. in basket page 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=37937 Bug ID: 37937 Summary: Budgeted cost tax exc. in basket page 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) Create an order line in acquisitions with vendor price 18.90 and a discount of 5 %. 4) After creation your are back to the basket page 5) Verify that the "Budgeted cost tax exc." in the order table on the basket page is 17.95. => this is wrong, it should be 17.96 6) Just like "Total tax exc. (USD)" (after Bug 36049 is merged) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[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 38589] New: The manual should specify that MARC configuration for bundles is the same for MARC21 and UNIMARC
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38589 Bug ID: 38589 Summary: The manual should specify that MARC configuration for bundles is the same for MARC21 and UNIMARC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de In the manual, the item bundle section (https://koha-community.org/manual/latest/fr/html/circulation.html#circulati…) states "The bundle functionality will only be displayed if you create a catalogue record with the Leader, (000 MARC tag) position 7 set to ‘c’ for Collection." and displays a picture from MARC21 framework This exact configuration setting is working for UNIMARC ("c" in pos.7 of leader), but this is not obvious as many settings in Koha are MARC-flavour-dependant -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[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