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

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.

Imre (Admin) authored 5 years ago and Andreas Brandl committed 5 years ago

Move Contribution Analytics related spec in 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

Imre (Admin) authored 5 years ago and Andreas Brandl committed 5 years ago

Move Contribution Analytics related spec in 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.

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.