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.
Add columns for each custom notification level, defaulting to null. Read from
those columns if non-null, otherwise fall back to the serialized column. Writing
will write to the new column if `events` isn't manually set.
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.
If the Sidekiq job fails for some reason, a project can be 'stuck'
pending deletion. The project can't be viewed, so it shouldn't be
available through the notification settings association as this will
throw an exception when we try to show the link.
In 8278b763d9 the default behaviour of annotation
has changes, which was causing a lot of noise in diffs. We decided in #17382
that it is better to get rid of the whole annotate gem, and instead let people
look at schema.rb for the columns in a table.
Fixes: #17382
* visiting project will create notification setting if missing
* change notification setting per project even without membership
* use notification settings instead of membership on profile page
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
It will hold notification setting per group or per project. It will
allow get rid of notification level stored in Member model
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
gfyoung