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

[Bug 40726] New: Clicking off of a dropdown in the user menu branch switching closes the dropdown
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40726 Bug ID: 40726 Summary: Clicking off of a dropdown in the user menu branch switching closes the dropdown Change sponsored?: --- Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: koha-bugs(a)lists.koha-community.org Reporter: bdaeuber(a)cityoffargo.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 When using the user menu switching, if you miss the dropdown and click anywhere behind it, it closes the menu. I'd expect the menu to stay open unless I click elsewhere on the page, outside of the menu. To recreate 1. Open the user menu 2. Click the gear 3. Try to click a dropdown but miss it and click outside of it 4. View the menu collapsing. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 27115] New: Restarting koha-common fails to restart SIP2 server
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27115 Bug ID: 27115 Summary: Restarting koha-common fails to restart SIP2 server Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Sometimes when we run "systemctl restart koha-commmon" the SIP server doesn't get restarted but might just get stopped leading to longer than expected downtime. There is probably some sort of race condition. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 24364] New: Display item holding library in opac issues
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24364 Bug ID: 24364 Summary: Display item holding library in opac issues 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: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Be able to display the item's holding library in OPAC issues. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 38291] New: Add GET /library_groups
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38291 Bug ID: 38291 Summary: Add GET /library_groups Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: matt.blenkinsop(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com We should have an endpoint to list library groups -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 35903] New: In cataloguing authority plugin using autocomplete must set operator exact
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35903 Bug ID: 35903 Summary: In cataloguing authority plugin using autocomplete must set operator exact Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org When cataloguing and using authority plugin, there is auto-completion on inputs and default operator is "contains". When using auto-completion and selecting a result it would be logical to set operator "exact" and submit form. So the usually unique result appears. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 40888] New: and/or/not drop-downs are missing in the Advanced Search form
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40888 Bug ID: 40888 Summary: and/or/not drop-downs are missing in the Advanced Search form Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org Created attachment 186984 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=186984&action=e… Advanced search missing and/or drop-downs In the Advanced Search form, if "More options" is selected, each search field should have a drop-down to select between "and", "or", and "not" for that field. However, in 25.05 and main, that drop-down only appears in the first line. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 41158] New: Field 001 replaced when importing records while using autoControlNumber system preference
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41158 Bug ID: 41158 Summary: Field 001 replaced when importing records while using autoControlNumber system preference Initiative type: --- Sponsorship --- status: Product: Koha Version: 25.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: anneli.osterman(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Field 001 is replaced with records local biblionumber when importing records while using autoControlNumber system preference. This happens when using Z39.50 search/import and importing staged records. The manual tells about the system preference like this: "If set to ‘generated as biblionumber’, the control number will be filled with the biblionumber once the record is saved. This will not affect existing records that already have a value in 001. The existing value will be preserved." Replacing the 001 is not right because 001 should correspond to the value stored in field 003. The value in the field 001 is given by the cataloging agency marked in 003. Second problem is that if the 001 is replaced and the record has child records / component records, the connection between the host record and component record is lost. ShowComponentRecords system preference enables the linking component parts. >From the manual: "Components to be displayed are found using the host record’s control number (001) in the child record’s 773$w subfield" How to reproduce the problem with staging: 1. Activate autoControlNumber system preference 2. Find or create a bibliographic record which field 001 is not the records biblionumber. 3. Export the record using the Save button at the Normal view 4. Go to Cataloging -> Stage record for import -> Find the file you just saved 5. Stage the file with a rule to find matches (for example ISBN). If you do not have record matching rules, please make one in Administration -> Record matching rules. Choose to replace the record if match is found. 6. View the batch and check from the Diff column's link that 001 looks the same at this point. 7. Import the batch into the catalog. 8. Go to the record you just updated (or replaced) and click the MARC preview 9. Notice that the 001 field is replaced with records biblionumber How to reproduce by using Z39.50 (this is not a straight forward replacing like it seems to be in staging): 1. Activate autoControlNumber system preference 2. Find or create a bibliographic record which field 001 is not the records biblionumber. 3. Choose under the Edit button "Replace record via Z39.50/SRU" 4. Search for the title from a database that has the same title and choose to import it 5. You will be transferd to the record's editing page 6. Notice that field 001 is empty 7. If the cataloger does not notice the empty field, it will be filled with biblionumber upon saving the record. You can also try both ways while the autoControlNumber is not activated to notice the difference. If the autoControlNumber system preference is deactivated, the 001 stays the same in staging and in Z39.50 the 001 field is not emptied. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 38192] New: DT - State not restored correctly on suggestion tables
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38192 Bug ID: 38192 Summary: DT - State not restored correctly on suggestion tables Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Staff interface Assignee: jonathan.druart(a)gmail.com Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 33426 There is one table per tab, the id of the table is table_N. Say you have: Pending (#table_1), Accepted (#table_2), Rejected (#table_3) The state will be stored in localStorage with the following key: DataTables_table_1_/cgi-bin/koha/suggestion/suggestion.pl DataTables_table_2_/cgi-bin/koha/suggestion/suggestion.pl DataTables_table_3_/cgi-bin/koha/suggestion/suggestion.pl If you move all the suggestions from Accepted to Rejected, a shift will give: Pending (#table_1), Rejected (#table_2) And the previous state from the "Accepted" tab will be used for "Rejected" Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33426 [Bug 33426] Add client storage of user-selected DataTables configuration to suggestion.tt -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 37530] New: Enhance the confirm cashup modal in the Point of sale module
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37530 Bug ID: 37530 Summary: Enhance the confirm cashup modal in the Point of sale module Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com When doing a cashup on the registers.pl page in the POS module, it would be helpful to be able to have specific information about the previous time period's sales before actually recording the cashup. Currently, when you perform the cashup the only information you get is how much money you should be removing from the register and how much of a float to leave. Although the table on the cash summary page gives some information, the modal gives no information about how much money you should have in cash, credit cards or checks. No information about refunds. No information about the actual debit types that were sold. This is critical information for us because we handle sales for three entities - the library, Friends of the Library and Library Foundation. There is a 'cashup summary' link in the 'last cashup' column which gives a nice breakdown of this type of information but that's for the last cashup you performed not the one you are about to do. In fact, when we were learning POS we kept expecting this info to match the sales we were about to cashup. A report (based on the current 'cashup summary' report ) of the transactions since the last cashup, along with the current information you get when clicking on the 'Record cashup' button would be helpful. The information could be presented on screen and allow printing prior to actually confirming the cashup. Another reason an enhanced 'Record cashup' modal would be helpful is that we have had to create customized reports to get this detailed information. If it could be presented during the cashup process we could print the information for our own records and send it to our Finance Dept. with our daily deposit. I've added a screenshot to offer more clarification. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 39852] New: Add UPC (024$a) to OPAC/Staff interface detail pages
by bugzilla-daemon＠bugs.koha-community.org 16 Feb '26

16 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39852 Bug ID: 39852 Summary: Add UPC (024$a) to OPAC/Staff interface detail pages Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We should add the 024$a to the record display for OPAC/Staff interface detail pages. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10