This is to be more consistent as there is already a :read_note policy in
NotePolicy. To keep other behaviour the same we've introduced a
Note#noteable_ability_name that is used anywhere this was expected.

Sean McGivern authored 5 years ago and Mayra Cabrera committed 5 years ago

The 'assigned' reason doesn't apply to notes, but the other two
can ('mentioned' and 'own_activity'), so we can still use this for note
emails.

Manoj M J authored 5 years ago and Mayra Cabrera committed 5 years ago

This change limits the number of emails
for new access requests notifications to
10 most recently active owners/maintainers

- Adds UI to configure in group and project settings
- Removes notification configuration for users when
disabled at group or project level

When sending access granted/rejected emails we should also respect
custom emails set for groups/sub-groups

When a user's notification email is set for a group, we
should use that for pipeline emails

We have one auto merge strategy today - Merge When Pipeline
Succeeds.

In order to add more strategies for Merge Train feature,
we abstract the architecture to be more extensible.

Removed arguments

Fix spec

Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).

When moving a project, it's possible that some users who had
access to the project in old path can not access the project
in the new path.

Because `project_authorizations` records are updated asynchronously,
when we send the notification about moved project the list of project
team members contains old project members, we want to notify all these
members except the old users who can not access the new location.

When moving a project, it's possible that some users who had
access to the project in old path can not access the project
in the new path.

Because `project_authorizations` records are updated asynchronously,
when we send the notification about moved project the list of project
team members contains old project members, we want to notify all these
members except the old users who can not access the new location.

Fix the CVE-2018-16476 vulnerability.

The email is sent to project maintainers containing the last mirror
update error. This will allow maintainers to set alarms and react
accordingly.

Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

Partially addresses #47424.

lulalala authored 6 years ago and Mark Chao committed 6 years ago

Display MR unmergeable reasons

The NotificationService has to do quite a lot of work to calculate the
recipients for an email. Where possible, we should try to avoid doing this in an
HTTP request, because the mail are sent by Sidekiq anyway, so there's no need to
schedule those emails immediately.

This commit creates a generic Sidekiq worker that uses Global ID to serialise
and deserialise its arguments, then forwards them to the NotificationService.
The NotificationService gains an `#async` method, so you can replace:

    notification_service.new_issue(issue, current_user)

With:

    notification_service.async.new_issue(issue, current_user)

And have everything else work as normal, except that calculating the recipients
will be done by Sidekiq, which will then schedule further Sidekiq jobs to send
each email.

Closes #23460

Adds `#build_notification_recipients` to `NotificationRecipientService`
that returns the `NotificationRecipient` objects in order to be able to
access the new attribute `reason`.

This new attribute is used in the different notifier methods in order to
add the reason as a header: `X-GitLab-NotificationReason`.

Only the reason with the most priority gets sent.

This also refactor the email_helper support spec to watch for multiple
emails being sent.

Send a confirmation email when the user adds a secondary email address. Utilizes the Devise `confirmable` capabilities. Issue #37385

An upcoming update to rubocop-gitlab-security added additional
violations.