<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ### Release note The authorisation of the Jira Issue integration is now based on the specific user browsing the integration, and not on credentials specified upon integration setup. Users are able to view only those Jira issues within GitLab via Jira Issue integration, that they can view in Jira according to their permissions. ## Problem to solve When viewing issues via the `Jira Issue List` feature (Jira Issue Integration), you can only see only basic (name/id/url/labels) information, and no further details. This was decided upon as a middle-ground, for security reasons. Many users/organizations use admin-level credentials for configuring this integration and as such, this may allow users without appropriate access to view the details of an issue they would not otherwise have access to. While this integration currently allows them to view a _list_ of issues that they potentially don't have access to, it was viewed as a reasonable middle-ground to not also allow them to get details. In %"13.4", gitlab~10046105 added support for [federating your Atlassian account with your GitLab profile](https://gitlab.com/gitlab-org/gitlab/-/issues/220991). We should work towards allowing our Jira integration to leverage these credentials for the Jira Issue List feature. ## Proposed solution From GitLab user should authorise with Atlassian as OAuth provider and the access token should be stored and used by GitLab to access the Jira resources in the integration. What Jira resources a user can see within GitLab should depend on their Jira permissions. For the first configuration of Jira Issue Integration user should also be able to use OAuth as oppose to basic authentication. The authorisation of the Jira Issue integration would be based on the specific user browsing the integration, and not on credentials specified upon setup of the integration. ## Implementation plan See more details [here](https://gitlab.com/groups/gitlab-org/-/epics/4954#note_1870162461) Issue 1 - Weight 2 (Refresh OAuth tokens) Issue 2 - Weight 1 or 2 (Fetch `could_id` from Atlassian, depending on how we decide to implement it) Issue 3 - Weight 2 (Code to construct new client from user's OAuth token) Issue 4 - Weight 2 or 3 (Update all the places where the Jira client is being called. This is a little bit tricky to estimate as it depends on the above issues.) Issue 5 - Weight 1 - fix an issue with the project_keys configuration in the integration settings. If the administrator sets the project_keys to include projects like TEST1 and TEST2, and a user lacking access to TEST2 attempts to list Jira issues, it will lead to an error. We should pass a param so that Jira api doesn't raise an error. Use the [validateQuery](https://developer.atlassian.com/cloud/jira/platform/rest/v2/api-group-issue-search/#api-rest-api-2-search-get) parameter. Additionally, we may need another 2 for tasks that might have been missed, such as updating the error messages we display to the user.