Message To User
- Kimyen Truong (Unlicensed)
When Synapse sends a message to user either from our notification service or on behalf of another user, we include the one click unsubscribe link in the email. When a user received an email from Synapse, they could choose to reply or forwarding the message to another user. By doing so, they accidentally forwarding their one click unsubscribe link. The user who receives the forwarding email may wish to unsubscribe to Synapse email, and may accidentally click on the sender's unsubscribe link, resulting in unsubscribe the sender instead of himself/ herself.
The problem is captured in PLFM-4078 - Getting issue details... STATUS
To fix the problem, we would limit the chance that a user could accidentally forwarding their one click unsubscribe link by:
- Replace one click unsubscribe link from user to user message with a link to their profile setting page
- Change the sender of system to user message to noreply@synapse.org
The second step of the solution requires identifying all system to user messages.
While working on this issue, we recognize all the events that Synapse sends message to our users:
| Event | Need user action? | Can turn off? | Sent from | Include user message? | Include unsub link? | Include user profile setting link? | |
|---|---|---|---|---|---|---|---|
| 1 | Someone invited me to a team | Yes | Synapse Notification | Yes | Yes | No | |
| 2 | Someone accepted my invitation | No | Synapse Notification | No | Yes | No | |
| 3 | Someone requested to join my team | Yes | Synapse Notification | Yes | Yes | No | |
| 4 | Someone granted my request | No | Synapse Notification | No | Yes | No | |
| 5 | Someone submitted a submission for my team | No | Synapse Notification | No | Yes | No | |
| 6 | Someone requested to view my entity | Yes | SWC | No | No | Yes | |
| 7 | Someone shared an entity with me | No | SWC | No | No | Yes | |
| 8 | Someone sent me a message | No | Any client & email | Yes | No | Yes | |
| 9 | I created a verification submission | Synapse Notification | No | Yes | No | ||
| 10 | My verification submission status has changed | No | Synapse Notification | Yes | Yes | No | |
| 11 | A new thread has been created | No | Yes | Broadcast Message Worker | No | No | No |
| 12 | A new reply has been created | No | Yes | Broadcast Message Worker | No | No | No |
| 13 | Password Reset | No | No | No | No | No | |
| 14 | Welcome to Synapse | No | No | No | No | No | |
| 15 | Delivery Failure | No | No | No | No | No | |
| 16 | Additional Email Validation | No | No | No | No | No | |
| 17 | New Account Email Validation | No | No | No | No | No | |
| 18 | After a new submission is created | Yes | Yes | Broadcast Message Worker | No | No | No |
| 19 | After a submission is approved | No | No | Broadcast Message Worker | No | No | No |
| 20 | After a submission is rejected | Yes | No | Broadcast Message Worker | Yes | No | No |
From this list, 6 and 7 should be sent from Synapse Notification instead of sending from SWC. In fact, in PLFM-2578 - Getting issue details... STATUS user asked that we have the same behavior when the ACL is changed from different clients. Also, SWC-3545 - Getting issue details... STATUS could be solved by adding an API for requesting access. Email should be send from the backend as a Synapse Notification email.
Users requested that after the immediate fix, we would also provide the following:
- When a user goes to unsubscribe from Synapse, we would provide them with more fine grant control. So that a user could choose to unsubscribe from certain topics in Synapse. SWC-3310 - Getting issue details... STATUS
- Provide a way for the user to retrieve all unread message while they are unsubscribed from Synapse. SWC-3311 - Getting issue details... STATUS