You must only install apps that call the Teamwork Graph API in test organizations. Apps calling the Teamwork Graph API require the read:graph:jiraor read:graph:confluence scope, which provides access to Teamwork Graph data across your entire organization. While apps still respect end-user permissions, this scope may grant access to sensitive information. For safety, only install these apps in organizations with test data. Do not install apps using this API in organizations with production data while this feature is in EAP.

Additionally, this EAP has significant limitations. To review the full list of limitations, see Limitations and considerations.

You must be part of this EAP in order to use the Teamwork Graph API. Express interest in joining through this form.

The `AtlassianUserAssignedJiraWorkItem` relationship represents the link between an Atlassian User and a Jira Work Item within the Teamwork Graph. It allows you to:
* View all Jira Work Items currently assigned to a specific user
* Identify who is responsible for resolving a particular Jira Work Item
* Traverse and analyze user-issue relationships

Relationship type: Canonical

From object types	To object types
Atlassian User - `ati:cloud:identity:user`	Jira Work Item - `ati:cloud:jira:issue`

Cypher

Note

We recommend sending parameterized Cypher queries as below instead of embedding the parameters directly in the query string. This approach will help ensure better performance.

Forward query

Inverse query

GraphQL

1
2
query AtlassianUserAssignedJiraWorkItem_CypherQuery($cypherQuery: String!, $params: CypherRequestParams) {
  cypherQuery(query: $cypherQuery, params: $params) {
    edges {
      node {
        columns {
          value {
            ... on CypherQueryResultNode {
              id
              data {
                __typename
                ... on JiraWorkItem {
                  id
                }
              }
            }
          }
        }
      }
    }
  }
}

Params

1
2
{
  "cypherQuery": "MATCH (user:AtlassianUser {ari: $id})-[:atlassian_user_assigned_jira_work_item]->(item:JiraWorkItem) RETURN item",
  "params": {
    "id": "$id"
  }
}

Metadata

Relationship Metadata

Name	Type	Properties
`creatorAri`	Ari (`Message`)
`statusCategory`	StatusCategory (`Enum`)
`issueType`	IssueType (`Message`)
`dueDate`	`Long`
`projectType`	ProjectType (`Enum`)
`actorAri`	Ari (`Message`)

Nested Types

Ari

When filtering by ARI in GraphQL, it will behave as a String rather than a message as shown below.

Name	Type	Properties
`value`	`String`

IssueType

Name	Type	Properties
`hierarchyLevel`	HierarchyLevel (`Enum`)
`issueTypeName`	IssueTypeName (`Enum`)

StatusCategory

Name	Internal Name	Index
`not-set`	`STATUS_NOT_SET`	`0`
`undefined`	`STATUS_UNDEFINED`	`1`
`new`	`STATUS_NEW`	`2`
`done`	`STATUS_DONE`	`3`
`indeterminate`	`STATUS_INDETERMINATE`	`4`

ProjectType

Name	Internal Name	Index
`not-set`	`TYPE_PROJECT_TYPE_NOT_SET`	`0`
`service_desk`	`TYPE_PROJECT_TYPE_SERVICE_DESK`	`1`
`business`	`TYPE_PROJECT_TYPE_BUSINESS`	`2`
`software`	`TYPE_PROJECT_TYPE_SOFTWARE`	`3`
`product_discovery`	`TYPE_PROJECT_TYPE_PRODUCT_DISCOVERY`	`4`
`customer_service`	`TYPE_PROJECT_TYPE_CUSTOMER_SERVICE`	`5`
`ops`	`TYPE_PROJECT_TYPE_OPS`	`6`

HierarchyLevel

Name	Internal Name	Index
`undefined`	`TYPE_HIERARCHY_LEVEL_NOT_SET`	`0`
`subtask`	`TYPE_HIERARCHY_LEVEL_SUBTASK`	`1`
`standard`	`TYPE_HIERARCHY_LEVEL_STANDARD`	`2`
`epic`	`TYPE_HIERARCHY_LEVEL_EPIC`	`3`
`initiative`	`TYPE_HIERARCHY_LEVEL_INITIATIVE`	`4`

IssueTypeName

Name	Internal Name	Index
`not-set`	`TYPE_UNKNOWN`	`0`
`Alerts`	`TYPE_ALERTS`	`2`
`Bug`	`TYPE_BUG`	`4`
`Epic`	`TYPE_EPIC`	`10`
`Task`	`TYPE_TASK`	`20`
`Story`	`TYPE_STORY`	`30`
`Sub-task`	`TYPE_SUBTASK`	`40`
`Sub-Task`	`TYPE_SUBTASK_1`	`50`
`Subtask`	`TYPE_SUBTASK_2`	`60`
`SUBTASK`	`TYPE_SUBTASK_3`	`70`