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: | 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
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 If/when we have a Content-Security-Policy, this could be useful for CSP violation reports. 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. +1 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. |