Dataset: Issues & Pull Requests
Entity: Pull Requests
Field ID: resolved_issue_sysids
Type: List of text values
Description: The list of issue System IDs (Keypup IDs) that the pull request resolves via auto-closing keywords.
It can be used to:
Count the number of resolved issues on each pull request.
See a list of resolving Pull Requests from a specific issue by configuring a drilldown report on the resulting values (select all resolving Pull Requests where resolved issue ids contain the selected issue id).
Source: Calculated
Transformation logic:
Pull Requests: The list of system IDs (Keypup-generated IDs) from resolved issues. Resolved issues are issues that are referenced by a resolving pull request.
Issues: This field will always be an empty array
[]
From: |
|
Github (PRs, Issues) | Calculated |
Gitlab (PRs, Issues) | Calculated |
Bitbucket (PRs) | Calculated |
Azure DevOps (PRs, Issues) | Calculated |
JIRA (Issues) | N/A |
ClickUp (Issues) | N/A |
Trello (Issues) | N/A |
Reporting Use Cases
The Resolved Issue IDs (System) field is the technical linchpin that connects a pull request to the issue(s) it resolves, making it one of the most important fields for analyzing process compliance and the scope of your development work.
Identifying Planned vs. Unplanned Work: This is the field's primary function. It allows you to distinguish between pull requests that are linked to a planned piece of work (an issue) and those that are not.
Filtering: You can easily create a report of all "unplanned" or "orphan" pull requests by using a filter where
Resolved Issue IDs (System) length = 0. Conversely, filtering whereResolved Issue IDs (System) length > 0will show all "planned" work.Categorization: The most powerful use is to create a "Planned vs. Unplanned" ratio. A custom formula dimension like
IF(LENGTH(resolved_issue_sysids) > 0, "Planned", "Unplanned")can be used in a pie chart with aCOUNT()metric to visualize the proportion of your development effort that is formally tracked.
Measuring the Scope of Pull Requests: The number of issues a single pull request resolves is a strong indicator of its scope and complexity.
You can analyze this by creating a metric that calculates the average number of issues resolved per PR:
AVG(LENGTH(resolved_issue_sysids)). A high average might indicate that pull requests are bundling too many distinct tasks, which could make them harder to review and test.