Problem
atl issue view <key> --json does not include the issuelinks field from the Jira REST API. This forces users to fall back to raw REST calls (with manual OAuth token extraction from ~/.config/atlassian/tokens/) whenever they need to inspect or filter by linked issues.
Real use case
I needed to answer: "Which SD issues have at least one linked NX issue, where all NX links are resolved?"
JQL cannot express this without ScriptRunner (linkedIssues() only takes a single hardcoded key — it has no universal quantification over a link set). The pragmatic fallback is:
- Page through
project = NX issues
- Inspect each NX's
issuelinks to find SD references + the NX's resolution
- Aggregate per-SD and filter client-side
Step 2 is impossible with atl today because issuelinks is stripped from the JSON output. I had to read the OAuth token directly from the config directory and curl the REST API — which works but bypasses the whole point of the CLI.
Proposed behavior
atl issue view <key> --json should include the raw issuelinks array from the Jira API, e.g.:
{
"key": "SD-25045",
"issuelinks": [
{
"type": { "name": "Caused", "inward": "is caused by", "outward": "causes" },
"inwardIssue": {
"key": "NX-15514",
"fields": {
"status": { "name": "Erledigt", "statusCategory": { "key": "done" } },
"resolution": { "name": "Done" },
"summary": "…"
}
}
}
]
}
Minimum useful fields per linked issue: key, status.name, status.statusCategory.key, resolution.name, summary, issuetype.name.
Nice-to-have: batch access
For bulk workflows (4k+ issues in my case), a batch command would avoid the N-request loop:
atl issue list --jql "…" --json --include-links — embed issuelinks in list output
- or
atl issue links <key> — dedicated subcommand
Today the textual view also omits linked issues, so adding them to both --json and default output would be consistent.
Context
- Atlassian endpoint:
GET /rest/api/3/issue/{key}?fields=issuelinks already returns this
- Bulk via
POST /rest/api/3/search/jql with "fields": ["issuelinks"]
- No extra scope needed beyond
read:issue-details:jira which atl already requests
Problem
atl issue view <key> --jsondoes not include theissuelinksfield from the Jira REST API. This forces users to fall back to raw REST calls (with manual OAuth token extraction from~/.config/atlassian/tokens/) whenever they need to inspect or filter by linked issues.Real use case
I needed to answer: "Which SD issues have at least one linked NX issue, where all NX links are resolved?"
JQL cannot express this without ScriptRunner (
linkedIssues()only takes a single hardcoded key — it has no universal quantification over a link set). The pragmatic fallback is:project = NXissuesissuelinksto find SD references + the NX'sresolutionStep 2 is impossible with
atltoday becauseissuelinksis stripped from the JSON output. I had to read the OAuth token directly from the config directory andcurlthe REST API — which works but bypasses the whole point of the CLI.Proposed behavior
atl issue view <key> --jsonshould include the rawissuelinksarray from the Jira API, e.g.:{ "key": "SD-25045", "issuelinks": [ { "type": { "name": "Caused", "inward": "is caused by", "outward": "causes" }, "inwardIssue": { "key": "NX-15514", "fields": { "status": { "name": "Erledigt", "statusCategory": { "key": "done" } }, "resolution": { "name": "Done" }, "summary": "…" } } } ] }Minimum useful fields per linked issue:
key,status.name,status.statusCategory.key,resolution.name,summary,issuetype.name.Nice-to-have: batch access
For bulk workflows (4k+ issues in my case), a batch command would avoid the N-request loop:
atl issue list --jql "…" --json --include-links— embed issuelinks in list outputatl issue links <key>— dedicated subcommandToday the textual view also omits linked issues, so adding them to both
--jsonand default output would be consistent.Context
GET /rest/api/3/issue/{key}?fields=issuelinksalready returns thisPOST /rest/api/3/search/jqlwith"fields": ["issuelinks"]read:issue-details:jirawhichatlalready requests