<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=20689) </details> <!--IssueSummary end--> MR https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/16160 implements a way to signal to the user why they have received an email notification, but only implements `own_activity`, `assigned`, and `mentioned` reasons. The original issue (gitlab-ce#41532) has some more relevant discussion. This issue is meant to encompass future work required in order to define all possible reasons for a user to be notified. For example: - Label subscription - Watching the project, although not a participant in the topic of the email. - Participant (has commented in the past or is issue owner) - Subscriber We could also consider having a separate reason for the owner of the issue/mr/etc DarwinJS: Below I am suggesting using "Event" data that may already exist in the data turned over to the notification system. ## Proposal - Add a `X-GitLab-NotificationReason` header that contains the possible values from the user's notification settings (ex: `watch`, `participate`, `on mention`, `custom`) - Add a `X-GitLab-NotificationType` header that contains the event that triggered the notification (ex: `merged`, `new commit`, `merge conflict`, ...) ## Non-exhaustive list of notification types - ....