Till/2400 message banner

[tillprochaska]

• Messages can have a title, a date, and a level (info, warning, error, success).
• Messages can be loaded dynamically from a remote JSON endpoint (configured via ALEPH_APP_MESSAGES_URL) or set to a static value via the ALEPH_APP_BANNER variable.
• If a JSON endpoint is configured, the app will poll for changes every 15 minutes. This way, even users that keep the Aleph session open for a long time will be shown new messages with a max. 15 minutes delay.
• Messages can be hidden after a fixed amount of time. This can be useful to display a messages for some time once an incident has be resolved.
• Messages can have updates. If a message has updates, the most recent update (and the time it was posted) is displayed.

A few things to consider:

• The messages JSON endpoint can be configured via an environment variable. The value of that variable is exposed to the frontend via the app metadata. This isn’t optimal for two reasons:

  1. It creates a request waterfall, i.e. the metadata has to be loaded before being able to load messages. This only happens once on app startup and honestly this also isn’t the worst performance bottleneck, so this should be fine.

  2. If the metadata endpoint is unavailable (e.g. because the API service crashed), the frontend won’t be able to load messages, i.e. we can’t display a message banner in case of a full outage.

     The only way to change that would be to include the messages endpoint in the frontend image. That means that everyone who’d like to use this feature would have to build a customized UI Docker image. Additionally, configuring this feature would be different from configuring everything else.

     I don’t think it’s worth the effort. As an alternative generating a simple, static HTML status page with the same information would be much more sensible. Users would be able to find status information there even in case of a full outage.

• I’m unsure about naming. "Messages" is pretty generic. On the other hand, this might be used for things other than incidents/system status (e.g. announcing new features or datasets). We already use the terms alerts, notifications for different concepts.