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

[Bug 41212] New: members/maninvoice.pl debit_types should sort by description not code
by bugzilla-daemon＠bugs.koha-community.org 21 May '26

21 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41212 Bug ID: 41212 Summary: members/maninvoice.pl debit_types should sort by description not code Initiative type: --- Sponsorship --- status: Product: Koha Version: Main 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(a)bywatersolutions.com To recerate: 1. Add some debit types that can be manually invoiced. 2. Go to members/maninvoice.pl?borrowernumber=X where X is your borrowernumber 3. In the type dropdown see that the entries are sorted by code not description. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 40843] New: On modborrowers.pl patron attributes should sort by the description, not the code
by bugzilla-daemon＠bugs.koha-community.org 21 May '26

21 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40843 Bug ID: 40843 Summary: On modborrowers.pl patron attributes should sort by the description, not the code Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1/ Have several borrower attributes set up so you can see how they sort 2/ Go to Tools > Batch patron modification 3/ Notice the "Patron attribute:: dropdown near the bottom 4/ It is sorted by the attribute code, not the description. It should sort by description. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 40836] New: Credit and debit types are not shown in patron account on OPAC
by bugzilla-daemon＠bugs.koha-community.org 21 May '26

21 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40836 Bug ID: 40836 Summary: Credit and debit types are not shown in patron account on OPAC Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 40256 In the patron account on the OPAC, the Type column is meant to show the description value for the associated credit or debit type (account_credit_types.description or account_debit_types.description). But the Type column is empty for any credit or debit type that's defined locally. All of the system-defined credit and debit types have this value hardcoded in the accounts.inc file, rather than actually fetching the value from the database. To recreate: - create a credit type that can be applied manually - create a debit type that can be applied manually - apply both a credit and debit to your patron (make sure auto-reconcile is off) - look at your patron's account in the staff interface, see values in the "account type" column - look at your patron's account in the OPAC, see the "Type" column is blank Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40256 [Bug 40256] System defined MANUAL debit type description is hard coded but the description can be changed -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 41039] New: Patron search button can be spammed and trigger many API patron searches
by bugzilla-daemon＠bugs.koha-community.org 21 May '26

21 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41039 Bug ID: 41039 Summary: Patron search button can be spammed and trigger many API patron searches 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle(a)bywatersolutions.com Every click of the "Search" button on members/members-home.pl will trigger another patron search api request. This button should be disabled until the first searches results are displayed. To demonstrate, open the network tab of the developer console on your web browser. Note each click if the button show another patron search api request. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 41207] New: Permission description string does match permission name
by bugzilla-daemon＠bugs.koha-community.org 21 May '26

21 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41207 Bug ID: 41207 Summary: Permission description string does match permission name Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: loreganlloyd(a)clamsnet.org QA Contact: testopia(a)bugs.koha-community.org On member-flags.pl under the Edit Catalog the description for this subpermission mentions edit_item permission however this should read edit_items. To reproduce: Go to a patron record Click on more -> set permissions Scroll down and expand the Edit Catalog Notice the line says edit_item is required but the permission needed is edit_items -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 29908] New: Warning when empty ClaimReturnedWarningThreshold in patron_messages.inc
by bugzilla-daemon＠bugs.koha-community.org 21 May '26

21 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29908 Bug ID: 29908 Summary: Warning when empty ClaimReturnedWarningThreshold in patron_messages.inc Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com System preference ClaimReturnedWarningThreshold manages the display of a patron message in case of too many claims. But this preference may be empty. This generates a warning : Argument "" isn't numeric in numeric gt (>) at /kohadevbox/koha/koha-tmpl/intranet-tmpl/prog/en/includes/patron_messages.inc line 128. Default value should be considered has 0 or infinite ? Before Bug 27873 code was in templates, bug still applies. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 40720] New: Misleading tooltip text "remove all items" in Select2 fields
by bugzilla-daemon＠bugs.koha-community.org 21 May '26

21 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40720 Bug ID: 40720 Summary: Misleading tooltip text "remove all items" in Select2 fields Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: elina.uotila(a)jarvenpaa.fi QA Contact: testopia(a)bugs.koha-community.org When editing an item record (for example, changing its current not for loan value) and hovering the cursor over the x symbol at the end of the field, Koha displays the tooltip text "remove all items". This wording is misleading, as the function does not remove any items from the database. Instead, it clears the selected value(s) in the drop-down menu. The affected text string comes from the messages-js.po file and is used by Select2 (koha-tmpl/intranet-tmpl/prog/js/select2.js:26). The fields where this text is used are all drop-down menus that are not directly related to items, so the wording "items" is confusing in this context. Would it be possible to change the phrase "remove all items" in Select2 to something more accurate, such as "remove selection"? -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 41082] New: Renaming columns in reports doesn't work with batch tools
by bugzilla-daemon＠bugs.koha-community.org 21 May '26

21 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41082 Bug ID: 41082 Summary: Renaming columns in reports doesn't work with batch tools Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: lisette(a)bywatersolutions.com This is a bit of a curious case: When creating an SQL report and it contains the column itemnumber, we activate batch operations above the table. The itemnumber column can be renamed, using the syntax [[itemnumber|Exemplarnummer]], which gives us the option to translate the column name into something nicer for display. But: if you then send to batch item edit, the items are not transmitted. To test: 1) Create a report: select itemnumber, itemcallnumber from items; 2) Send some items to batch item edit, verify the items are shown above the item form 3) Update the report: select [[itemnumber|Exemplarnummer]], itemcallnumber from items; 4) Verify the report still shows as before with the batch options available and only the column being renamed. 5) Send some items to the batch item edit again, verify the items are NOT shown abvoe the item form => nothing would be batch edited. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 42658] New: Add option for direct DB matching when using bulkmarcimport
by bugzilla-daemon＠bugs.koha-community.org 20 May '26

20 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42658 Bug ID: 42658 Summary: Add option for direct DB matching when using bulkmarcimport Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Currently bulkmarcimport lets you define a matching rule when importing - often we are matching on the biblionumber/999c - this means searching ES or the DB is functionally equivalent. We should have an option to bypass the search engine and check the DB in these cases -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 42657] New: Improve bulkmarcimport
by bugzilla-daemon＠bugs.koha-community.org 20 May '26

20 May '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42657 Bug ID: 42657 Summary: Improve bulkmarcimport Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: jake.deery(a)openfifth.co.uk, robin(a)catalyst.net.nz Importing large numbers of records can be slow - opening this while investigating some improvements -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3