...
--extended may show extra columns which are normal hidden. Since there may be a lot of information to fit the width of the screen by default some commands may not show all the columns by default. For example nearly all tables includes a ‘self’ column which contains URL of the entity. This is very long and occupies a lot fo space on the screen and may cause lots of columns to be truncated. For this reason ‘self’ column and some other columns are hidden by default. You can specify --extended flag to show these columns.
Here is our general recommendations on when to use which output format:
table: This is the default format and suitable for human eyes especially if all the columns of output fits to width of the terminal and there are multiple rows of data. For example when getting list of users.
Code Block | ||
---|---|---|
| ||
jira project:get-all
Id Key Name Project Type Key Archived
10001 ACN Accurate Notebook software false
10005 ADS Adaptable Summer software false
10008 AUC Auxiliary Card software false
10006 CLG Clean Guardian software false
10004 COI Compressing Interface software false |
yaml: Prefer this format when there are a lot of columns and it is difficult to fit all columns on the screen. Especially when displaying a single row of information.
Code Block | ||
---|---|---|
| ||
jira server-info:get --output=yaml
baseUrl: 'http://localhost:8080'
version: 8.14.0
versionNumbers:
- 8
- 14
- 0
deploymentType: Server
buildNumber: 814001
buildDate: '2020-11-23T00:00:00.000+0300'
databaseBuildNumber: 814001
serverTime: '2021-01-06T12:36:45.790+0300'
scmInfo: ab08d3d2b500818bdad5c85d636b509d4cade801
serverTitle: Jira Server |
json: Prefer this format when writing integrations and scripts. It is suitable for hierarchical data too.
Code Block | ||
---|---|---|
| ||
jira issue:get ERP-53 --output=json
{
"expand": "renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations",
"id": "12705",
"self": "http://localhost:8080/rest/api/2/issue/12705",
"key": "ERP-53",
"fields": {
"issuetype": {
"self": "http://localhost:8080/rest/api/2/issuetype/10000",
"id": "10000",
"description": "Created by Jira Software - do not edit or delete. Issue type for a big user story that needs to be broken down.",
"iconUrl": "http://localhost:8080/images/icons/issuetypes/epic.svg",
"name": "Epic",
"subtask": false
},
"timespent": 21600,
"project": {
"self": "http://localhost:8080/rest/api/2/project/10000",
"id": "10000",
"key": "ERP",
"name": "Enterprise Resource Planning",
"projectTypeKey": "software",
"avatarUrls": {
"48x48": "http://localhost:8080/secure/projectavatar?pid=10000&avatarId=10203",
"24x24": "http://localhost:8080/secure/projectavatar?size=small&pid=10000&avatarId=10203",
"16x16": "http://localhost:8080/secure/projectavatar?size=xsmall&pid=10000&avatarId=10203",
"32x32": "http://localhost:8080/secure/projectavatar?size=medium&pid=10000&avatarId=10203"
}
},
"fixVersions": [],
......
} |
Issue ID or Key
Most commands that expects an issue can either accepts an issue ID or key. In that case this flag is usually ‘issue’ and you can use either ‘--issue=10000’ or ‘--issue=TEST-1’ to specify issue. If a command explicitly needs issue ID the flag will be ‘issueId’ and if a command explicitly needs issue key, the flag will be ‘issueKey’.
...