Versions Compared

Old Version 154

changes.mady.by.user Joseph Wu

Saved on

compared with

New Version Current

changes.mady.by.user Ziming Dong

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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.
  • Jira Legacy
    serverJIRA (sagebionetworks.jira.com)
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    serverIdba6fb084-9827-3160-8067-8ac7470f78b2
    keyPLFM-1039
     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?
    • Proposed implementation:
      • On create/update of ACL, fetch the original ACL
      • Compare the original with the new ACL and send a message to all users that have changed permissions
      • Message will contain the ID/alias of the person who made the change and the entity ID.  It may also contain the set of permissions.  
  • 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.)

...

  •  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 (question)
  •  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
      •  Delivery failure
      •  Entity shared
      •  Entity changed
      •  TBD

Message sender (worker)

...