jql
parameter is a full JQL
expression, and includes an ORDER BY
clause.
The fields
param (which can be specified multiple times) gives a comma-separated list of fields
to include in the response. This can be used to retrieve a subset of fields.
A particular field can be excluded by prefixing it with a minus.
By default, only navigable (*navigable
) fields are returned in this search resource. Note: the default is different
in the get-issue resource -- the default there all fields (*all
).
*all
- include all fields*navigable
- include just navigable fieldssummary,comment
- include just the summary and comments-description
- include navigable fields except the description (the default is *navigable
for search)*all,-comment
- include everything except comments
GET vs POST: If the JQL query is too large to be encoded as a query param you should instead POST to this resource.
Expanding Issues in the Search Result: It is possible to expand the issues returned by directly specifying the expansion on the expand parameter passed in to this resources.
For instance, to expand the "changelog" for all the issues on the search result, it is neccesary to specify "changelog" as one of the values to expand.
]]>In order to protect against XSRF attacks, because this method accepts multipart/form-data, it has XSRF protection on it. This means you must submit a header of X-Atlassian-Token: no-check with the request, otherwise it will be blocked.
The name of the multipart/form-data parameter that contains attachments must be "file"
A simple example to upload a file called "myfile.txt" to issue REST-123:
curl -D- -u admin:admin -X POST -H "X-Atlassian-Token: no-check" -F "file=@myfile.txt" http://myhost/rest/api/2/issue/TEST-123/attachments]]>
Values available for the assigneeType field are: "PROJECT_LEAD" and "UNASSIGNED".
]]>expand=projectKeys
.
]]>
Results can be ordered by the following fields:
curl \ -X POST \ -u admin:admin \ -H "X-Atlassian-Token: no-check" \ -H "Content-Type: image/png" \ --data-binary @mynewavatar.png \ 'http://localhost:8090/jira/rest/api/2/user/avatar/temporary?username=admin&filename=mynewavatar.png']]>
Set-Cookie
HTTP headers that must be honoured by the
caller. If you are using a cookie-aware HTTP client then it will handle all Set-Cookie
headers
automatically. This is important because setting the JSESSIONID
cookie alone may not be
sufficient for the authentication to work.]]>"my"
for returning
dashboards that are owned by the calling user.]]>maxResults
to determine the value that is
effectively being used.]]>NB: The above means that for issue-level permissions (EDIT_ISSUE for example), hasPermission may be true when no context is provided, or when a project context is provided, but may be false for any given (or all) issues. This would occur (for example) if Reporters were given the EDIT_ISSUE permission. This is because any user could be a reporter, except in the context of a concrete issue, where the reporter is known.
Global permissions will still be returned for all scopes.
Prior to version 6.4 this service returned project permissions with keys corresponding to com.atlassian.jira.security.Permissions.Permission constants. Since 6.4 those keys are considered deprecated and this service returns system project permission keys corresponding to constants defined in com.atlassian.jira.permission.ProjectPermissions. Permissions with legacy keys are still also returned for backwards compatibility, they are marked with an attribute deprecatedKey=true. The attribute is missing for project permissions with the current keys.
]]>issueType
field must correspond to a sub-task issue type (you can use
/issue/createmeta
to discover sub-task issue types), andparent
field in the issue create request containing the id or key of the
parent issue.expand=transitions.fields
.
The fields in the metadata correspond to the fields in the transition screen for that transition.
Fields not in the screen will not be in the metadata.]]>updateHistory
param adds the issues retrieved by this method to the current user's issue history,
if set to true (by default, the issue history does not include issues retrieved via the REST API).
You can view the issue history in the JIRA application, via the Issues dropdown or by using the
lastViewed
JQL field in an issue search.]]>
The fields
param (which can be specified multiple times) gives a comma-separated list of fields
to include in the response. This can be used to retrieve a subset of fields.
A particular field can be excluded by prefixing it with a minus.
By default, all (*all
) fields are returned in this get-issue resource. Note: the default is different
when doing a jql search -- the default there is just navigable fields (*navigable
).
*all
- include all fields*navigable
- include just navigable fieldssummary,comment
- include just the summary and comments-comment
- include everything except comments (the default is *all
for get-issue)*all,-comment
- include everything except commentsThe {@code properties} param is similar to {@code fields} and specifies a comma-separated list of issue properties to include. Unlike {@code fields}, properties are not included by default. To include them all send {@code ?properties=*all}. You can also include only specified properties or exclude some properties with a minus (-) sign.
issueIdOrKey
path parameter. This can be an issue id,
or an issue key. If the issue cannot be found via an exact match, JIRA will also look for the issue in a case-insensitive way, or
by looking to see if the issue was moved. In either of these cases, the request will proceed as normal (a 302 or other redirect
will not be returned). The issue key contained in the response will indicate the current value of issue's key.
The expand
param is used to include, hidden by default, parts of response. This can be used to include:
renderedFields
- field values in HTML formatnames
- display name of each fieldschema
- schema for each field which describes a type of the fieldtransitions
- all possible transitions for the given issueoperations
- all possibles operations which may be applied on issueeditmeta
- information about how each field may be edited. It contains field's schema as well.changelog
- history of all changes of the given issueversionedRepresentations
-
REST representations of all fields. Some field may contain more recent versions. RESET representations are numbered.
The greatest number always represents the most recent version. It is recommended that the most recent version is used.
version for these fields which provide a more recent REST representation.
After including versionedRepresentations
"fields" field become hidden.expand=projects.issuetypes.fields
.
The results can be filtered by project and/or issue type, given by the query params.]]>/rest/api/2/project/{projectIdOrKey}/role/{roleId}?user={username}
/rest/api/2/project/{projectIdOrKey}/role/{roleId}?group={groupname}
As is the case with {@link IssueTypeResource#deleteIssueType(String, String) issue type deletion}, certain changes to an issue type scheme require issue migrations on the part of affected projects. This resource does not support such migrations, and users are encouraged to use the GUI to perform them when necessary.
]]>expand=schemes.issueTypes
.
Similarly, the default issue type associated with the scheme (if one exists) will only be returned if
additional an query parameter is provided: expand=schemes.defaultIssueType
.
Note that both query parameters can be used together: expand=schemes.issueTypes,schemes.defaultIssueType
.
The number of groups returned is limited by the system property "jira.ajax.autocomplete.limit"
The groups will be unique and sorted.]]>
curl -c cookiejar.txt -X POST -u admin:admin -H "X-Atlassian-Token: no-check" \ -H "Content-Type: image/png" --data-binary @mynewavatar.png \ 'http://localhost:8090/jira/rest/api/2/issuetype/1/avatar/temporary?filename=mynewavatar.png' curl -b cookiejar.txt -X POST -u admin:admin -H "X-Atlassian-Token: no-check" \ -H "Content-Type: application/json" --data '{"cropperWidth": "65","cropperOffsetX": "10","cropperOffsetY": "16"}' \ -o tmpid.json \ http://localhost:8090/jira/rest/api/2/issuetype/1/avatar curl -b cookiejar.txt -X PUT -u admin:admin -H "X-Atlassian-Token: no-check" \ -H "Content-Type: application/json" --data-binary @tmpid.json \ http://localhost:8090/jira/rest/api/2/issuetype/1/avatar]]>
You *must* use "avatar" as the name of the upload parameter:
curl -c cookiejar.txt -X POST -u admin:admin -H "X-Atlassian-Token: no-check" \ -F "avatar=@mynewavatar.png;type=image/png" \ 'http://localhost:8090/jira/rest/api/2/issuetype/1/avatar/temporary']]>
nodeId
- Node identifier.reportTime
- Time of this report creation.issueIndex
- Summary of issue index status.replicationQueues
- Map of index replication queues, where
keys represent nodes from which replication operations came from.issueIndex
can contain:
indexReadable
- If false
the end point failed to read data from issue index
(check JIRA logs for detailed stack trace), otherwise true
.
When false
other fields of issueIndex
can be not visible.countInDatabase
- Count of issues found in database.countInIndex
- Count of issues found while querying index.lastUpdatedInDatabase
- Time of last update of issue found in database.lastUpdatedInIndex
- Time of last update of issue found while querying index.replicationQueues
's map values can contain:
lastConsumedOperation
- Last executed index replication operation by current node from sending node's queue.lastConsumedOperation.id
- Identifier of the operation.lastConsumedOperation.replicationTime
- Time when the operation was sent to other nodes.lastOperationInQueue
- Last index replication operation in sending node's queue.lastOperationInQueue.id
- Identifier of the operation.lastOperationInQueue.replicationTime
- Time when the operation was sent to other nodes.queueSize
- Number of operations in queue from sending node to current node.curl -c cookiejar.txt -X POST -u admin:admin -H "X-Atlassian-Token: no-check" \ -H "Content-Type: image/png" --data-binary @mynewavatar.png \ 'http://localhost:8090/jira/rest/api/2/user/avatar/temporary?username=admin&filename=mynewavatar.png' curl -b cookiejar.txt -X POST -u admin:admin -H "X-Atlassian-Token: no-check" \ -H "Content-Type: application/json" --data '{"cropperWidth": "65","cropperOffsetX": "10","cropperOffsetY": "16"}' \ -o tmpid.json \ http://localhost:8090/jira/rest/api/2/user/avatar?username=admin curl -b cookiejar.txt -X PUT -u admin:admin -H "X-Atlassian-Token: no-check" \ -H "Content-Type: application/json" --data-binary @tmpid.json \ http://localhost:8090/jira/rest/api/2/user/avatar?username=admin]]>
You *must* use "avatar" as the name of the upload parameter:
curl -c cookiejar.txt -X POST -u admin:admin -H "X-Atlassian-Token: no-check" \ -F "avatar=@mynewavatar.png;type=image/png" \ 'http://localhost:8090/jira/rest/api/2/user/avatar/temporary?username=admin']]>
Types can be extended by plugins, but here is a list of all built-in types (expected parameter contents are given in parenthesis):
There are also two "hidden" holder types, which are not available in on-demand but can be used in enterprise instances:
In addition to specifying the permission holder, a permission must be selected. That way a pair of (holder, permission) is created and it represents a single permission grant.
Custom permissions can be added by plugins, but below we present a set of built-in JIRA permissions.
To update just the name and description, do not send permissions list at all.
To add or remove a single permission grant instead of updating the whole list at once use the {schemeId}/permission/ resource.
]]>