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

[Bug 41213] New: 500 Error: The amount collected from the patron is higher than the amount to be paid
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41213 Bug ID: 41213 Summary: 500 Error: The amount collected from the patron is higher than the amount to be paid Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: eric(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 189247 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=189247&action=e… Showing the amount outstanding, payment, and tendered amounts To recreate: 1. Create a manual invoice 2. Make a payment on the invoice BUT: 1. Set the "amount to be paid" to be less than the total outstanding 2. Set the Amount Tendered to be more than what is being paid The "Change to be given" value is correct, but when you confirm the action you get a 500 error and the payment is not tracked in the accountlines. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 39219] New: Error when issuing a refund from the transaction table
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '25

07 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39219 Bug ID: 39219 Summary: Error when issuing a refund from the transaction table Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: - Create a manual invoice: $10.00 - Pay using the pay button in the transactions table: $1.00 - Now issuing a refund explodes into: Exception 'Koha::Exceptions::ParameterTooHigh' thrown 'Amount to payout (3.00) is higher than amountoutstanding (0)' at /usr/share/perl5/Exception/Class/Base.pm line 88 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 31507] New: When printing barcode range labels library name does not print
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '25

06 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31507 Bug ID: 31507 Summary: When printing barcode range labels library name does not print Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org With the ability to print barcode labels from a range, using the Home or Holding description data within the label layout, it does not print any info, since by default, these are barcodes that do not have items yet, and therefore, no home or holding data. It would be really helpful to have a way to have the library info appear without having to manually enter the library name in the fields data. This is particularly important for libraries with multiple branches where you don't want to have to change the library name, nor have a lot of different layouts. Perhaps the default for this scenario could be the logged in library if there is no home or holding? -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 41196] New: Additional sushi authentication params potentially required
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '25

06 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41196 Bug ID: 41196 Summary: Additional sushi authentication params potentially required Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: jvinke(a)austinseminary.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk Some SUSHI 5 providers require additional parameters beyond those listed in the Data Provider SUSHI Credentials fields. One such example is Harvard University Press, which requires a "platform" parameter. There is a field in the data provider record for "service platform" but this does not seem to be used. >From their SUSHI page: Multiple platforms available, populate the Platform parameter with the platform name you wish to report on Loeb+Classical+Library DARE+Dictionary So a functional link for me looks like: https://ams.hup.harvard.edu/rest/COUNTER/v5/reports?customer_id=[REDACTED]&… For now, I can get this target to work by injecting the additional parameter in my API key field, but it would be nice to have a way to handle odd extra params like this. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 37856] New: Some SUSHI providers require the platform parameter
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '25

06 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37856 Bug ID: 37856 Summary: Some SUSHI providers require the platform parameter Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: pedro.amorim(a)ptfs-europe.com Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, michaela.sieber(a)kit.edu, pedro.amorim(a)ptfs-europe.com The harvest_sushi method produces the following URL when harvesting SUSHI data: <provider_url>/reports/<report_type>?customer_id=<customer_id>&requestor_id=<requestor_id>&api_key=<api_key>&begin_date=<begin_date>&end_date=<end_date> Some providers require the 'platform' parameter. Docs here: https://app.swaggerhub.com/apis/COUNTER/counter-sushi_5_0_api/5.0.2#/defaul… We need to look for a way to identify when/if a provider requires this parameter, and add it to the URL if so. The provider in question is ScienceDirect: https://registry.countermetrics.org/platform/ab4d3560-1165-491d-a67e-9359d0… The 'platform parameter required' entry is unchecked even though this provider requires it. We should consider using this to identify if the parameter is required or not. -- You are receiving this mail because: You are watching all bug changes.

1 53

[Bug 39828] New: QuickAdd skips fields from PatronQuickAddFields in some cases
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '25

