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

[Bug 21810] New: Add methods to allow deleting of action logs
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21810 Bug ID: 21810 Summary: Add methods to allow deleting of action logs 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: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Currently it is not possible to delete action logs since C4::Log does not provide any methods to do so. As detailed in bug 21809, it may, on occasions, be desirable to delete the logs associated with an object that has been deleted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 33441] New: SMTP server errors should have better logs in staff client
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33441 Bug ID: 33441 Summary: SMTP server errors should have better logs in staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: evelyn(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When using SMTP servers to send notices in Koha, if the sending fails there is an error message shown "Unhandled email failure, check the logs for further details". If the Koha is not hosted by the library, checking the server logs may not be possible. It would be beneficial to have at least the actual error code displayed to assist library staff with troubleshooting. This could be shown in the notices tab, centralized to the action logs, or a third option I haven't thought of yet. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 27841] New: Add unique action types to action logs for holds
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27841 Bug ID: 27841 Summary: Add unique action types to action logs for holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a hold's Found value changes to T (for transit) for W (for waiting), the action logs simply record a modification. That makes it very difficult to search the logs specifically for the point at which a hold goes to one of those two statuses. I'd like to see them marked with their own action_logs.action values, though I'm not sure on wording that would be translatable / understandable for all. Maybe just "Transfer" and "Waiting?" Though it bothers me a bit that those aren't verbs and the rest of the action options are. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 29917] New: Logging Plug-In Usage
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29917 Bug ID: 29917 Summary: Logging Plug-In Usage Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: rcoert(a)arlingtonva.us QA Contact: testopia(a)bugs.koha-community.org Plug-in Usage is not tracked at all & it would be very helpful to have the date a plug-in was last run/generated/used added to the Home › Tools › Plugins screen. It has a "Last Updated" column which is helpful, but this information would also be useful. Alternatively, it would be great to have this added to the system logs like the cronjobs are. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 25790] New: [OMNIBUS] warnings removal
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25790 Bug ID: 25790 Summary: [OMNIBUS] warnings removal Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: nugged(a)gmail.com Reporter: nugged(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)bugs.koha-community.org, slavashishkin(a)gmail.com, stalkernoid(a)gmail.com Depends on: 25440, 25491, 25506, 25533, 25695 This is an omnibus report to group tickets/tasks related to cleaning up of warnings, mostly now emitted in logs in various cases after "use warnings" added and also where something suspicious going on. Let's clean up our beautiful Universe from noise and potential bugs! <3 :P Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25440 [Bug 25440] Remove undef and CGI warnings and fix template variables list in circulation rules https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25491 [Bug 25491] Perl warning at the login page of installer https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25506 [Bug 25506] Perl undef warning on the "About Koha" page https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25533 [Bug 25533] Perl "not numeric" warning on the "Holds" page https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25695 [Bug 25695] Missing logging of $@ in onboarding.pl after eval block -- You are receiving this mail because: You are watching all bug changes.

1 87

[Bug 31613] New: koha-z3950-responder doesn't log (apart from YAZ logging in theory)
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31613 Bug ID: 31613 Summary: koha-z3950-responder doesn't log (apart from YAZ logging in theory) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl While we pass a log file to koha-z3950-responder, that is just used by the YAZ toolkit. That's why issues like bug 28364 can't be seen. We're not logging what happens in the actual koha-3950-responder or its child processes. Most of the time that is fine... except when you have an error. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 16329] New: Koha::Logger->sql(). Unified interface to log SQL statements OR use DBIx::Log4perl
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16329 Bug ID: 16329 Summary: Koha::Logger->sql(). Unified interface to log SQL statements OR use DBIx::Log4perl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Instead of whenever needing to log SQL statements, making a custom logging output/function, introduce a centralized subroutine to handle all sql-statement logging. How the SQL-statements should be logged remains to be seen, but currently simply presenting very simple formatting we can discuss about. SQL libraries (DBI, DBIx) also allow logging SQL-statements but lack the fine-grained control Log4perl offers. Or maybe Log4perl can be integrated better to DBI / DBIx with this: https://metacpan.org/pod/DBIx::Log4perl Because I am not a huge fan of DBIx and also integrating that to Koha::Object is a lot of work, will not pursue that track further. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 16304] New: Koha::Logger, lazy load loggers so environment can be properly set.
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16304 Bug ID: 16304 Summary: Koha::Logger, lazy load loggers so environment can be properly set. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: olli-antti.kivilahti(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org If you instantiate Koha::Loggers before having set the C4::Context->interface, their interface defaults to 'opac'. This is rather undesired especially for 'commandline' scripts such as cronjobs. A solution to this is to lazyLoad loggers when they are really needed. LazyLoading might also have a performance boost when using packages that initialize a package-level logger but which never gets used. see t/Koha/Logger.t on how to replicate this issue, but here is a nutshell of how to replicate this issue: @@ file A.pm package A; use Koha::Logger; my $logger = Koha::Logger->get({category => __PACKAGE__}); #interface unknown sub doStuff { $logger->error('My interface is always "opac"'); } @@ script run.pl use C4::Context; C4::Context->interface('commandline'); use A; A::doStuff(); #error is logged using the "opac"-interface instead #of the "commandline"-interface -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 31916] New: It would be nice to make the paging in datatables and search results consistent
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31916 Bug ID: 31916 Summary: It would be nice to make the paging in datatables and search results consistent Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The paging UI is nice in the catalog search results.. it would be great to clone that styling to the general datatables paging? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 34358] New: Generalise library selection filter for datatables
by bugzilla-daemon＠bugs.koha-community.org 12 Jun '26

12 Jun '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34358 Bug ID: 34358 Summary: Generalise library selection filter for datatables Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We add a custom library select option to the patron search results datatable. We should really generalise this away from the patron-search includes so it could be used on other ajax driven datatables with the header row filters enabled. We should support both 'data-filter="libraries"' at the table heading line definition and 'filter: "libraries"' in the datatable column settings definition level. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10