Syncing Restricted Issues on a Team Managed Board

General Questions
, , ,
1

Originally asked by Quincy Els on 07 February 2023 (original question)

We’re using Jira Cloud and have a team managed project with a restricted issue type.

For a company managed board, I would usually add the atlassian-addons-project-access project role to a permission schema for that type of issue and apply it to the project. However, team managed projects can’t edit permission schemas directly, they need to apply the permissions to the project itself. This doesn’t work because the Exalate user is automatically generated and can’t be added to roles or groups.

I was wondering if there is a workaround or if syncing restricted issues only works on company managed boards?

Comments:

Serhiy Onyshchenko commented on 08 February 2023

Hello, Quincy Els , instead on relying on Exalate’s authentication to create the issue you could use the GroovyHttpClient (at the end of your incoming sync script):

def issueCreationResult = new GroovyHttpClient(httpClient)
    .http(
            "POST",
            "https://... .atlassian.net/rest/api/2/issue",
            """{
  "fields": {
    "assignee": {
      "id": "5b109f2e9729b51b54dc274d"
    },
    "components": [
      {
        "id": "10000"
      }
    ],
    "customfield_10000": "09/Jun/19",
    "customfield_20000": "06/Jul/19 3:25 PM",
    "customfield_30000": [
      "10000",
      "10002"
    ],
    "customfield_40000": "Occurs on all orders",
    "customfield_50000": "Could impact day-to-day work.",
    "customfield_60000": "jira-software-users",
    "customfield_70000": [
      "jira-administrators",
      "jira-software-users"
    ],
    "customfield_80000": {
      "value": "red"
    },
    "description": "Order entry fails when selecting supplier.",
    "duedate": "2019-03-11",
    "environment": "UAT",
    "fixVersions": [
      {
        "id": "10001"
      }
    ],
    "issuetype": {
      "id": "10000"
    },
    "labels": [
      "bugfix",
      "blitz_test"
    ],
    "parent": {
      "key": "PROJ-123"
    },
    "priority": {
      "id": "20000"
    },
    "project": {
      "id": "10000"
    },
    "reporter": {
      "id": "5b10a2844c20165700ede21g"
    },
    "security": {
      "id": "10000"
    },
    "summary": "Main order flow broken",
    "timetracking": {
      "originalEstimate": "10",
      "remainingEstimate": "5"
    },
    "versions": [
      {
        "id": "10000"
      }
    ]
  },
  "update": {
    "worklog": [
      {
        "add": {
          "started": "2019-07-05T11:05:00.000+0000",
          "timeSpent": "60m"
        }
      }
    ]
  }
}""",
            ["Accept": ["application/json"], "Content-type" : ["application/json"], "Authorization":["Basic <>"] ]
    ) 
    { 
        response ->
        if (response.code >= 400)
            throw new com.exalate.api.exception.IssueTrackerException("Failed")
        else
            (new groovy.json.JsonSlurper()).parseText(response.body)
    }def issueKey = new com.exalate.basic.domain.BasicIssueKey(issueCreationResult.id, issueCreationResult.key)return new scala.Tuple2(issueKey, scala.collection.JavaConverters.asScalaBuffer(traces))
Quincy Els commented on 08 February 2023

Serhiy Onyshchenko Thanks, this is really good to know! I’m not sure it would entirely solve my issue though?

The issue is already created, the problem is that Exalate doesn’t have permission to view the issue to maintain an outgoing sync. To your point, I’ll probably need to do this if I want to manage incoming tickets of this restricted type, but I’m still not sure how Exalate would view the protected issues for the outgoing connection?

Quincy Els commented on 14 February 2023

While I’m still looking for a solution, it looks like we may need to move to a company managed board. It would be nice if the Exalate user was configurable in some way so we can allow it to to view restricted issue types on team managed boards.