jira: use standard parent field and document hierarchy level constraints - #606
Conversation
openshift-ci
Bot
added
the
approved
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (7)
✅ Files skipped from review due to trivial changes (4)
🚧 Files skipped from review as they are similar to previous changes (2)
WalkthroughThis PR bumps Jira plugin version metadata to 0.8.3 and updates Jira create/reference documentation to use structured ChangesJira metadata and documentation updates
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 10✅ Passed checks (10 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
5cf498e to
5be8944
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@plugins/jira/.claude-plugin/plugin.json`:
- Around line 2-4: The plugin manifest is missing the required author metadata,
so update the jira plugin’s plugin.json to include an author field alongside
name, description, and version. Use the existing manifest structure in
plugin.json and add author as a JSON object with a name key, matching the
contract expected for plugins/*/.claude-plugin/plugin.json.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 390b8271-2ca8-4fe3-ba0a-f1eddb9943f5
📒 Files selected for processing (7)
.claude-plugin/marketplace.jsondocs/index.htmlplugins/jira/.claude-plugin/plugin.jsonplugins/jira/reference/cntrlplane.mdplugins/jira/reference/create-epic.mdplugins/jira/reference/gcp-hcp.mdplugins/jira/skills/create/SKILL.md
5be8944 to
1ec5073
Compare
cblecker
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
plugins/jira/skills/create/SKILL.md (1)
175-181: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winUse Jira component objects here
componentsshould be an array of objects, not bare strings; e.g.[{ "id": "..." }]or[{ "name": "Name" }]depending on the Jira instance.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@plugins/jira/skills/create/SKILL.md` around lines 175 - 181, The SKILL.md field format example for components is incorrect because it shows bare string values instead of Jira component objects. Update the Component row in the field format errors section to use an array of component objects in the create payload, and reference the surrounding examples in the create skill docs so it clearly shows the expected shapes such as id or name objects rather than plain strings.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@plugins/jira/skills/create/SKILL.md`:
- Around line 138-155: The hierarchy-change flow in the SKILL.md guidance is
currently a partial-update sequence that can leave an issue mid-transition if
`editJiraIssue` fails after unsetting the parent or changing the type. Update
the instructions around the “Changing Issue Type Across Hierarchy Levels”
section to require guarded execution in `editJiraIssue` and to explicitly define
recovery: either restore the original parent/type on failure or clearly surface
that the issue is in a partial state before proceeding. Ensure the guidance
references the separate `parent` and `issuetype` edits so implementers can
locate the sequence easily.
---
Outside diff comments:
In `@plugins/jira/skills/create/SKILL.md`:
- Around line 175-181: The SKILL.md field format example for components is
incorrect because it shows bare string values instead of Jira component objects.
Update the Component row in the field format errors section to use an array of
component objects in the create payload, and reference the surrounding examples
in the create skill docs so it clearly shows the expected shapes such as id or
name objects rather than plain strings.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 2a659a2d-3b2c-47e6-abc5-41b4152ac63d
📒 Files selected for processing (7)
.claude-plugin/marketplace.jsondocs/index.htmlplugins/jira/.claude-plugin/plugin.jsonplugins/jira/reference/cntrlplane.mdplugins/jira/reference/create-epic.mdplugins/jira/reference/gcp-hcp.mdplugins/jira/skills/create/SKILL.md
✅ Files skipped from review due to trivial changes (6)
- .claude-plugin/marketplace.json
- docs/index.html
- plugins/jira/.claude-plugin/plugin.json
- plugins/jira/reference/create-epic.md
- plugins/jira/reference/gcp-hcp.md
- plugins/jira/reference/cntrlplane.md
|
Overall: Solid simplification. Replacing instance-specific custom field IDs with the standard 1. Consider retaining a duplicate guard in the fallback The new fallback ( Jira Cloud typically returns validation errors before writing, so partial success is unlikely in practice. That said, network timeouts can still leave a server-side record with no client-side confirmation. You might consider adding a brief note like: "Before retrying, search for an existing issue with the same summary to avoid creating a duplicate." Low priority, but the guard existed for a reason. 2. Consider defining what counts as a "parent-related error" The fallback trigger is "if creation fails with a parent-related error," but doesn't specify what that looks like in the API response. The old error table listed concrete message strings ( 3. Confirm GCP Epic test was run, not just planned The test plan includes 4. Minor: The updated |
|
Thanks for the thorough review! Addressing each point: 1. Duplicate guard: Declining — the old guard triggered on 4xx validation errors, which are synchronous rejections before issue creation. Jira's single-issue create is all-or-nothing at validation time, so the partial-success scenario doesn't apply to this error class. The network-timeout risk is real broadly, but it applies to any POST call and would be better addressed as generic retry guidance rather than a parent-linking-specific guard. The guard's trigger condition (custom field errors for 2. Parent-related error definition: Declining — the old concrete error strings ( 3. GCP Epic test: Confirmed — we ran these tests and verified the standard 4. create-epic.md cross-reference: Declining — |
The standard Jira parent field works for all hierarchy levels (Story→Epic, Epic→Feature) and is simpler than setting custom field IDs directly. Remove customfield_10014/customfield_10018 references and the fallback complexity that existed only because of custom field fragility. Document the Jira hierarchyLevel system (Outcome=3, Feature=2, Epic=1, Story/Task/Bug=0, Sub-task=-1) and the constraint that parents must be exactly one level higher. Fix the pre-validation table: Task's parent is Epic only (not Story, which is the same level), and add missing rows for Bug and Feature. Add guidance for changing issue types across hierarchy levels — the parent must be unset before changing the type, then re-set afterward, because Jira validates the one-level-higher constraint on every edit. Assisted-by: Claude:claude-opus-4-6
1ec5073 to
2bcf3d9
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cblecker, katherinekeane The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
2 participants
Summary
customfield_10014(Epic Link) andcustomfield_10018(Parent Link) with the standard Jiraparentfield for all parent-child relationships (Story→Epic, Task→Epic, Bug→Epic, Epic→Feature, Feature→Outcome)hierarchyLevelsystem (Outcome=3, Feature=2, Epic=1, Story/Task/Bug=0, Sub-task=-1) and the constraint that parents must be exactly one level higherWhy: Empirical testing on redhat.atlassian.net confirmed that
{"parent": {"key": "PARENT-KEY"}}works for all hierarchy levels. Theparentfield is simpler, more portable, and eliminates the need to know instance-specific custom field IDs. The hierarchy level documentation prevents silent failures when setting invalid parent-child relationships.Test plan
/jira:create story GCP "Test parent linking" --parent GCP-248and verify the Story is linked to the Epic/jira:create epic GCP "Test epic parent" --parent GCP-100and verify the Epic is linked to the Featuremake lintpassesSummary by CodeRabbit
additional_fieldsand clarified hierarchy-level constraints.