Message To User

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?

	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