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 plumbingAssignee: Kyle M Hall (khall) <kyle>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: angela.berrett, dcook, kebliss, lisette, magnus
Version: Main   
Hardware: All   
OS: All   
GIT URL: 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.
Comment 4 Angela Berrett 2024-12-13 21:08:49 UTC
+1
Comment 5 David Cook 2024-12-15 23:23:07 UTC
Still a +1 from me. I've been meaning to add this into other projects as well actually. 

Another consideration could be other forms of notification. Do we want to send emails to a configurable list of admins when one is added to this table? This could also be a follow-up, so long as we think about the database design of how it could be easily extended.