Skip to content

Notifications and Messages

Jeremy Zongker edited this page Aug 18, 2023 · 1 revision

Use Cases

Notification

  • A new comment on a conversation the user is involved in
  • An update to a task
  • A new event for a group
  • A new conversation for a group
  • A form has been completed

Instant Message

  • Streaming chat
  • Private message
  • Real-time updates to a conversation

Desired Workflow

  • Always log a notification so that a user has a list of them when returning to an app.
  • If the user is currently active in a web or mobile app, send a Socket notification to instantly light up a bell (maybe a toast message too)
  • Else, if the user has the B1 mobile app installed on a phone, send a Push notification to the device
  • Else, send an email notification
  • Additional notifications of the same type do not trigger additional push or email messages, until the original notification has been read.

In addition to that primary workflow, the user should be able to opt out of push and email notifications.

It’s possible the user may have left the app running on a computer they’re no longer at. We might need to still send an email the next morning if a notification has gone unacknowledged.

Database Tables

In messaging database:


CREATE TABLE notifications (

id char(11) NOT NULL,

churchId char(11) DEFAULT NULL,

userId char(11) DEFAULT NULL,

notificationType varchar(45) DEFAULT NULL,

timeSent date DEFAULT NULL,

read bit(1) DEFAULT NULL,

message text,

PRIMARY KEY (id)

);


message field contains markdown


CREATE TABLE messaging.notificationPreferences (

id CHAR(11) NOT NULL,

churchId CHAR(11) NULL,

userId CHAR(11) NULL,

allowPush BIT NULL,

allowEmail BIT NULL,

PRIMARY KEY (id)

);


API Routes

POST //messagingApi/notifications

{ userIds: [] notification: {} }

MessagingApi calls helper method directly not an API call to itself. (chat, conversations)

Concerns

Clone this wiki locally