Age | Commit message (Collapse) | Author |
|
|
|
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
|
|
|
|
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
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.
|
|
For a user with the mention notification level set, the type of their
corresponding NotificationRecipient must be :mention for them to receive an
email.
We set this correctly on notes, but we weren't adding it on new issues or MRs -
perhaps because these users are also participants. But the type of the
NotificationRecipient in that case would be :participant, not mention, so we
have to add the mentioned users manually when creating an issue or MR.
When editing an issue or MR, and there are newly-mentioned users to email, we
still use the :new_issue and :new_merge_request actions, so this works for that
case as well.
|
|
Adds a rubocop rule (with autocorrect) to ensure line break after guard clauses.
|
|
fix multiple notifications from being sent for multiple labels
Closes #37691
See merge request gitlab-org/gitlab-ce!14798
|
|
This also refactor the email_helper support spec to watch for multiple
emails being sent.
|
|
Utilizes the Devise `confirmable` capabilities. Issue #37385
|
|
|
|
|
|
|
|
where that custom setting is not enabled.
|
|
|
|
|
|
since the mere act of creating the key sends an email :|
|
|
and add one
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Refactor.notification recipient builders
See merge request !13197
|
|
|
|
`:mailer` is needed to pick it easily, while
`type: :mailer` is needed for picking it automatically for
tests located in spec/mailers/*_spec.rb
It's a bit complicated in spec/services/notification_service_spec.rb
but we'll leave it alone for now.
|
|
|
|
There were two specs that were testing the exact same thing as the spec
above it, but with additional expectations. So we opted to keep the
"more expectations" tests and deleted the duplicates.
We've also deleted one nested `before` block that was duplicating setup
of its parent context.
|
|
GPG signed commits
Closes #20268
See merge request !9546
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
services: true, no_db: true, api: true
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
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.
|
|
Use the EnforcedStyleForMultiline: no_comma option.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
|
|
|
|
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.
|
|
|