Allow Server Admins to Create Notifications for Editors

[tempsaint]

This is a feature request. I'm not sure how doable it is, but hey, it's an idea.

I think it would be great if Server Admins were able to create global notifications that would pop-up, or display prominently on the screen, when other users logged in. Some examples of how this could be useful would be to alert editors when formats were added, notify users of upcoming server maintenance/downtime, and of course, when significant changes in future releases are coming, like we are looking at for 2.16.0 and the change to how Venue Types are handled.

Just an idea.

[jbraswell]

This is a good idea. For SEZF we've been manually editing index.php to do similar things.

[jbraswell]

I also think this is probably not too complex to implement. It could just be a free form text field in the server administration part of the UI. We'd need to create a simple single-row database table to store the value. Alternatively, this could be a good time to add a settings table, with the plan to begin migrating some config.php settings to the table in the future. This message would just be the first setting in the settings table.

[cosmastech]

Proposal:

Create notifications table with text (markdown? html?), creating user_id, created_at, and visible_until_date.

I think it would be difficult to keep this as a single row in a settings table. If we want the alert to be dismissible by users, there's an opportunity to create a pivot table (or store as JSON in a settings table, but JSON columns in MySQL are routinely pain points in my experience).

[jbraswell]

I would initially implement this as part of a settings table. We need to migrate a bunch of stuff from a config file to a db table anyway, and then build a simple UI to toggle the settings.

A created_at column is good to have on most tables. I'd wait to refactor to add things like visibility expiration until that is something we actually need. Such a refactor is simple to do, but my preference is to do it iteratively to keep from spending more time than necessary on a feature that might get used by only one or two people.

That said, my preference is to basically code freeze until we start modernizing the codebase a little. Will discuss with you on the phone later.