06 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39828 Bug ID: 39828 Summary: QuickAdd skips fields from PatronQuickAddFields in some cases Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: slavashishkin(a)gmail.com Reporter: slavashishkin(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using PatronQuickAddFields to add fields to the Quick Add form, fields that exist in the main form but contain multiple input elements (especially hidden/disabled ones) may be silently skipped during QuickAdd form generation. Example: "userid" field exists in the full patron form (entryform) as: > <li> > <label for="userid">Username:</label> > <input type="text" id="userid" name="userid" ...> > <input type="text" disabled="disabled" style="display:none" ...> > </li> The current JavaScript logic to detect and clone these fields uses: > let orig_input_id = orig_li.children("input,textarea,select").last().attr("id"); In this example, .last() selects the hidden disabled input without an id → orig_input_id becomes undefined → and the field is not cloned into QuickAdd form. Result: userid is missing from Quick Add even though it's included in PatronQuickAddFields. Steps to reproduce: 1. Add userid (or any other field that matches above structure) to PatronQuickAddFields. 2. Open the Add Patron form and use Quick Add. 3. Observe → the field is missing. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 41195] New: Data Provider Manual should specify file requirements
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '25

06 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41195 Bug ID: 41195 Summary: Data Provider Manual should specify file requirements Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart(a)gmail.com Reporter: jvinke(a)austinseminary.edu QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, jonathan.field(a)openfifth.co.uk, martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, pedro.amorim(a)openfifth.co.uk The "manual upload" tab of the data provider page does not offer any guidance regarding what type of file should be uploaded. The counter specification allows for either a TSV file or a json file, so I presume it's one or both of these. https://cop5.countermetrics.org/en/5.1/03-specifications/02-formats-for-cou… I actually tested with both and didn't have luck with either. The file will upload, but the job that gets invoked (ERM Usage Statistics SUSHI Harvester) fails. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 40341] New: Patron Category Messaging Preferences Not Applied to Existing Patrons
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '25

06 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40341 Bug ID: 40341 Summary: Patron Category Messaging Preferences Not Applied to Existing Patrons Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: samrocks1011(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 28492] New: Hyphen in branchcode gives wrong search results
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28492 Bug ID: 28492 Summary: Hyphen in branchcode gives wrong search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org A client noticed that when limiting by branch, some search results were wrong and after a bit of digging, I found that it happens when the branchcode contains a hyphen. I was able to recreate the situation as follows: 1) Go to Administration > Libraries and add the libraries - Fairfield (branchcode FFL) -- if you have the default database, this library should already exist - Fairfield North (branchcode FFL-N) - Fairfield South (branchcode FFLS) 2) Add an item to record A with holding branch FFL-N 3) Add an item to record B with holding branch FFLS 4) reindex if necessary 5) In Advanced search, search for record A and limit to Fairfield North library -- record is in the results - OK 6) In Advanced search, search for record A and limit to Fairfield library -- record is in the results! - NOT OK 7) In Advanced search, search for record B and limit to Fairfield South library -- record is in the results - OK 8) In Advanced search, search for record B and limit to Fairfield library -- record is not in results - OK As you can see, the search for branchcode FFL-N and for branchcode FFL give the same results. The problem was originally found by a client using 18.05.03. I was able to recreate in 20.05.08 and master (21.06.000), always with Zebra. I didn't try with ES because mine is currently broken :( -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 40439] New: We cannot use the arrow keys to navigate through all the items in the navigation menus
by bugzilla-daemon＠bugs.koha-community.org 05 Nov '25

05 Nov '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40439 Bug ID: 40439 Summary: We cannot use the arrow keys to navigate through all the items in the navigation menus Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: nina.martinez(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)openfifth.co.uk, matt.blenkinsop(a)openfifth.co.uk, oleonard(a)myacpl.org We cannot use the arrow keys to navigate through all items in the navigation menus. Specifically, the arrow keys do not work for navigating the user menu “Welcome, ” in the navigation bar. While all other dropdown menus are navigable using the arrow keys like List and Languages (in the Languages menu, navigation is possible only with the arrow keys), this one is not. We can navigate it only with the Tab key, which can be confusing for users. Keyboard navigation is one of the most important accessibility features. We could improve this to enable navigation in this menu using the arrow keys like the other menus. To test this issue: 1- Log in to an account 2- Navigate with the tab key through the navigation bar, test to navigate in the different menus (List, Languages) with the arrows keys. 3- Go to ‘Welcome, ’ press Enter, and try to navigate through the options with the arrow keys. https://webaim.org/techniques/keyboard/ -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10