Bug 34962

Summary:	Add a system messages feature to Koha to report issues and failures in a more visible way
Product:	Koha	Reporter:	Kyle M Hall (khall) <kyle>
Component:	Architecture, internals, and plumbing	Assignee:	Kyle M Hall (khall) <kyle>
Status:	NEW ---	QA Contact:	Testopia <testopia>
Severity:	enhancement
Priority:	P5 - low	CC:	dcook, kebliss, lisette
Version:	Main
Hardware:	All
OS:	All
Change sponsored?:	---	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:

Description Kyle M Hall (khall) 2023-09-29 16:05:22 UTC

Many web projects have a "system messages" area to report cron failures and things like that. These messages are often dismissable. I think it would be great to have a "system messages" table that we could insert things into to make staff aware that something has failed.

What I'm imagining is something like wrapping cronjob code in a try/catch and reporting cronjob failures. This would dovetail with action logs. Action logs lot you got searching for issues. This would put the issue right in front of you and would be trigger by actual failures. It could be used to report records with malformed MARC. It could be used to report items that are missing a required field that Koha assumes exists to function, and so on.

Comment 1 Kyle M Hall (khall) 2023-09-29 16:07:45 UTC

Table thoughts:
id
message type
message content
created on
dismissed

Put it in the admin section. Any admin would be able to dismiss a system message for everyone. Messages would remain in the database for viewing. Probably want to put something in cleanup_database.pl

Comment 2 David Cook 2023-11-29 02:07:31 UTC

If/when we have a Content-Security-Policy, this could be useful for CSP violation reports.

Comment 3 Kyle M Hall (khall) 2024-02-29 17:20:03 UTC

I think for an initial development, we could show a table of messages with the date/time, a "component" ( basically the module of Koha this is part of ), and the message itself.

For example, if EDI can't connect to an FTP server for a vendor EDI profile, would could have a component of "Acquisitions/EDI" and a message like "Unable to connect to remote server: Failed to connect to $vendor_ftp_host for $vendor_description ($vendor_id)".

It seems like anything connection to an external service should take advantage of this kind of feature.

Table columns could be something like:
timestamp
component
message
cleared (timestamp)

The screen would have a "clear all" button to set cleared. Cleared messages would not show in the staff interface, but would remain in the table until the cleared messages are deleted by the cleanup database cronjob.