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

[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 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 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 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 24535] New: Add the ability to have longer barcodes than 20 digits
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24535 Bug ID: 24535 Summary: Add the ability to have longer barcodes than 20 digits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: nick(a)bywatersolutions.com Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently, in Koha, an item's barcode can only be up to 20 digits, it would be nice to increase this value to possibly a higher number such as 32. Koha recently increased the patron's barcode length to 32 and it was helpful to libraries. -- You are receiving this mail because: You are watching all bug changes.

1 31

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

[Bug 17921] New: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17921 Bug ID: 17921 Summary: Shelf Browser does not take OpacSuppression or OpacHiddenItems into consideration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Items that shouldn't be displayed in the OPAC are displayed in the shelf browser The links work as expected (redirect to opac-blocked or 404) but we should not display them in the first place -- You are receiving this mail because: You are watching all bug changes.

1 33

[Bug 21217] New: No error when doing Renewals for expired borrowers
by bugzilla-daemon＠bugs.koha-community.org 30 Oct '26

30 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21217 Bug ID: 21217 Summary: No error when doing Renewals for expired borrowers Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jeremy.evans(a)phe.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We have had a couple of instances when books were being renewed in the staff client where the renewal was failing but there was no error message. It turned out in both cases that the user accounts had expired. Is it possible for an alert to show in the staff client when trying to renew an items for an expired borrower? The alert shows if trying to check out items to an expired borrower but this does not appear from the renewals screen. I have had a look in the system preferences but can't see anything obvious. Thanks, Jeremy -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5