Questions
Objects
Name | DBO | Migration | DTO |
---|
(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
|
(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)
|
(Immutable after creation) | - Foreign key: ID (MessageContent)
- Foreign key: Recipient ID (UserGroup)
| Secondary to MessageContent | |
| - Foreign key: ID (MessageContent)
- Foreign key: Recipient ID (UserGroup)
- States: UNREAD, READ, ARCHIVED
| Secondary to MessageContent | |
(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 |
| 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
|
| - Primary key: Message ID
- Up votes
- Down votes
- Is-comment-inappropriate votes
| TBD | |
| | | Bundles the MessageToUser and Message Status |
| | | |
'* 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
- Max 10 creations per minute
- Max 50 recipients
- When adding a new person to a conversation, the new person should get the whole history of the conversation
- Might be implemented by forwarding ALL the previous messages
- OR by concatenating all previous into one new message
Configure Amazon SES
- Automated proposal:
- Reroute bounce and complaints to SNS
- Have a worker subscribe to the topic via SQS
- Have a worker disable emails to hard-bounced recipients
- The worker may email a Google Group to notify us of anything it cannot handle
- Also flip flags in settings for complaints
- Store the bounce/complaint in a blob

- Should users be notified of bounces? <<< Yes, and (1) this is a special case of 'notification', i.e. a Message triggered by a Synapse event, (2) perhaps user can configure email receipt to avoid excessive email from notifications (or other sources)
- Add methods to send messages according to templates
- Each individual Message should be stored in its final form.
- This design choice would change for very very large notification message volumes.
- Templates:
- Password reset
- Welcome
- Entity shared
- Entity changed
- TBD
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.
- A message has been sent if there is a recipient. The worker is in charge of making sure all sent messages have at least one recipient. In the case where a user sends a message to multiple recipients, all of which are not visible to the user, then the worker should bounce the message back to the user, along with a bounce message. This ensures the message has a row in the MessageStatus table.
- 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
Services
- Sorting & Pagination
- Sort by creation date
- Sort by subject
- Sort by recipient name
Method | URI | Body | Parameters | Return | Description | Permission |
---|
| /message | MessageToUser | | MessageToUser | Sends a message. Note, message delivery permission is on a recipient-by-recipient basis, asynchronous to the message creation. Unauthorized delivery may result in silent failure or a bounce message (TBD). | Authenticated User Must be admin to send to AUTH_USERS Must have SEND_MESSAGE permission on team to send to team |
| /message/inbox | | Sorting + pagination | Paginated results<MessageBundle> | Gets all messages the authenticated user has received | Authenticated User
|
| /message/outbox | | Sorting + pagination | Paginated results<MessageToUser> | Gets all messages the authenticated user has sent | Authenticated User |
| /message/{id} | | | MessageToUser | Gets a specific message | Sender or Receiver |
| /message/{id}/forward | MessageRecipientSet | | MessageToUser | Forwards a message to other recipients. This is equivalent to getting a (visible) message and POST-ing it to /message | Sender or Receiver |
| /message/{id}/conversation | | Sorting + pagination | Paginated results<MessageToUser> | Gets messages belonging in the same thread as the message ID. The list is filtered according to the user's ID. | Sender or Receiver |
| /message/status | MessageStatus | | | Marks a message as: | Receiver |
| /entity/{id}/message | MessageToUser | | MessageToUser | Sends a message to the creator or administrator of the given entity. This allows users to ask for permission to see restricted entities. Added per  | Authenticated user |
| /entity/{id}/comment | Comment | | Comment | Method for commenting on an entity. | Authenticated user with SEND_MESSAGE permission on entity |
| /entity/{id}/comment | | Sorting + pagination | Paginated results<Comment> | Gets messages belonging to the thread tied to the entity. | Authenticated user with READ permission on entity |