Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rewrite banner alerts as standalone plugin #187

Open
stopfstedt opened this issue Jul 31, 2024 · 2 comments
Open

rewrite banner alerts as standalone plugin #187

stopfstedt opened this issue Jul 31, 2024 · 2 comments

Comments

@stopfstedt
Copy link
Member

stopfstedt commented Jul 31, 2024

the current implementation is flawed in several ways

  1. it has an fixed alert "bank" of 10 slots that can be turned off and on, rather than a true lifecycle. this results in recycling of alert slots. if a slot gets reused too soon, part of the audience may not receive it (see next bullet item).
  2. alerts can never truly be dismissed by the user. when a user clicks on a banner alert, it gets "dismissed" by flagging it as "seen" in the user's session. when the session refreshes (e.g. the users logs out and back in), the alerts will resurface.
  3. alerts are completely mutable. any attribute - start/end, recurrence pattern, target pages, its message, etc. can be modified at any time. if modifications are made while an alert is "live", then it is not clear who received what message from the same given alert.
  4. alert administration is cumbersome - the settings form is static. switching the alert recurrence pattern requires a saving the form before the pattern-specific settings can be provided. form validation is also bugged - on pattern switch, it throws form validation errors that pertained to the previous state of the alert. 1
  5. alert output is baked into the theme - alert output is rendered in our theme's customized page template, making the whole feature non-reusable.

proposed solutions

  1. implement a new model and workflow that would allow for the creation and deletion of alerts.
  2. persist dismissed alerts in the database. dismissed alerts records will be deleted when the corresponding alert is deleted.
  3. prevent editing/updating of existing alerts. discussion point: - what attributes should be made immutable?
  4. make entry form dynamic with JavaScript.
  5. replace in-template rendering with a client-side/JS solution. rather than pushing alerts into the output server-side, fetch active alerts on page load from an API endpoint and render them client-side.
  6. provide non UI interfaces (command line and/or web service extensions) for creating/updating/deleting banner alerts. This way, the creation of notifications that need to happen on a recurring basis (e.g. the Wednesday morning site-maintenance alert) can be scripted.

footnotes

Footnotes

  1. image

@ctam
Copy link
Contributor

ctam commented Aug 1, 2024

Looks like we could replace it with this plugin.

@stopfstedt
Copy link
Member Author

Looks like we could replace it with this plugin.

there's some functional overlap, but it's missing a lot of what our feature does, and vice versa. this is not a drop-in replacement.

what i'm trying to do here is sketch out a solution that addresses the current shortcomings, but doesn't result in a loss of functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants