Keypup automatically enriches your data by capturing attributes from the Parent Issue associated with your Issues and Pull Requests.
This allows you to access context from higher-level hierarchy items (such as Epics or Parent tickets) directly on the child items. Keypup captures standard attributes (e.g., Title, State, Story Points) as well as Custom Fields from the parent issue.
A typical use case is filtering a list of GitHub Pull Requests based on the "Priority" or "Strategic Theme" custom field defined on their parent Jira Issue.
How is the Parent Issue calculated?
Keypup determines the Parent Issue differently depending on whether the record is an Issue or a Pull Request.
> For Issues
For issues, the determination is based on the native hierarchy links provided by the data source.
Jira: Keypup uses the "Parent" link or "Epic" link to identify the parent issue.
GitHub Issues: Keypup uses the parent issue set through GitHub sub-issues.
Azure DevOps: Keypup uses the work item's Parent link.
ClickUp: Keypup uses the parent task of a subtask.
> For Pull Requests
Pull Requests do not strictly have "parents" in the same way issues do. Keypup calculates the Parent Issue based on the First Resolved Issue.
Only the issues the pull request resolves count, as defined in Definition: Resolving Pull Request. A closed, unmerged pull request resolves no issue, so it has no Parent Issue.
While a Pull Request can resolve multiple issues using auto-closing keywords (e.g., "fixes #123"), the Parent Issue attributes are populated using only one specific issue.
To determine which resolved issue acts as the "Parent", Keypup looks at manually linked issues first, then scans for auto-closing keywords in a specific order of precedence. This determines the general ranking of resolved issues. The first issue found determines the Parent Issue.
Order of precedence:
Manually linked issues (GitHub): Issues linked by hand to the pull request in GitHub, from the Development section of the pull request, come first, in the order GitHub lists them.
Manually linked work items (Azure DevOps): Then come the work items that link to the pull request by hand, from the Development section of the work item.
Branch Name: We look for issue keys in the branch name (reading from left to right).
PR Title: Then we look in the PR title (reading from left to right).
PR Body: Then we look in the PR description/body (reading from left to right).
Commits: Finally, we scan the commit messages associated with the PR, ordered chronologically (older to newer) and from left to right.
Example:
If a Pull Request has the title Fixing bug [PROJ-123] and the body contains Also resolves [PROJ-456]:
PROJ-123 will be designated as the Parent Issue because the Title takes precedence over the Body.
The PR will still be linked to both issues in the
Resolved Issues > IDs (System)list, but fields likeParent Issue > TitleorParent Issue > Story pointswill be pulled solely from PROJ-123.
Available Attributes and Custom Fields
Once the Parent Issue is calculated, Keypup exposes its data on the child record. This includes:
Standard Fields:
Parent Issue > Title,Parent Issue > State,Parent Issue > Sub-Type,Parent Issue > Story points,Parent Issue > Due on, etc.Custom Fields: Any custom field available on the parent issue in the source system (e.g., Jira Custom Fields) is mapped and available for filtering.
Example Use Case
You want to see a list of all open GitHub Pull Requests that are working towards a "Critical" release.
In Jira, your Issues have a custom field called "Release Urgency".
In Keypup, you create a report for Pull Requests.
You add a filter:
Parent Issue CF > Release UrgencyequalsCritical.
Keypup will automatically filter the PRs by looking at the linked Jira Issue (the parent), checking that issue's custom field value, and returning the matching PRs.