Summary
Notifications triggered via the Jira REST API will have the "reply-to" header as the user who triggered the notification instead of Jira's mail server (jira@instance.atlassian.net). This will cause email replies to go directly to the user, instead of adding a comment to the ticket.
Steps to Reproduce
- In a Jira Cloud instance, create a test ticket. Example: TES-1.
- Make sure that some other user has permission to see the ticket.
- Execute the following, in order to trigger a notification.
curl -D- -X POST \ --url 'https://instance.atlassian.net/rest/api/3/issue/TES-1/notify' \ -u '<user>:<token>' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --data '{ "htmlBody": "Lorem ipsum <strong>dolor</strong> sit amet, consectetur adipiscing elit. Pellentesque eget venenatis elit. Duis eu justo eget augue iaculis fermentum. Sed semper quam laoreet nisi egestas at posuere augue semper.", "subject": "Mail Subject", "textBody": "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque eget venenatis elit. Duis eu justo eget augue iaculis fermentum. Sed semper quam laoreet nisi egestas at posuere augue semper.", "to": { "users": [ { "name": "<randomuser>", "active": true } ] } }'
Expected Results
The mail header should look like this:
From: "User who triggered the notification" <jira@instance.atlassian.net>
Reply-To: jira@instance.atlassian.net
To: randomuser@mail.com
Actual Results
From: "User who triggered the notification" <jira@instance.atlassian.net> Reply-To: user_who_triggered_the_notification@mail.com To: randomuser@mail.com
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JRACLOUD-72051] Wrong mail header when triggering notifications via issue/notify API
This looks like a GDPR regression. In fact, this is not a regression (at least not recent). The /notify REST endpoint already behaved this way last year.
With that in mind, the default behavior should not be changed, as it would potentially impact customers. Instead, an option should be added to the /notify REST API to specify what the reply-to address should be, just like the AdhocNotificationService offers on Jira Server - either the real address, or Jira's reply to address (the same one that's used by standard notifications, which actually varies by project).
Hi David,
Unfortunately for GDPR reasons that may not be an option for us. That being said, we definitely need to investigate what the compliant behaviour for this endpoint would be and if necessary make a communications and transition plan if any changes are necessary. For the moment it seems that this ticket is no longer needed, and we'll investigate GDPR implications internally. Any needed changes will be communicated.
Regards,
Oliver