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

[Bug 36802] New: Add 'status flow' configuration options to catalog concerns
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '24

02 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36802 Bug ID: 36802 Summary: Add 'status flow' configuration options to catalog concerns 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 Depends on: 32435, 35628 Blocks: 34255 With the introduction of catalog concern statuses (bug 35628) and resolutions (bug 32435) we have the foundations for a workflow management solution. I'm envisaging something along similar lines to how Bugzilla manages which statuses are available to pick from at the various stages of the bug workflow. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32435 [Bug 32435] Add resolution types to catalog concerns https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34255 [Bug 34255] Add an enquiry/request/workflow management module https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35628 [Bug 35628] Add additional statuses to catalog concerns -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 32435] New: Add resolution types to catalog concerns
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '24

02 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32435 Bug ID: 32435 Summary: Add resolution types to catalog concerns Change sponsored?: --- Product: Koha Version: master 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 Depends on: 31028 It would be nice to have a descriptive resolution text for different standard resolutions to catalog problems reported via the new catalog concerns feature. We're envisaging using the authorized values system to populate a drop down of resolutions available. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31028 [Bug 31028] Add 'Report a concern' feature for patrons to report concerns about catalog records -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 65

[Bug 36756] New: Fix default action on split update button when editing tickets/catalog concerns
by bugzilla-daemon＠bugs.koha-community.org 02 Aug '24

02 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36756 Bug ID: 36756 Summary: Fix default action on split update button when editing tickets/catalog concerns Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Depends on: 35657 Just clicking on "update" with ticket resolution status defined does nothing right now, it should update and keep the currently assigned status. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35657 [Bug 35657] Add ability to assign tickets to librarians for catalog concerns -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 15854] New: Possible race condition for sending renewal notices
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15854 Bug ID: 15854 Summary: Possible race condition for sending renewal notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Renewal notices are sent as digests - all renewed items are collected in one e-mail that is sent out with the process_messagequeue. We have a library, where sometimes this doesn't work. Instead of one single e-mail notice to the patron for one 'process_messagequeue' interval, multiple renewal notices are generated. The majority of e-mails is generated correctly. Looking at the code, this is about how it works: - AddRenewal is exectuted per item and calls - SendCirculationAlert which calls - C4::Message->find_last_message to help decide if a new notice has to be generated or an existing one can be amended In order to test this, you need: - EnhancedMessagingPreferences - Check-out notice checked for the patron you test with - RenewalSendNotice activated - A notice called RENEWAL As I see no problem in the logic so far, I think it could be a race condition where find_last_message doesn't find an existing notice (yet)? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 31

