-
Suggestion
-
Resolution: Cannot Reproduce
-
12
-
NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.
Problem Definition
When JIRA receives a mail to create issue from another JIRA instance, having X-JIRA-FingerPrint prevents JIRA to create issue and throws the below error in the logs:
Received message with another JIRA instance's fingerprint
For more detailed information you can refer to:
https://confluence.atlassian.com/display/JIRAKB/JIRA+Email+Finger+Print
Suggested Solution
To enable the administrator to have an option to be able to create issues. However, this might lead to loop issues.
This feature is to avoid loop and loop detection so we do not recommend to enable it, unless we get Atlassian Development Team idea about it.
Do note that Atlassian do not support customization as described on the documentation as outlined in our Atlassian Support Offerings. Please only try if you are confident on doing so and we strongly encourage customers to perform the check on test environment first before applying to production.
Explanation By Customer(In the comments):
The increasing number of JIRA instances, and how we'd like them to work together, raises an interesting use case for us:
Desired Outcome
What we'd like to do is create issues in our JIRA instance from another organisation's JIRA emails to us. We can't do that because our JIRA handler detects these emails as correctly belonging to another JIRA instance.
Steps:
Organisation A (OrgA) and Organisation B (OrgB) both have their own JIRA instances.
OrgA sends support request email to OrgB
OrgB JIRA mail handler detects email and creates issue (Issue Key ORGB-1)
OrgB sends JIRA issue notification to OrgA
OrgA JIRA mail handler detects email and create issue (Issue Key ORGA-1)
OrgA JIRA local users / groups can use ORGA-1 to track issue progress with OrgB without needing access to OrgB JIRA.
Actual Outcome
Organisation A (OrgA) and Organisation B (OrgB) both have their own JIRA instances.
Steps:
OrgA sends support request email to OrgB
OrgB JIRA mail handler detects email and creates issue (Issue Key ORGB-1)
OrgB sends JIRA issue notification to OrgA
OrgA JIRA mail handler detects email from OrgB and rejects it with the following error in the logs: "Received message with another JIRA instance's fingerprint"
No issue is created in OrgA JIRA.
This would be extremely useful because it allow users or user groups issue visibility and tracking with issues lodged with another organisation's JIRA.
- is related to
-
- Gathering Interest
[JRACLOUD-44107] To Be Able to Create Issues By JIRA Mail Handler Fingerprint
Do the watchers of this ticket still experience this issue? I am not able to reproduce it and we have not had any recent reports. The confluence article referred to in the Description refers to Jira Server, not Cloud, so I'm wondering if this error still occurs. Thank you!
It's rather bizarre that 6.5 years later, Jira still does not natively provide a way for two Jira instances to integrate - or at least ingest email from other Jira instances. This might simply be solved by allowing Jira admins to allowlist Jira instance fingerprints.
We just moved our web team's support process to Jira Service Desk from an ancient version of Request Tracker and found out about this unanticipated feature. The web team uses a single support email address to receive product service alerts from outside vendors and user/staff reports of website issues. The vendor alerts are for integrated services within the website umbrella that this team needs within a single ticketing application. Because some of these outside vendors use Jira to manage their own email alerts to customers, necessary tickets for the web team are being blocked.
The settings as they are prevent completely separate companies from using Jira or Jira Service Desk to communicate with each other. This would work great if settings existed to only block X-JIRA-FingerPrint header emails from within an organization and allow emails between organizations.
Best,
Tim
Thanks for creating this issue Sam.
The increasing number of JIRA instances, and how we'd like them to work together, raises an interesting use case for us:
Desired Outcome
What we'd like to do is create issues in our JIRA instance from another organisation's JIRA emails to us. We can't do that because our JIRA handler detects these emails as correctly belonging to another JIRA instance.
Steps:
Organisation A (OrgA) and Organisation B (OrgB) both have their own JIRA instances.
- OrgA sends support request email to OrgB
- OrgB JIRA mail handler detects email and creates issue (Issue Key ORGB-1)
- OrgB sends JIRA issue notification to OrgA
- OrgA JIRA mail handler detects email and create issue (Issue Key ORGA-1)
- OrgA JIRA local users / groups can use ORGA-1 to track issue progress with OrgB without needing access to OrgB JIRA.
Actual Outcome
Organisation A (OrgA) and Organisation B (OrgB) both have their own JIRA instances.
Steps:
- OrgA sends support request email to OrgB
- OrgB JIRA mail handler detects email and creates issue (Issue Key ORGB-1)
- OrgB sends JIRA issue notification to OrgA
- OrgA JIRA mail handler detects email from OrgB and rejects it with the following error in the logs: "Received message with another JIRA instance's fingerprint"
- No issue is created in OrgA JIRA.
This would be extremely useful because it allow users or user groups issue visibility and tracking with issues lodged with another organisation's JIRA.
Kind Regards,
Tran
As I did not receive any responses to this comment I am closing this ticket.
If you do not think this issue should have been closed, please add a comment here saying why and we can reopen it.