summaryrefslogtreecommitdiff
path: root/app/services/notification_recipient_service.rb
Commit message (Collapse)AuthorAgeFilesLines
* Refactor `add_recipients`blackst0ne-rails5-fix-frozen-arrayblackst0ne2018-04-091-3/+2
|
* [Rails5] Fix spec/requests/projects/cycle_analytics_events_spec.rbblackst0ne2018-04-071-1/+1
|
* Add discussion APIjprovazn-apiJan Provaznik2018-03-071-1/+1
| | | | | * adds basic discussions API for issues and snippets * reorganizes notes specs (so same tests can be used for all noteable types - issues, MRs, snippets)
* Initial work to add notification reason to emailsMario de la Ossa2018-01-161-22/+26
| | | | | | | | | | | 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.
* Fix watch level for mentions in descriptionSean McGivern2017-12-041-1/+12
| | | | | | | | | | | | | | | 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.
* actually use the :participating notification typehttp://jneen.net/2017-08-211-1/+1
|
* rubocop style fixhttp://jneen.net/2017-08-031-1/+1
|
* add a comment warning that note.project may be nilhttp://jneen.net/2017-08-031-0/+4
|
* remove build_relabeled_recipientshttp://jneen.net/2017-08-031-19/+0
|
* move the read_ability logic into NotificationRecipienthttp://jneen.net/2017-08-031-16/+0
|
* rm unused methodshttp://jneen.net/2017-08-031-26/+0
|
* disable the delegate cophttp://jneen.net/2017-08-031-0/+1
|
* deparameterize `project`http://jneen.net/2017-08-031-13/+17
| | | | since 99% of the time it's `target.project` anyways.
* unmemoize read_abilityhttp://jneen.net/2017-08-031-8/+9
| | | | since it's only called once now in make_recipient
* rm unused NewNote#subjecthttp://jneen.net/2017-08-031-4/+0
| | | | | its functionality is swept into the project permission check in NotificationRecipient#has_access? now
* clearer argument namehttp://jneen.net/2017-08-031-2/+2
|
* short-circuit if there is no policy, and add :read_project checkhttp://jneen.net/2017-08-031-5/+1
|
* force queries to include notification settingshttp://jneen.net/2017-08-031-2/+11
|
* use a simple pluck, since equivalent filtering happens laterhttp://jneen.net/2017-08-031-3/+1
|
* style fixeshttp://jneen.net/2017-08-031-1/+2
|
* .notifiable_users: compact the passed-in usershttp://jneen.net/2017-08-031-1/+1
|
* default the project to target.projecthttp://jneen.net/2017-08-031-1/+2
|
* use intersection and diff operators instead of eachhttp://jneen.net/2017-08-031-22/+2
|
* make sure #custom_action is always definedhttp://jneen.net/2017-08-031-0/+4
|
* move Recipient to its own NotificationRecipient filehttp://jneen.net/2017-08-031-109/+7
|
* move the #build_* methods to static, parameterize the projecthttp://jneen.net/2017-08-031-31/+26
|
* factor out .notifiable_usershttp://jneen.net/2017-08-031-36/+4
|
* don't elevate to :watch if no @custom_action is providedhttp://jneen.net/2017-08-031-1/+1
|
* rm the @builder argument and factor out .notifiable_usershttp://jneen.net/2017-08-031-13/+37
|
* move filtering logic into Recipient classhttp://jneen.net/2017-08-031-99/+102
|
* add builder helpers with levels and start to separate out #filter!http://jneen.net/2017-08-031-54/+113
|
* make recipients mutative during the buildhttp://jneen.net/2017-08-031-64/+73
|
* move build_custom_key to Defaulthttp://jneen.net/2017-08-031-8/+6
|
* factor out the `target` argument to helpershttp://jneen.net/2017-08-031-19/+19
|
* move the build arguments to the initializershttp://jneen.net/2017-08-031-14/+60
|
* move the builders to classes with a #buildhttp://jneen.net/2017-08-031-219/+257
|
* use notification_setting_for_user_project in reject_usershttp://jneen.net/2017-08-031-18/+2
|
* protect against nil project/group/settinghttp://jneen.net/2017-08-031-4/+4
|
* move notification_setting_for_user_project to a public class methodhttp://jneen.net/2017-08-031-13/+13
|
* move the ability check to reject_users_without_accesshttp://jneen.net/2017-08-031-1/+2
|
* Ensure NotificationRecipientService doesn't modify participantsSean McGivern2017-06-281-7/+10
| | | | | | | Even though it does modify the participants of the notification target in some cases, this should have been safe, as different workers are responsible for creating the notifications for each target. However, this is at best confusing, and we should ensure we don't do that.
* Deserialise existing custom notification settingsdeserialize-custom-notificationsSean McGivern2017-06-151-4/+4
| | | | | | 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.
* Backport of multiple_assignees_feature [ci skip]Valery Sizov2017-05-041-1/+6
|
* Quiet pipeline emailsquiet-pipelinesSean McGivern2017-04-031-6/+36
| | | | | | | | | | 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.
* Fix changes that were removed when code moved to NotificationReceipientServiceStan Hu2017-03-171-3/+3
|
* Resolve "Extract logic of who should receive notification into separate classes"Dongqing Hu2017-03-171-0/+293
View Lorry Controller Status