expand=projectKeys.
]]>
Values available for the assigneeType field are: "PROJECT_LEAD" and "UNASSIGNED".
]]>Results can be ordered by the following fields:
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']]>
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']]>
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.]]>/rest/api/2/project/{projectIdOrKey}/role/{roleId}?user={username}/rest/api/2/project/{projectIdOrKey}/role/{roleId}?group={groupname}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.
]]>The number of groups returned is limited by the system property "jira.ajax.autocomplete.limit"
The groups will be unique and sorted.]]>
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.
]]>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.]]>
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.]]>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.
]]>"my" for returning
dashboards that are owned by the calling user.]]>maxResults to determine the value that is
effectively being used.]]>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]]>