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

[Bug 35989] New: Searching Geographic authorities generates error
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35989 Bug ID: 35989 Summary: Searching Geographic authorities generates error Change sponsored?: --- Product: Koha Version: 23.11 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: rcooper(a)inceptlabs.com.au QA Contact: testopia(a)bugs.koha-community.org 1) Search Authorities from the main view (/cgi-bin/koha/authorities/authorities-home.pl) 2) From Authority type drop down select Geographic Name 3) Leave the search field blank 4) Run the search 5) The following error is returned : Error: Unmatched [ in regex; marked by <-- HERE in m/^[ <-- HERE ]$/ at /usr/share/perl5/MARC/Field.pm line 643. Notes: This also happens when searching for a or Australia, but not when searching for Japan When searching using the Authority Search pop-up, an Error 500 is returned. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 33237] New: If TranslateNotices is off, use the interface language includes in slips
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33237 Bug ID: 33237 Summary: If TranslateNotices is off, use the interface language includes in slips Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Most of our clients use Koha in one language only (French) and their patrons are also all french-speakers. So they don't use TranslateNotices, since they don't need to print slips in different languages. However, if TranslateNotices is off, the translations for "includes" (in my specific example, account types), are not taken into consideration and print in English. Same if TranslateNotices is on, but the patron's language is Default. In those cases, shouldn't it use the interface language rather than just print in English? To replicate: 1. Install the other language (i used fr-CA here) 1.1. gulp po:update fr-CA ./misc/translator/translate install fr-CA 1.2. In Administration > Global system preferences, search for language and check the added language 2. Create a manual invoice in a patron's account and pay it 3. From the Transactions tab, click 'Print' next to the payment line --> On the printed slip, the title is "Payment receipt" (OK) 4. Switch interface to other language 5. Redo step 3 --> On the printed slip, the title is still "Payment receipt" (not ok) 6. In Administration > Global system preferences, enable TranslateNotices 7. Go to Tools > Notices and slips > ACCOUNT_CREDIT and copy the content of the letter into all the languages 8. Redo step 3 (you should still be in the other language interface) --> On the printed slip, the title is still "Payment receipt" (not ok?) 9. Edit the patron's account and change the preferred language to the other language 10. Redo step 3 --> On the printed slip, the title is "Paiement receipt" (OK) On step 3, the account type is in English in the English interface (OK) On step 5, the account type is in English in the other interface, with TranslateNotices off, I feel like the slip should take the interface into account in this case for the include... On step 8, TranslateNotices is on, but the patron's language is Default, I feel like this should also take into account the interface language... On step 10, TranslateNotices is on and patron language is set, these are currently the only settings which allow to have the accounttypes in the other language. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 90

[Bug 35721] New: Replace ModItemTransfer calls in circ/returns.pl
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35721 Bug ID: 35721 Summary: Replace ModItemTransfer calls in circ/returns.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Blocks: 25754 ModItemTransfer is slowly getting removed and replaced by calls to the relevant Koha::Item and Koha::Item::Transfer methods. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25754 [Bug 25754] Deprecate C4::Items::ModItemTransfer -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61

[Bug 34972] New: Canceling a waiting hold from the holds over tab can make the next hold unfillable
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34972 Bug ID: 34972 Summary: Canceling a waiting hold from the holds over tab can make the next hold unfillable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When a staff member cancels a hold by clicking the button in the "holds waiting over 10 days" report, Koha incompletely attempts to assign that item to the next matching hold. Koha assigns the itemnumber to the hold, but does *not* set found status of the hold. Instead, it prompts the staff member, "Please retain this item and check it in to process the hold." This causes a few problems: - The itemnumber is immediately assigned to the hold without an opportunity for staff input, even if HoldsAutoFill is disabled. - If the staff member does not check in the book afterward (whether intentionally or through human error), it leaves the hold in an invalid state: it is tied to the itemnumber, but it is neither "found" nor an item-level hold. - Since the itemnumber is assigned, other items can't fill the hold. However, since the "found" field was never set, the option to "revert waiting status" or "revert transit status" isn't available. Essentially, a bib-level hold is suddenly behaving like an item-level hold, with no way for staff to identify or fix the issue. This is especially a problem if the item is missing from the holds shelf for some reason, and the staff member cancels the waiting hold first and then marks the item "lost". This makes the next-in-line hold unfillable unless the item is found. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 52

[Bug 33832] New: Can't change a patron's username without entering passwords
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33832 Bug ID: 33832 Summary: Can't change a patron's username without entering passwords Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the staff interface, on the "Change password" page, it's not possible to update a patron's username without also entering password information. This is contrary to the help text, "Leave the field blank to leave password unchanged." As far as I can tell this bug goes back to at least 21.05.x -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 35963] New: Problem using some filters in the bundled items table
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35963 Bug ID: 35963 Summary: Problem using some filters in the bundled items table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 28854 When trying to use the barcode filter of the bundled items table, the REST API returns an error 500 with the following message in logs: Unknown column 'me.barcode' in 'where clause' at /usr/share/perl5/Data/Page.pm line 49 The URL looks like this: /api/v1/items/3/bundled_items?&_page=1&_per_page=20&q=[{"me.external_id":{"like":"%1%"}}]&_match=contains If I manually remove "me." from the URL, it works. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28854 [Bug 28854] Add ability to create bundles of items for circulation -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 36140] New: Wrong for attribute on Invoice number: label in invoice.tt
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36140 Bug ID: 36140 Summary: Wrong for attribute on Invoice number: label in invoice.tt Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Accessibility Assignee: martin.renvoize(a)ptfs-europe.com Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, oleonard(a)myacpl.org The Invoice label is `<label for="shipmentdate">Invoice number:</label>` when it should be `<label for="invoicenumber">Invoice number:</label>` -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 35918] New: Incorrect library used when AutoLocation configured using the same IP
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35918 Bug ID: 35918 Summary: Incorrect library used when AutoLocation configured using the same IP Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Staff interface Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If you have AutoLocation turned on and you are using the same IP for different libraries, the logged in library will be set randomly. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 35548] New: Move KitchenSink test on its own and control table creation
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35548 Bug ID: 35548 Summary: Move KitchenSink test on its own and control table creation Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org See bug 35507. Since KitchenSink contains CREATE TABLE, it commits cruft into db. Lets control that a bit more. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 35507] New: TestBuilder.t is failing randomly
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '25

23 Jun '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35507 Bug ID: 35507 Summary: TestBuilder.t is failing randomly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org koha_1 | # Failed test 'No encoding warnings!' koha_1 | # at t/db_dependent/TestBuilder.t line 519. koha_1 | # found warning: Failed to load Koha::Plugin::Com::ByWaterSolutions::KitchenSink: Could not find or check module 'Koha::Plugin::Com::ByWaterSolutions::KitchenSink' at /kohadevbox/koha/Koha/Plugins.pm line 124. koha_1 | # didn't expect to find a warning koha_1 | # Looks like you failed 1 test of 1. koha_1 | koha_1 | # Failed test 'build_sample_biblio() tests' koha_1 | # at t/db_dependent/TestBuilder.t line 523. Has been failing on Koha_Master/2759 but fixed in 2760. The output is full of Failed to load Koha::Plugin::Com::ByWaterSolutions::KitchenSink: Could not find or check module 'Koha::Plugin::Com::ByWaterSolutions::KitchenSink' at /kohadevbox/koha/Koha/Plugins.pm line 124. -- You are receiving this mail because: You are watching all bug changes.

1 86