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

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

02 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 02 Nov '26

02 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 41113] New: Missing doc-head-close and cssinclude in sci-main.tt
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41113 Bug ID: 41113 Summary: Missing doc-head-close and cssinclude in sci-main.tt Initiative type: --- Sponsorship Sponsored status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: aleisha(a)catalyst.net.nz, alexbuckley(a)catalyst.net.nz, dcook(a)prosentient.com.au, hammat.wele(a)inlibro.com, lucas(a)bywatersolutions.com, testopia(a)bugs.koha-community.org +++ This bug was initially created as a clone of Bug #21266 +++ Many of the some changes should be made to the self checkin templates -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 24535] New: Add the ability to have longer barcodes than 20 digits
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 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 02 Nov '26

02 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 42164] New: Add bibliographic search via database (maybe to replace Zebra)
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '26

02 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42164 Bug ID: 42164 Summary: Add bibliographic search via database (maybe to replace Zebra) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: mark(a)hofstetter.at QA Contact: testopia(a)bugs.koha-community.org create a prototype "to search" for bibliographic records using only the database search is implemented here https://github.com/HKS3/koha-nm2db-keyword-search using (which has to be installed first!) https://github.com/HKS3/koha-normalize-marc2db work in progress / prove of concept -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[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 39204] New: Problem with cancelling a hold via SIP without marking it as waiting returns an error
by bugzilla-daemon＠bugs.koha-community.org 01 Nov '26

01 Nov '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39204 Bug ID: 39204 Summary: Problem with cancelling a hold via SIP without marking it as waiting returns an error Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org >From Bug 38615: "When testing I noticed something both with and without the patch (so this is a general SIP question) If you place a hold and then try to cancel the hold with this command before checking the item into the hold shelf the SIP cancel request returns |AFError with transaction drop_hold:|" Easy to recreate with SIP emulator: 1. /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode + 2. /kohadevbox/koha/misc/sip_cli_emulator.pl -a localhost -p 6001 -l CPL -su term1 -sp term1 -m hold --patron 23529000035676 --item 39999000001310 --hold-mode - 3. See the error: AFError with transaction drop_hold: -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 41705] New: Popup blockers may be triggered by options to automatically display payment receipt for printing after making a payments
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '26

31 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41705 Bug ID: 41705 Summary: Popup blockers may be triggered by options to automatically display payment receipt for printing after making a payments Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)openfifth.co.uk QA Contact: testopia(a)bugs.koha-community.org CC: black23(a)gmail.com, fridolin.somers(a)biblibre.com, gmcharlt(a)gmail.com, koha-bugs(a)lists.koha-community.org, kyle(a)bywatersolutions.com, lisette(a)bywatersolutions.com, martin.renvoize(a)openfifth.co.uk, maryse.simard(a)inlibro.com, testopia(a)bugs.koha-community.org Depends on: 23228, 23461 Blocks: 13985 The pattern we use for automatically printing receipts and slips can often trigger popup blockers. This is because we trigger the popup window via JavaScript after page reload and this is interpreted as not being a user directed event and thus invokes many browsers popup blocking code. We could reverse our process such that the form submission itself has a target="_blank" attribute to trigger the popup at form submission time (which is a direct user action), then our controller handles the post, redirect, get pattern for printing. We fires the window print in the already opened new tab and finally close the tab, thus bringing the original tab back into focus, after print. This would need a little thought regarding the original tab, as we'd need the reset that tabs context/state as part of the initial submit that triggers the popup earlier in the process. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13985 [Bug 13985] [Omnibus] Cash Management - Koha as 'Point of Sale' https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23228 [Bug 23228] Add option to automatically display payment receipt for printing after making a payment https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23461 [Bug 23461] Popup blockers triggered by option to automatically display payment receipt for printing after making a payment -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug. You are the assignee for the bug.

1 54