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

Authorising a shared account using Graph API causes Jira to process emails from the wrong account

XMLWordPrintable

      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

      1. Install JSM that supports Graph API
      2. Setup an Oauth integration with Azure, that uses Graph API permissions
      3. Create an incoming mail channel in JSM that uses the Microsoft Graph API protocol and is pointed to a shared mailbox
      4. Authorise the connection with a second user that has delegated access to the shared mailbox
      5. 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

            [JRASERVER-76593] Authorising a shared account using Graph API causes Jira to process emails from the wrong account

            Colin Carlton added a comment -

            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.

            Colin Carlton added a comment - 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.

            Marko Radivojevic added a comment -

            Hi d438ea5276bf

            I wanted to reach out to let you know that we have reopened this bug because we have confirmed a regression in the fixed versions. I understand how frustrating this situation can be, and to make sure we avoid this situation I have updated the workaround section to suggest that our customers use client credentials for now. Thank you for expressing your concerns about this issue and for contacting our support team. Your input has been invaluable in helping us identify this regression, and we truly appreciate your collaboration. We are committed to resolving this issue in the future, so please keep watching the issue in order to stay up to date on our progress.
            Thank you very much for understanding.
            Kind Regards,
            Marko Radivojevic
            Atlassian Support

            Marko Radivojevic added a comment - Hi d438ea5276bf I wanted to reach out to let you know that we have reopened this bug because we have confirmed a regression in the fixed versions. I understand how frustrating this situation can be, and to make sure we avoid this situation I have updated the workaround section to suggest that our customers use client credentials for now. Thank you for expressing your concerns about this issue and for contacting our support team. Your input has been invaluable in helping us identify this regression, and we truly appreciate your collaboration. We are committed to resolving this issue in the future, so please keep watching the issue in order to stay up to date on our progress. Thank you very much for understanding. Kind Regards, Marko Radivojevic Atlassian Support

            Carl Price added a comment -

            I have had a response from Atlassian support on this:
            "Quickly looked at the code changes for JRASERVER-76593 in the atlassian-msgraph-mail library, and I believe that we have a fallback in place that will use /me endpoint if the /users/ endpoint fails. I will check the idea behind the design and let you know if this is an expected behavior and how it should work in practice."

            So if the endpoint fails for whatever reason it reverts back to reading mail from the authorising account! I believe this to be a terrible fail back for obvious reasons. I will update you all again once I know more.

            Carl Price added a comment - I have had a response from Atlassian support on this: "Quickly looked at the code changes for JRASERVER-76593 in the atlassian-msgraph-mail library, and I believe that we have a fallback in place that will use /me endpoint if the /users/ endpoint fails. I will check the idea behind the design and let you know if this is an expected behavior and how it should work in practice." So if the endpoint fails for whatever reason it reverts back to reading mail from the authorising account! I believe this to be a terrible fail back for obvious reasons. I will update you all again once I know more.

            Carl Price added a comment -

            Hi all,

            Please be weary of this fix. I have tested this on JSD 5.12.15 as the fix was back ported to the LTS - [Issues resolved in 5.12.12 | Atlassian Support | Atlassian Documentation|https://confluence.atlassian.com/servicemanagement/issues-resolved-in-5-12-12-1425670250.html] and it does work, or so I thought. I have come in to work today to find that for 1 minute on Sunday 26th Jan tickets were created from email read from the authorising account and not the email address setup in the configuration. I am raising a case with support now and will let you know the outcome.

            Carl Price added a comment - Hi all, Please be weary of this fix. I have tested this on JSD 5.12.15 as the fix was back ported to the LTS - [Issues resolved in 5.12.12 | Atlassian Support | Atlassian Documentation|https://confluence.atlassian.com/servicemanagement/issues-resolved-in-5-12-12-1425670250.html] and it does work, or so I thought. I have come in to work today to find that for 1 minute on Sunday 26th Jan tickets were created from email read from the authorising account and not the email address setup in the configuration. I am raising a case with support now and will let you know the outcome.

            Craig Shannon added a comment - - edited
            Atlassian Update – 17 July 2024

            Hi Everyone,

            From Jira 9.16 this bug has been resolved. The client will now use the /users/sharedEmailAddress/messages endpoint rather than always defaulting to the /me/messages endpoint which retrieves emails from the account used to authorise the connection, rather the the one configured in Jira or JSM.

            To enable retrieving emails from a shared mailbox, it is required to add the following API permissions on your Azure portal to the GraphAPI scope:

            Mail.ReadWrite.Shared
Mail.ReadWrite
offline_access

            You also need to add the following URLs to the Scopes section in the application link configuration in Jira: 

            https://graph.microsoft.com/Mail.ReadWrite.Shared 
https://graph.microsoft.com/Mail.ReadWrite
https://graph.microsoft.com/offline_access

            With these scopes added, after re-authorising, emails should be pulled from the shared mailbox that is defined in the JSM configuration rather than the account that was used to authorise. 

            For more information on setting up Microsoft GraphAPI in Jira, see https://confluence.atlassian.com/jiracore/set-up-a-mail-server-with-the-microsoft-graph-api-protocol-1236437555.html.

            Thanks,
            Craig Shannon
            JSM DC

            Craig Shannon added a comment - - edited Atlassian Update – 17 July 2024 Hi Everyone, From Jira 9.16 this bug has been resolved. The client will now use the /users/sharedEmailAddress/messages endpoint rather than always defaulting to the /me/messages endpoint which retrieves emails from the account used to authorise the connection, rather the the one configured in Jira or JSM. To enable retrieving emails from a shared mailbox, it is required to add the following API permissions on your Azure portal to the GraphAPI scope: Mail.ReadWrite.Shared Mail.ReadWrite offline_access You also need to add the following URLs to the Scopes section in the application link configuration in Jira:  https: //graph.microsoft.com/Mail.ReadWrite.Shared https: //graph.microsoft.com/Mail.ReadWrite https: //graph.microsoft.com/offline_access With these scopes added, after re-authorising, emails should be pulled from the shared mailbox that is defined in the JSM configuration rather than the account that was used to authorise.  For more information on setting up Microsoft GraphAPI in Jira, see https://confluence.atlassian.com/jiracore/set-up-a-mail-server-with-the-microsoft-graph-api-protocol-1236437555.html . Thanks, Craig Shannon JSM DC

            Lukasz Pieczkowski added a comment -

            Proposed workaround demands an extra MS account - extra external cost for your customers!

            This is for a feature you deliver and sell!

            Please up-prio this one.

            Lukasz Pieczkowski added a comment - Proposed workaround demands an extra MS account - extra external cost for your customers! This is for a feature you deliver and sell! Please up-prio this one.

            Marianne Lee (SVV) added a comment -

            We are unable to use the proposed workaround solution, as we need to both migrate to use the Graph API and shared mailboxes. It is not an option for us to use individual mailboxes to process incoming mails.

            Are there other workarounds? If not, I hope this bug can be prioritised instead of the current "Low" as this is a show-stopper for us.

            Affected version includes 9.12.x.

            Marianne Lee (SVV) added a comment - We are unable to use the proposed workaround solution, as we need to both migrate to use the Graph API and shared mailboxes. It is not an option for us to use individual mailboxes to process incoming mails. Are there other workarounds? If not, I hope this bug can be prioritised instead of the current "Low" as this is a show-stopper for us. Affected version includes 9.12.x.

            Philippe LEJEUNE added a comment - - edited

            I confirm this is a blocking point for us regarding a major migration for our Eu Large Bank

            ; this should really be looked at with urgency at Athassian, if they care for their major clients

            Hope they solve it soon

             

            regards

            Philippe LEJEUNE added a comment - - edited I confirm this is a blocking point for us regarding a major migration for our Eu Large Bank ; this should really be looked at with urgency at Athassian, if they care for their major clients Hope they solve it soon   regards

            SDLC Support added a comment - - edited

            Hi Team,

            This bug is a blocker to transition incoming mail handlers from using POP to MS Graph API.  Please prioritize this bug and provide a fix in the Jira 9.x version. 
            This is for a large EU bank who wants to migrate incoming mail handlers from using POP to MS Graph API. 

            Thanks,

            SDLC Support added a comment - - edited Hi Team, This bug is a blocker to transition incoming mail handlers from using POP to MS Graph API.  Please prioritize this bug and provide a fix in the Jira 9.x version.  This is for a large EU bank who wants to migrate incoming mail handlers from using POP to MS Graph API.  Thanks,

            Ravilal Gunaratne added a comment -

            This should be fix as soon as possible. all the modern mailbox integrations required auth2.0 similar integration. 

             

             

            provided workarounds may have issues .

             

            1. Turn the shared mailbox into an account, so it can authorize the connection - This one required additional M365 E3 license. 
            2. Use IMAP/POP protocols for your incoming mail - IMAP/POP may not work in some disconnected environment since only web requests allowed to go internet via proxy. Also pop/imap will be depreciate soon.

            Any plans to fix the Bug. 

            Ravilal Gunaratne added a comment - This should be fix as soon as possible. all the modern mailbox integrations required auth2.0 similar integration.      provided workarounds may have issues .   Turn the shared mailbox into an account, so it can authorize the connection - This one required additional M365 E3 license.  Use IMAP/POP protocols for your incoming mail - IMAP/POP may not work in some disconnected environment since only web requests allowed to go internet via proxy. Also pop/imap will be depreciate soon. Any plans to fix the Bug. 

              399904f8a539 Tripta Kaur
              7550ef5838c5 Tom Offin
              Affected customers:
              26 This affects my team
              Watchers:
              39 Start watching this issue

                Created:
                Updated: