| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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
|
|
These are not required because MySQL is not
supported anymore
|
|
When a user's notification email is set for a group, we
should use that for pipeline emails
|
|
Updates changed method names and fixes spec failures
|
|
When cache_collection_render runs we end up reading and writing
things to redis even if we already have the rendered field cached
in the DB. This commit avoids using redis at all whenever we have
the field already rendered in the DB cache.
|
|
updated several specs and factories to accomodate new permissions
|
|
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.
|
