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 identifies the parent based on Task lists or Parent/Child relationships defined within the issue.
> For Pull Requests
Pull Requests do not strictly have "parents" in the same way issues do. Keypup infers the Parent Issue based on the First Resolved 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 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:
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 resolving_issue_ids list, but attributes like parent_issue_title or parent_issue_story_points will 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_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.