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

[Bug 37722] New: Add Koha Objects for Koha Holidays
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '24

24 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37722 Bug ID: 37722 Summary: Add Koha Objects for Koha Holidays Change sponsored?: --- Product: Koha Version: Main 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 37611] New: Spelling MIstake
by bugzilla-daemon＠bugs.koha-community.org 24 Oct '24

24 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37611 Bug ID: 37611 Summary: Spelling MIstake 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: niesha(a)aflibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 170212 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=170212&action=e… Misspelling When cataloguing a DVD, I noticed that you've written PROCUCTION rather than PRODUCTION: https://staff.aflibrary.org/cgi-bin/koha/cataloguing/addbiblio.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 32401] New: DataTable search can't handle UTF-8 when receiving orders
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32401 Bug ID: 32401 Summary: DataTable search can't handle UTF-8 when receiving orders Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you try to search pending orders in acquisitions using Arabic like خمسة it will silently fail. Nothing changes on the screen. No "Processing" or obvious Javascript errors. However, if you turn on "Pause on caught exceptions", you'll see the following: TypeError: Failed to execute 'setRequestHeader' on 'XMLHttpRequest': String contains non ISO-8859-1 code point. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 36199] New: Forgive overdue fines checkbox becomes unchecked when a wrong transfer occurs
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36199 Bug ID: 36199 Summary: Forgive overdue fines checkbox becomes unchecked when a wrong transfer occurs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Turn on the finesmode system preference. 2. Go to returns.pl (/cgi-bin/koha/circ/returns.pl) 3. Expand the the options so you see 'Forgive overdue charges'. Check that box. 4. Select an item from the catalog that is available at a different branch. Check in the item. Notice that the transfer modal pops up. Click on OK. The box for 'Forgive overdue charges' remains checked. 5. Check that same item in again. A modal stating "Wrong transfer detected, please return item to: *Branch name*" appears. Click on OK. Notice that the 'Forgive overdue charges' box has been unchecked. Ideally, the checkbox should remain checked until a staff member unchecks the box. A wrong transfer should not uncheck the box. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 34638] New: Option to configure default sort order for items on bib records in staff client
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34638 Bug ID: 34638 Summary: Option to configure default sort order for items on bib records in staff client Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: catrina(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 5594 suggests the ability to select the default sort order for the holdings table on the OPAC (holdingst). This bug requests the same functionality to select the default sort order for the holdings table in the staff client (holdings_table). The ability to set the default sort order exists on some tables but it would be nice to extend this capability to both holdings tables as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 32010] New: selenium/authentication_2fa.t is failing randomly
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32010 Bug ID: 32010 Summary: selenium/authentication_2fa.t is failing randomly Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 30588 Blocks: 25551 Since bug 30588 t/db_dependent/selenium/authentication_2fa.t is failing randomly. Well, it seems that it fails consistently on jenkins. 17:28:48 koha_1 | STRACE: /usr/share/perl5/Try/Tiny.pm:123 in Selenium::Remote::Driver::catch {...} 17:28:48 koha_1 | /usr/share/perl5/Selenium/Remote/Driver.pm:361 in Try::Tiny::try 17:28:48 koha_1 | (eval 541):1 in Selenium::Remote::Driver::__ANON__ 17:30:50 koha_1 | (eval 543):2 in Selenium::Remote::Driver::__ANON__ 17:30:50 koha_1 | /usr/share/perl5/Selenium/Remote/Driver.pm:654 in Selenium::Remote::Driver::_execute_command 17:30:50 koha_1 | t/db_dependent/selenium/authentication_2fa.t:282 in Selenium::Remote::Driver::get_alert_text 17:30:50 koha_1 | /usr/share/perl/5.32/Test/Builder.pm:334 in main::__ANON__ 17:30:50 koha_1 | /usr/share/perl/5.32/Test/Builder.pm:334 in (eval) 17:30:50 koha_1 | /usr/share/perl/5.32/Test/More.pm:809 in Test::Builder::subtest 17:30:50 koha_1 | t/db_dependent/selenium/authentication_2fa.t:291 in Test::More::subtest 17:30:50 koha_1 | 17:30:50 selenium_1 | 1666711728262 Marionette INFO Stopped listening on port 35969 17:30:50 selenium_1 | JavaScript error: resource://gre/modules/Prompter.jsm, line 1253: NS_ERROR_NOT_AVAILABLE: prompt aborted by user 17:30:50 selenium_1 | JavaScript error: resource:///modules/Interactions.jsm, line 230: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIUserIdleService.removeIdleObserver] 17:30:50 koha_1 | # Looks like you planned 7 tests but ran 4. 17:30:50 koha_1 | 17:30:50 koha_1 | # Failed test 'Enforce 2FA setup on first login' 17:30:50 koha_1 | # at t/db_dependent/selenium/authentication_2fa.t line 291. 17:30:50 koha_1 | Error while executing command: no such alert at /usr/share/perl5/Selenium/Remote/Driver.pm line 411. 17:30:50 koha_1 | at /usr/share/perl5/Selenium/Remote/Driver.pm line 356. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25551 [Bug 25551] [OMNIBUS] Some tests are failing randomly https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30588 [Bug 30588] Add the option to require 2FA setup on first staff login -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 36898] New: Elasticsearch indexer error log needs more information
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36898 Bug ID: 36898 Summary: Elasticsearch indexer error log needs more information Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au Fairly regularly I'm seeing the following message showing up in /var/log/koha/instance/es-indexer-output.log [2024/05/20 09:28:13] [WARN] Update of elastic index failed with: Exception 'Koha::Exceptions::Elasticsearch::BadResponse' thrown 'Bad response received when submitting request to Elasticsearch' with details => [https://hostname:9300]-[599] Timed out while waiting for socket to become ready for reading, type => Timeout main::catch {...} /usr/share/koha/bin/workers/es_indexer_daemon.pl (229) But this doesn't really tell me anything useful. It's not clear what records failed to update or what the job number was, so there's no way to re-try and fix the missing indexed data. Also, I've updated the request_timeout from 30 to 60, so it's a fairly long timeout. Generally speaking, there was a fair amount of indexing activity, but around 09:27:13 there wasn't. Although there was 6 jobs at 09:28:13, so maybe it's not the request_timeout that needs tweaking... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 37481] New: Some operations that do not affect data should be submitted as POST requests
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37481 Bug ID: 37481 Summary: Some operations that do not affect data should be submitted as POST requests Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Summarizing from bug 37197: There are limits to URL size that make POST preferable to GET in some instances. We can handle this with fake cud- operations "cud-show" or by allowing "show" and "cud-show" options to do the same things We have links that append the data - these could be made to use our new JS form submission We need to decide on a path here -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 37614] New: Printing patron cards from patron lists broken by CSRF protection
by bugzilla-daemon＠bugs.koha-community.org 22 Oct '24

22 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37614 Bug ID: 37614 Summary: Printing patron cards from patron lists broken by CSRF protection Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)gmail.com, oleonard(a)myacpl.org Blocks: 36192 Steps to reproduce: 1. Tools - Patrons lists, if you don't already have one then New list, name and save, Search for patrons, add at least one patron, then return to Patron lists. 2. In the Actions menu for your patron list, select Print patron cards 3. In that perfectly normal looking popup, click Export. You now have a popup with an Loading throbber, which will hang forever, and in your console you have a 403 error from trying to GET patroncards/print.pl. If you go back and inspect the page where you clicked Export, you'll find that it is a button type='submit' in a form with method='post' which makes the GET seem a bit odd. To see that it sometimes posts, 1. Tools - Patron card creator - New card batch - Add at least one patron 2. Export card batch 3. You get a popup with a lovely Windows 95 aesthetic courtesy of greybox.inc, but it is that same form method='post' with the same type='submit' Export button. Click Export and you will POST to patroncards/print.pl and things will work just fine. Not at all clear to me how opening the popup one way turns the POST to a GET, but it does. There's a FIXME in patroncards/print.pl saying that the op=cud-export looks sus, which it does. You could try to make the case that it's sensible to POST because in the case where you have selected some but not all of the patrons in a label batch, the number of label_id params in the URL could be so high that it exceeds Apache's max URL length, but then the result of the POST is a link to create the PDF that is the actual "print" export, and that link is a GET which contains all of them with an over-escaped &label_id= param for each one. So a pragmatic fix would be to just change from a POST to a GET, change cud-export to export, and not worry about why called one way it POSTs and called another way it GETs. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 36801] New: Allow un-resolving of a catalog concern
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '24

21 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36801 Bug ID: 36801 Summary: Allow un-resolving of a catalog concern 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We didn't allow for re-opening a resolved catalog concern before, but with the introduction of the update status's I think we managed to change the logic a bit and the 'Update' button now displays. This effectively allows for re-opening a resolved ticket; However, the actual ticket state isn't properly updated and should be so the new state is properly reflected in the display table and filtering options. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9