[Bug 24007] New: Koha::Account::non_issues_charges is badly named
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24007 Bug ID: 24007 Summary: Koha::Account::non_issues_charges is badly named Change sponsored?: --- Product: Koha Version: master 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 The non_issues_charges method name suggests you will be returned a set of charges (Account::Lines) which would block a patrons ability to check out items. In fact, it returns a 'balance' of such charges but includes outstanding credits in the calculation. We should either rename the method to clarify it's use or update the method to return the expectation given it's naming. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 24009] New: Koha::Account->outstanding_debits should support inline filtering
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24009 Bug ID: 24009 Summary: Koha::Account->outstanding_debits should support inline filtering Change sponsored?: --- Product: Koha Version: master 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 We have a number of places where we want to get a specific list of outstanding debits for comparison.. at the moment one would have to construct a search directly by inspecting system preferences at the controller level. By addins a filter option to oustanding_debits we can move that back to the object level without having to add additional methods. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 30654] New: Even with RabbitMQ enabled, we should poll the database for jobs at worker startup
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30654 Bug ID: 30654 Summary: Even with RabbitMQ enabled, we should poll the database for jobs at worker startup Change sponsored?: --- Product: Koha Version: master 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 Depends on: 27344 Our worker currently starts up and immediately tries to listen for jobs being passed via STOMP. However, if rabbitMQ wasn't running when the tasks were enqueue, then the worker will never know about them. We should work through the outstanding queue before listening for new jobs. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27344 [Bug 27344] Implement Elastic's update_index_background using Koha::BackgroundJob -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 37164] New: worker-output.log file grows to incredible sizes and causing the server to crash
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37164 Bug ID: 37164 Summary: worker-output.log file grows to incredible sizes and causing the server to crash Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: Linux Status: NEW Severity: critical Priority: P5 - low Component: bugs.koha-community.org Assignee: koha-bugs(a)lists.koha-community.org Reporter: yuriy.kotsyuk(a)oa.edu.ua QA Contact: testopia(a)bugs.koha-community.org Created attachment 168002 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=168002&action=e… scrinchot worker-output.log.2 (fragment) The worker-output.log file grows to incredible sizes. While checking one of the files (5 GB), a warning entry was found and this entry was duplicated a huge number of times over a short period of time. The first two records are as follows: DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: DBI connect('database=koha_library;host=localhost;port=3306','koha_library',...) failed: Lost connection to MySQL server at 'reading initial communication packet', system error: 104 at /usr/share/koha/lib/Koha/Database.pm line 91. at /usr/share/koha/lib/Koha/Objects.pm line 312 DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: DBI connect('database=koha_library;host=localhost;port=3306','koha_library',...) failed: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) at /usr/share/koha/lib/Koha/Database.pm line 91. at /usr/share/koha/lib/Koha/Objects.pm line 312 Line number three indicates the date and time 2024/05/20 17:35:52 In general, the record looks like this: [2024/05/20 17:35:52] [WARN] Frame not processed - malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "You must log in usin...") at /usr/share/koha/bin/workers/background_jobs_worker.pl line 120. main::catch {...} /usr/share/koha/bin/workers/background_jobs_worker.pl (122) This entry occurs 985 times in a row. Recording in the next second: [2024/05/20 17:35:53] [WARN] Frame not processed - malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "You must log in usin...") at /usr/share/koha/bin/workers/background_jobs_worker.pl line 120. main::catch {...} /usr/share/koha/bin/workers/background_jobs_worker.pl (122) occurs 1483 times in a row. Recording in the next second: [2024/05/20 17:35:54] [WARN] Frame not processed - malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "You must log in usin...") at /usr/share/koha/bin/workers/background_jobs_worker.pl line 120. main::catch {...} /usr/share/koha/bin/workers/background_jobs_worker.pl (122) occurs 6952 times A total of 16,709,173 messages of the same type were generated from 2024/05/20 17:35:52 to 2024/05/21 10:59:08 After this series of messages, other messages have already appeared: Cannot connect to the message broker, the jobs will be processed anyway (Failed to connect: Error connecting to localhost:61613: Connection refused at /usr/share/perl5/Net/Stomp.pm line 27.; giving up at /usr/share/perl5/Net/Stomp.pm line 27. ) at /usr/share/koha/bin/workers/background_jobs_worker.pl line 92. Cannot connect to the message broker, the jobs will be processed anyway (Failed to connect: Error connecting to localhost:61613: Connection refused at /usr/share/perl5/Net/Stomp.pm line 27.; giving up at /usr/share/perl5/Net/Stomp.pm line 27. ) at /usr/share/koha/bin/workers/background_jobs_worker.pl line 92. Today, worker-output.log was 108 GB in size and took up all free disk space, causing the server to crash. Perhaps someone had the same problems and was able to overcome them -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 37458] New: opacusercss
by bugzilla-daemon＠bugs.koha-community.org 01 Aug '24

01 Aug '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37458 Bug ID: 37458 Summary: opacusercss Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: Linux Status: NEW Severity: critical Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lvargassarmiento(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 169511 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=169511&action=e… cada rato me sale el mismo error y tengo que cerrar todo y volver a entrar y sigue apareciendo el mismo error Cuando trato de colocar codigos en el Opacusercss me sale este error solo cuando presiono los cambioas para guardarlo. TypeError: Cannot read properties of undefined (reading 'map') -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 37541] New: Changing PIN after turning on forced PIN reset results in setting of NEVER
by bugzilla-daemon＠bugs.koha-community.org 31 Jul '24

31 Jul '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37541 Bug ID: 37541 Summary: Changing PIN after turning on forced PIN reset results in setting of NEVER Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: chanel.wheeler(a)yavapaiaz.gov QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org We set up a new patron category with an expiration date of 90 days. We then moved the shared staff accounts over to this new category and set a manual expiration date of a few weeks out. We then went into one of these staff accounts and manually changed the PIN. Now on the patron detail page, it shows their PIN Expires as NEVER. It should show either the manual expiration date we'd already set, or a new date 90 days out. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3