-
Bug
-
Resolution: Unresolved
-
High (View bug fix roadmap)
-
None
-
9.9.1, 9.10.1, 9.16.0, 9.12.12, 9.12.15, 9.17.4
-
9.09
-
27
-
Severity 2 - Major
-
76
-
Issue Summary
If you have a shared mailbox A and create an incoming mail channel for this in JSM using the Microsoft Graph API. When you authorise the connection using account B, Jira will instead process incoming mail from account B rather than the defined account A.
This is reproducible on Data Center: yes
Steps to Reproduce
- Install JSM that supports Graph API
- Setup an Oauth integration with Azure, that uses Graph API permissions
- Create an incoming mail channel in JSM that uses the Microsoft Graph API protocol and is pointed to a shared mailbox
- Authorise the connection with a second user that has delegated access to the shared mailbox
- Watch Jira process mail from the second user, not the shared mailbox
Expected Results
Jira should function as normal and process incoming mail from the shared mailbox
Actual Results
Jira processes incoming mail from the authorising account
Workaround
- Turn the shared mailbox into an account, so it can authorise the connection.
- Use IMAP/POP protocols for your incoming mail
- The client credentials grant flow for the Oauth 2.0 integration implemented for the Incoming/Outgoing Mail Server has been implemented in Jira in version 9.17 under the feature JRASERVER-74324. Please use the steps from the following article as a workaround: How to setup Azure mail using Graph API with client credentials (application permissions) in Jira Data Center. For many organisations, this might be the preferred method for integration as well.
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JRASERVER-76593] Authorising a shared account using Graph API causes Jira to process emails from the wrong account
| UIS | Original: 92 | New: 76 |
| UIS | Original: 98 | New: 92 |
| Remote Link | New: This issue links to "Page (Confluence)" [ 1022136 ] |
| UIS | Original: 105 | New: 98 |
| UIS | Original: 98 | New: 105 |
| Support reference count | Original: 26 | New: 27 |
| UIS | Original: 105 | New: 98 |
| UIS | Original: 111 | New: 105 |
| UIS | Original: 118 | New: 111 |
Is there any chance we can get a ballpark ETA on this? The workarounds available are not appropriate for us and we have a deadline of three months to move inboxes to O365. If a fix is not likely to be available in the next 2-3 months we will need to start communicating to our user that the feature will be disabled, so it is very important we get some kind of indicative timeline on hen this may be released.