| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using custom_action and recipient filtering
Add more generic filtering to user_ids_notifiable_on
Add changelog entry
Remove commented class
Method is no longer needed
Overloading no longer required
Filter by action just in case of custom notification level
Add participant check
Fix unexpected extra notification mails
Using custom_action and recipient filtering
Add more generic filtering to user_ids_notifiable_on
Add changelog entry
Remove commented class
Method is no longer needed
Overloading no longer required
Filter by action just in case of custom notification level
Fix comment
Add repond_to? checks
Reverted custom_action filtering
Enhanced output of should_email helper
Changed :watch to :participating for custom notifiable users
Change spec variable name
Enhanced participating check
These conditions are no longer needed
Fix custom notification handling for participating type
Participating level should include maintainers
Fixed add_guest notification
Fix successful pipeline notification
Refactoring: Use maintainer? method on team instead
Add spec for new_issue: true for a custom group setting
which should have lower prio than an available project setting
Clean up specs
|
| |
|
|
| |
Probably useful as we often move these files to "new" files.
|
| |
|
|
| |
spec/features/groups/group_page_with_external_authorization_service_spec to EE
|
| |
|
|
|
| |
Backports https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10161
(code out of ee/ folder).
|
| |
|
| |
This reverts merge request !26823
|
| |
|
|
| |
spec/features/groups/group_page_with_external_authorization_service_spec to EE
|
| |
|
|
| |
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
- we now use the hierarchy class also for epics
- also rename supports_nested_groups? into supports_nested_objects?
- move it to a concern
|
| |
|
|
|
|
| |
The email is sent to project maintainers containing the last mirror
update error. This will allow maintainers to set alarms and react
accordingly.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
