/
Messaging services

Messaging services

Aug 18, 2016

Questions

  • When we send emails to users, should we download the body of the email and send it in the email body?  Or should we tell them to visit the portal?

    • At the moment, the body of the email == the body of the message.  And files are assumed to be stored as plain text.

  •  Should notifications of this nature be implemented now or later?

    • Also, if the affected entity has child entities, should those be included in the notification?

  • How should we tie Entities to users in terms of notifications?

    • Ownership?  << It might be this.

    • Favorites? << It might be this.

    • Permissions?  << I don't think it's this.

    • Something else?  << It could be a completely new set of services, allowing users to enable/disable notification.  (Could be initialized from Favorites and Owners.)

Objects

Name

DBO

Migration

DTO

Name

DBO

Migration

DTO

MessageContent

(Immutable after creation)

  • Primary key: ID

  • Foreign key: CreatedBy (UserGroup)

  • Foreign key: MessageBody (S3 File Handle ID)

  • Etag

  • CreatedOn

Backup via ID

Note:  Etag is required because MessageStatus is mutable.

Interface

  • ID

  • CreatedBy (principal ID)

  • S3 File Handle ID

  • CreatedOn

MessageToUser

(Immutable after creation)

  • Foreign key: ID (MessageContent)

  • Subject (nullable)

  • Self foreign key: InReplyTo (ID) (nullable)

  • Foreign key: InReplyToRootId

    • Recursive foreign key to primary key

     

Secondary to MessageContent

Implements MessageContent

  • Subject (string, optional)

  • Set of recipient IDs

  • inReplyTo (optional)

  • inReplyToRoot (optional)

MessageRecipient

(Immutable after creation)

  • Foreign key: ID (MessageContent)

  • Foreign key: Recipient ID (UserGroup)

Secondary to MessageContent

 

MessageStatus

  • Foreign key: ID (MessageContent)

  • Foreign key: Recipient ID (UserGroup)

  • States: UNREAD, READ, ARCHIVED

Secondary to MessageContent

  • ID

  • Recipient

  • State

Comment

(Immutable after creation)

  • Foreign key: ID (MessageContent)

  • Target type (Enum ObjectType)

  • Target ID

TBD:  references to other Comments in the conversation*

Secondary to MessageContent

Implements MessageContent

  • Target type

  • Target ID

MessagingSettings

Part of UserProfile

Use existing services to support this

Secondary to UserGroup

Should email be sent?
Should emailed messages be READ automatically?
Other options (as necessary)
Blacklist of blocked users
CommentVotes

  • Primary key: Message ID

  • Up votes

  • Down votes

  • Is-comment-inappropriate votes

TBD

  • ID

  • Up

  • Down

MessageBundle

 

 

Bundles the MessageToUser and Message Status

MessageRecipientSet

 

 

  • Set of recipient IDs

'* per Marcel, Comments may have a more complex set of references/relationships than Messages to Users have.  Rather than just 'inReplyTo', it might be that one Comment is an 'answer' to another comment which is a question.  Further, the multiple answers to a question may have 'previous' references which order them.

Other TODOs

Throttle message input 

When adding a new person to a conversation, the new person should get the whole history of the conversation

Configure Amazon SES

Add methods to send messages according to templates

Message sender (worker)

Extend ObjectType to include a "MESSAGE" type
Have DBOMessage extend ObservableEntity
Send a change message when a message is created
Subscribe worker to the repo-changes topic
Look for MESSAGE-CREATED changes to process
The worker should always check to see if a message has already been sent, so that messages do not get resent every time the stack changes.
Whenever the message sending worker encounters an error:
Send the sender of the message a notification with the summary of delivery failures
Add CloudWatch metrics to count delivery failures
If the message cannot be sent to anyone, mark the sender as the receiver of the message so that it doesn't get reprocessed (i.e. after migration)
Process change of other ObjectTypes (i.e. ENTITY) for notifications
Needs additional state: either a link between ObjectID/Type and messageContent or ObjectID/Type and UserID (to prevent messages from being resent everytime the stack blows away the change messages)