Skip to content

Instantly share code, notes, and snippets.

@krisleech

krisleech/notifier_with_audit.md

Last active October 3, 2016 15:24
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save krisleech/a942eb5d83dfa740437947b73a4e089e to your computer and use it in GitHub Desktop.
Save krisleech/a942eb5d83dfa740437947b73a4e089e to your computer and use it in GitHub Desktop.
Download ZIP
notifications
Raw
notifier_with_audit.md

Usecase: email notifications need storing for audit/regulatory purposes.

SendNotification will send and record a notification.

SendNotification = Oxygen::SendNotification.new(env: '', template_root: '')

SendNotification.call(recipients: [], subject: '', data: {}, template: '', sender_id: '')
  • template is a string or relative path to a template.
  • sender_id would typically be the class name of the object generating the notification so in the future it can find notifications it has already sent.
  • data is any hash and can later be queried. It is provided to the template. You might want to store information in data which isn't used in the template such as user_id. You might also store which field(s) triggered the notification.
FetchNotifications = Oxygen::FetchNotifications.new(env: '')
notifications = FetchNotifications.call(sender_id: 'Apr::ReportSoonOverdueNotification', data: { study_id: 88 }, since: 2.days.ago)

You can query on data, sender_id, timestamp and recipiants. since and before allow > / < for timestamps.

Since we need to query in the schemaless data attribute we need a database schema such as:

notification -< notification_data (notification_id, key, value)

If we stored username or user_id (maybe in data) we can also show a list of notifications in the UI for a user.

We could, optionally, also syndicate to the audit, or have a seperate list of notifications. Audit could be a light weight representation of notification (no body), but link to full details.

We might store notifications and have a seperate process (e.g. rake task triggered by CRON) actually send them. This will mean if SendGrid is down emails are not lost. However if the database is down email is lost.

Proberbly do not need ActionMailer, but instead can talk directly to SendGrid HTTP API via their Ruby client. This would make it non-Rails and useable from any of our gems/engines.

@krisleech
Copy link
Author

Maybe don't give recipients as email addresses but person_id?
This way we could have different kinds of notifications, other than email, in the future.
For example SMS, or in app notifications.

@krisleech
Copy link
Author

SendGrid allows custom headers, we can store the notification_id so we can reference back for bounces, click tracking etc.

@krisleech
Copy link
Author

We can use SendGrid webhooks to get notified of bounces etc. instead of polling.

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