What does this MR do?
NotificationRecipientService that returns the
NotificationRecipient objects in order to be able to access the new attribute
This new attribute is populated inside the
#build! method and used in the different notifier methods in order to add the reason as a header:
Only the reason with the most priority gets sent, decided by the
So far only
assigned have been implemented. Also implemented is a priority list for each 'reason' in order to send the most relevant/important reason.
own_activity gets set from within
NotificationRecipient#own_activity? when it is detected that the user
This MR also adds the reason in the footer of email notifications.
Are there points in the code the reviewer needs to double check?
- NotificationRecipient#reason is a string due to ActiveJob not being able to serialize symbols
new_issue_worker_specsay they're testing "creates a notification for the assignee" but they're really testing a notification for a mentioned user? The
assignee(s)relationship is empty/nil.
NotificationRecipientService#build!, when adding
assignednotifications for new issues/MRs, I'm adding them at the
:participatinglevel since existing specs (
notification_service_spec.rb:509) expect it to be at a level below
:mention. Is this correct? Shouldn't an assignment count as a mention?
Why was this MR needed?
See #41532 (closed). This allows users to filter their email notifications depending on the reason they were notified.
Screenshots (if relevant)
Does this MR meet the acceptance criteria?
Changelog entry added, if necessary
API support added
Tests added for this feature/bug
Has been reviewed by UX
Has been reviewed by Frontend
Has been reviewed by Backend
Has been reviewed by Database
Conform by the merge request performance guides
Conform by the style guides
Squashed related commits together