Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-78142

Users receive notifications on their own changes with the option "My changes: set to "Do not notify me"

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Low Low
    • None
    • 9.12.8, 9.16.1, 10.1.1
    • Email notifications

      Issue Summary

      • Users receive notifications on their own changes with the option "My changes: set to "Do not notify me"
      • This issue only affects Issues and Projects that have Insight Field configured. The user does not have to modify the field value itself, as a notification is sent for any Issue Updated event made by the current user.
      • There are no watched objects, and the issue is not relevant to cases explained in the following article: Users receiving notifications from issues where they should not receive notifications due to the Insight application.
      • The issue only affects Edit Issue Operation (changes made using Edit screen), not Inline Edit.
      • Issue affects any project type, as long as there is an insight field used.
      • This issue was introduced between the Jira 9.4/5.4 version and the 9.12/5.12 version.

      This is reproducible on the Data Center: YES

      Steps to Reproduce

      • Install Jira Software 9.16 LTS
      • Install Jira Service Desk 5.16 LTS under Applications
      • Configure the Outgoing Email Server and reduce batching notification interval to 2 minutes, or use regular notifications in order to save a few minutes.
      • Navigate to Projects > Create Project > Create sample Data > Choose "Assets IT Service Management" as this project will create Insight/Asset fields and setup everything for us.
      • Once the project is created, navigate to the sample issue, for example, SD-9. Make sure that the current user is able to receive the Issue Updated event. Using the Jira Default Notification scheme, the user should be the assignee, reporter, or watcher of the test issue SD-9.
      • Reproduce the issue by using the Edit issue operation (the edit button) and make a change, for example summary or custom field. Take note that an email is sent to the user making a change.
      • Attempt to reproduce the issue again by using Inline Edit issue operation (by clicking on the field on the issue view and using input) and make a change, for example summary or custom field. Take note that email is not sent to the user making a change.

      Expected Results

      Jira should not receive notification about the changes they have made on the issue themself with with option "My changes: set to "Do not notify me". Taking into account the Jira Default Notification scheme, and that admin is a current and collaborator on the issue, in the atlassian-jira-outgoing-mail.log we should see the following entries:

      2024-10-15 19:05:13,706+0000 DEBUG [] JIRA-INFORM-Thread-2      [c.a.m.o.c.a.j.p.i.batching.recipients.JiraNotificationSchemeRecipientProvider] Getting recipients for com.atlassian.jira.event.issue.IssueEvent@27e4a015[issue=SD-9,comment=<null>,worklog=<null>,changelog=[GenericEntity:ChangeGroup][issue,10108][author,admin][created,2024-10-15 19:05:13.607][id,10602],eventTypeId=2,sendMail=true,params={eventsource=action, baseurl=https://myjira/jira},subtasksUpdated=true,spanningOperation=Optional.empty]
      2024-10-15 19:05:13,715+0000 DEBUG [] JIRA-INFORM-Thread-2      [c.a.m.o.c.a.j.p.i.batching.recipients.JiraNotificationSchemeRecipientProvider] Recipients: []
      

      Actual Results

      Jira sends the notification to the user about the changes they have made on the issue themself with with option "My changes: set to "Do not notify me". Taking into account the Jira Default Notification scheme, and that admin is a current assignee and collaborator on the issue, in the atlassian-jira-outgoing-mail.log we can see the following entries:

      2024-10-15 19:16:29,697+0000 DEBUG [] JIRA-INFORM-Thread-0      [c.a.m.o.c.a.j.p.i.batching.recipients.JiraNotificationSchemeRecipientProvider] Getting recipients for com.atlassian.jira.event.issue.IssueEvent@2fbf7c58[issue=SD-9,comment=<null>,worklog=<null>,changelog=[GenericEntity:ChangeGroup][issue,10108][author,admin][created,2024-10-15 19:16:29.629][id,10605],eventTypeId=2,sendMail=true,params={eventsource=action, baseurl=https://myjira/jira},subtasksUpdated=true,spanningOperation=Optional.empty]
      2024-10-15 19:16:29,709+0000 DEBUG [] JIRA-INFORM-Thread-0      [c.a.m.o.c.a.j.p.i.batching.recipients.JiraNotificationSchemeRecipientProvider] Recipients: [RecipientDTO{id=null, userKey='admin', consumerName='mailEventConsumer', status=NEW, created=2024-10-15T19:16:29.706665680Z, updated=null, sendDate=2024-10-15T19:18:29.706681384Z}]
      

      Take note that the Recipients collection is not empty. In addition, if the additional logging is enabled, for example, for package com.atlassian.jira.notification, we will see entries that the event issuer was removed from the Recipients collection, but that was not the case. These entries will be misleading when troubleshooting these kinds of issues. Here is an example that can be found in Atlassian.

      JIRA-INFORM-Thread-2 DEBUG      [c.a.jira.notification.NotificationRecipientsSource] Removed user admin with email address admin@myjiraemail.xyz from notification because they are the modifier and do not wish to be notified.
      

      Issue Root Cause

      The NotificationRecipientsSource component is responsible for retrieving recipients for a given IssueEvent and relevant notification schemes. Once all are configured the recipients are retrieved as a set, the issuer(author) of the IssueEvent is removed from the set collection if the "Do not notify me" option is configured. However, due to recent changes, this part of the code is failing to find and remove the issuer of the event. The code is unable to find the object because of the current implementation of the com.atlassian.jira.notification.NotificationRecipient#hashCode which did not account for different kinds of principal user. In addition to DelegatingApplicationUser, Edit Issue Operation retrieves the principal as InsightApplicationUser from InsightThreadContext, and in that case hash code is not the same. On the other hand, when the Inline Edit option is used, the user is again retrieved from threadLocal as DelegatingApplicationUser. In Jira 9.4, both operations would result in DelegatingApplicationUser being used and code worked perfectly.

      Workaround

      As of right now, the only workaround we have is to advise users is to use the Issue Inline edit, as opposed to the Edit Issue Operation and Screen. If your Jira customization options allow it, you can enable this option under Configuring Jira application options - Inline edit

              Unassigned Unassigned
              3984d3d058e8 Marko Radivojevic (Inactive)
              Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated: