search

ucsf-education / moodle-theme-ucsf

A Moodle theme for the UCSF CLE site
GNU General Public License v3.0
0 stars 1 forks source link

rewrite banner alerts as standalone plugin #187

Open stopfstedt opened 3 months ago

stopfstedt commented 3 months ago

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

ctam commented 3 months ago

Looks like we could replace it with this plugin.

stopfstedt commented 3 months ago

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.