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

[Bug 32573] New: background_jobs_worker.pl should ACK a message before it forks and runs the job
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32573 Bug ID: 32573 Summary: background_jobs_worker.pl should ACK a message before it forks and runs the job Change sponsored?: --- Product: Koha Version: master 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Splitting off this functionality from bug 32558. This is the comment that started this discussion: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32558#c15 >From the O'Reilly book Mobile and Web Messaging: --- By default, the STOMP broker will consider the message automatically acknowledged when it is delivered to the consumer. However, there are cases in which the consumer may prefer to explicitly acknowledge the message. It leaves a window of opportunity to determine whether it can handle the message or not. For example, the client needs to write the message payload in a data store. There may be issues with opening a connection to the data store and the client could choose to acknowledge the message only after having successfully written its body to the data store. In case of failure, it will instead nack the message (explicitly refuse to take ownership of it). When the STOMP broker is informed of this negative acknowledgment, it may then decide to deliver the message to another consumer subscribed to the destination or try again some time later depending on its configuration. --- >From https://www.rabbitmq.com/stomp.html --- RabbitMQ STOMP plugin supports auto, client, and client-individual subscription headers that affect how ACK on NACK operations work. The auto mode uses automatic acknowledgements. The client mode is manual (client-driven) acknowledgements of multiple messages at once. The client-individual is for message-by-message manual acknowledgement. --- If ACK is meant to be sent post-work, why would automatic acknowledgement exist? The interpretation that an ACK is meant to be sent after handling the processing of a job doesn't make sense. In summary, we should be sending back ACK messages as soon as we've successfully processed ( e.g. read and decoded the data ) of a frame. Only then should we process it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 50

[Bug 32221] New: password option should be removed from notice templates
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32221 Bug ID: 32221 Summary: password option should be removed from notice templates Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Since the password can no longer be shown in notices, borrowers.password should be removed from the notice templates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 32656] New: Script delete_records_via_leader.pl no longer deletes items
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32656 Bug ID: 32656 Summary: Script delete_records_via_leader.pl no longer deletes items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 29788 inadvertantly replaced a call to safe_delete() with safe_to_delete() such that any time the script should delete an item it only checks to see if the item is delectable, after which deletion of the record fails because the items were not deleted. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 31244] New: Logout when not logged in raise a 500
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31244 Bug ID: 31244 Summary: Logout when not logged in raise a 500 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Staff Client 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 /cgi-bin/koha/mainpage.pl?logout.x=1 is hit when the user is not logged in, a 500 is displayed. Can't use an undefined value as a HASH reference at /kohadevbox/koha/C4/Auth.pm line 985 C4::Auth::checkauth('CGI=HASH(0x5603b7dc4300)', 0, 'HASH(0x5603b2633238)', 'intranet', undef, 'intranet-main.tt') called at /kohadevbox/koha/C4/Auth.pm line 186 C4::Auth::get_template_and_user('HASH(0x5603b7b83d08)') called at /kohadevbox/koha/mainpage.pl line 40 -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 32349] New: Remove TEST_QA
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32349 Bug ID: 32349 Summary: Remove TEST_QA Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 Depends on: 5485 There is an env var that we are passing from koha-testing-docker, TEST_QA. It's used in Koha from a single test file, t/00-testcritic.t. If not set, no test is run. Do we really need this? libtest-perl-critic-perl is packaged and automatically installed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5485 [Bug 5485] Add a framework for static source code analysis -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 32330] New: Table background_jobs is missing indexes
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32330 Bug ID: 32330 Summary: Table background_jobs is missing indexes Change sponsored?: --- Product: Koha Version: master 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Table background_jobs should have indexes to optimize queries. Query on borrowernumber : mainpage.pl: my $already_ran_jobs = Koha::BackgroundJobs->search( mainpage.pl- { borrowernumber => $logged_in_user->borrowernumber } )->count ? 1 : 0; Query on status: misc/background_jobs_worker.pl: my $jobs = Koha::BackgroundJobs->search({ status => 'new', queue => \@queues }); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 31492] New: Patron image upload fails on first attempt with CSRF failure
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31492 Bug ID: 31492 Summary: Patron image upload fails on first attempt with CSRF failure Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: matthew.lindfield-seager(a)hope.edu.kh QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com After upgrading to 22.05.004 (and after manually installing `libmojolicious-plugin-openapi-perl` to get patron search to work - as per https://www.mail-archive.com/koha@lists.katipo.co.nz/msg28885.html) we are now seeing an issue uploading patron images. After logging in to Koha, the first attempt to upload an individual patron image (from the patron show screen) fails with a CSRF error: > The form submission failed (Wrong CSRF token). Try to come back, refresh the page, then try again. Second and subsequent attempts succeed up until we log out and log back in again. After that the first submission once again fails. I tailed the logs to see if I could see any errors using `tail -f /var/log/koha/library/*.log`. On one occasion I saw an error related to `picture_upload.pl` in `/var/log/koha/library/intranet-error.log` but I can't reproduce it. In case it's relevant the error I saw once was: > [Wed Aug 31 09:55:06.665314 2022] [cgi:error] [pid 288501] [client 136.228.129.94:64313] AH01215: Use of uninitialized value $cardnumber in concatenation (.) or string at /usr/share/koha/intranet/cgi-bin/tools/picture-upload.pl line 66.: /usr/share/koha/intranet/cgi-bin/tools/picture-upload.pl, referer: https://<library url>/cgi-bin/koha/circ/circulation.pl?borrowernumber=1790 The CSRF error in the client is reproducible in up-to-date versions of Chrome on Windows and Safari on macOS so it doesn't seem to be browser or OS specific. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 32255] New: Cannot use file upload in batch record modification
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32255 Bug ID: 32255 Summary: Cannot use file upload in batch record modification Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When using the batch record modification tool with a file of biblionumbers, nothing happens. When we click 'Continue' the file is somehow removed before continuing. To test: 1. Get a file of biblionumbers (if you already have a file, proceed to step 2) 1.1. Go to Reports 1.2. Click on 'Create from SQL' 1.3. Enter a report name (e.g. biblionumbers) 1.4. Enter the following SQL query SELECT biblionumber FROM biblio LIMIT 100 1.5. Click 'Save report' 1.6. Click 'Run report' 1.7. Click 'Download' > 'Tab separated text' 2. Create a MARC modification template (if you already have a MARC modification template, proceed to step 3) 2.1. Go to Cataloging > MARC modification template 2.2. Click 'New template' 2.3. Enter a template name (e.g. Add note) 2.4. Click 'Submit' 2.5. Click 'New action' 2.6. Choose - Add new - Field 500 a - with value Note 2.7. Click 'Add action' 3. Batch modify records 3.1. Go to Cataloging > Batch record modification 3.2. In the 'Upload a file tab', choose the biblionumber file --> Note that the name of the file appears next to the Choose button 3.3. In 'Template', select the MARC modification template 3.4. Click 'Continue' --> The name of the file disappears next to the Choose button and goes back to 'No file chosen' --> Message 'No records were modified.' -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 32348] New: Library public is missing from columns settings
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32348 Bug ID: 32348 Summary: Library public is missing from columns settings Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Bug 27360 added public info on libraries table. This should be added to columns settings. Currently the column "STMP server" can not be managed in settings. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 30694] New: Impossible to delete line in circulation and fine rules
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30694 Bug ID: 30694 Summary: Impossible to delete line in circulation and fine rules Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: klas.blomberg(a)skovde.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If you have entered a value in the column "Decreased loan period for high holds" for a circulation rule - you can't delete that line. The only thing that will happend is that all numerical values are wiped out - giving today as duedate -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19