ephios-dev/ephios

Notification Framework Improvements

Closed this issue · 0 comments

problem description

The current notification system has a few downsides:

  • if a notification fails there is no system to retry them or discard them. They just sit around.
  • Notification order is not guaranteed. When doing multiple actions like confirming and then rejecting a participation, I believe there is no code in place to make sure the notifications come in in the correct order. Also,
  • obsolete notifications are still sent. When a participation doesn't exist anymore or a rejected notification for a participation that was confirmed seconds later, there is no check to make sure that the notifications content is still correct.
  • It's not real-time. users need to wait for the next periodic run to get the notifications. accepted
  • At the same time, there is no kind of batching or rate-limiting for the run_periodic task, which might lead to problems when 2 processes try to send notifications at the same time?

web

First of all, there is no web list of notifications, but I think there should be. They could even be marked as read if people open an email or click a link in it or they click on the push notification.

email

  • emails really need a nice template, with an imprint already done
  • mails should have an unsubscribe links or at least a link to the notification management page already done
  • emails should come from a contentful from-email instead of noreply@ (reply-to header) not possible
  • mass mailings don't use BCC. When informing many people about a new event, that creates dozens of individual emails and therefore smtp calls and therefore hits on our email reputation. Probably. we need to research more about that. not true

non local participants

  • From reading the code, guest participants don't have the correct URL in their (email) notifications. They aren't even given the option for push notifications, which would be so cool.

push

  • I don't think users dig the settings to enable notifications. I think we should ask them when installing the PWA or after signing up for the first time or smth like that.
  • push notifications don't (always) use symbols or good deep links to be actionable... There are probably more features we aren't using.
    • clicking the push notification could lead to a web version of the full notification to read it. That's probably better then directly redirecting to the disposition view if the users didn't read the whole notification or could not, because it was too long
  • when using multiple ephios accounts, one can't discriminate the push notifications origin because the title always says ephios. It may be good brand placement, but maybe we should incorporate some kind of short form or site URL into the sender field. Actually, my phone does show the origin URL. But same goes for the PWA itself by the way (at least on my device).

What I like about the current setup

  • I like the modularity of creating new notification types and new backends. doesn't even need the visitor pattern ;)
  • I like how we create Notifications directly on the type object. That makes it very versatile and specific. None of those random python get_item-calls like in dynamic-preferences.
  • I like that we can also send notifications to people without a user account (other kinds of participants being the only use case atm)
  • The code is easy to maintain and easy to use. It does a lot for how understandable it is imho.

Solution

I think we should rethink what a Notification object represents. Seems to me like it should not be specific to one type of notification backend but instead the act of notifying some user about something that happened, incl. fields for

  • data about sending status for all the backends
  • read (and archived) or something like what github/traewelling does.
  • data for type objects to construct the various sending content values like
    • icon
    • from_user or from_email
    • head/subject and text body

That doesn't yet answer how to do the multi-recipient BCCs (or other kinds of multi-recipient notifications for that matter. Maybe a notification can have multiple recipients?

relates issues/PRs

  • code that leads to #959
    • regarding something being sent twice: there are lots of explicit calls to the email framework right now, even by django itself (password reset, ephios account security notification, AGB sending, ...). Do we want to continue with this or use our notification framework for all emails?
  • an early try to #655
  • #372
  • #1077
  • #1041

Feedback

Do you have any thoughts on this? What do our users think/want/need?