Commit graph

6 commits

Author SHA1 Message Date
Sean McGivern
60bd2ae372 Ensure NotificationRecipientService doesn't modify participants
Even though it does modify the participants of the notification target in some
cases, this should have been safe, as different workers are responsible for
creating the notifications for each target. However, this is at best confusing,
and we should ensure we don't do that.
2017-06-28 12:14:44 +01:00
Sean McGivern
e94c1028c1 Deserialise existing custom notification settings
Create a post-deployment migration to update all existing notification settings
with at least one custom level enabled to the new format. Also handle the same
conversion when updating settings, to catch any stragglers.
2017-06-15 15:15:13 +01:00
Valery Sizov
387c4b2c21 Backport of multiple_assignees_feature [ci skip] 2017-05-04 17:11:53 +03:00
Sean McGivern
a1805cbcd5 Quiet pipeline emails
1. Never send a pipeline email to anyone other than the user who created
   the pipeline.
2. Only send pipeline success emails to people with the custom
   notification setting for enabled. Watchers and participants will
   never receive this.
3. When custom settings are unset (for new settings and legacy ones),
   act as if failed_pipeline is set.
2017-04-03 13:59:48 +01:00
Stan Hu
c4c3731159 Fix changes that were removed when code moved to NotificationReceipientService 2017-03-17 16:07:04 -07:00
Dongqing Hu
90ade76b2e Resolve "Extract logic of who should receive notification into separate classes" 2017-03-17 17:56:04 +00:00