rest api - how to set sharePermissions for a project?

[ben friedman]

Hi,

my JSON game isnt strong, and i didnt fully undersdtand the documentation. 

Im createing a filter via API call with the below body:

{
"jql": "project ={{issue.project.key}} and type = Bug and resolution is empty",
"name": "All Open Bug2s",
"description": "Lists all open bugs",
"sharePermissions":["type":"project","project": {"id": "{{webhookResponse.body.id}}"}]
}

with out the 'sharePermissions' all is good.  how should i build it so the request passes?

[Darryl Lee · Accepted solution]

The way I'm reading the API is that you can't set share permissions when you create a filter. I think you have to do it in a separate operation.

Docs for Create filter say this:

Creates a filter. The filter is shared according to the default share scope. The filter is not selected as a favorite.

So I would try to Add share permission: 

curl --request POST \
 --url 'https://your-domain.atlassian.com/rest/api/3/filter/{id}/permission' \
 --user 'email@example.com:<api_token>' \ 
--header 'Accept: application/json' \
 --header 'Content-Type: application/json' \ 
--data '{ "type": "group", "groupname": "jira-administrators" }'

Also, are you making two web requests in the same rule?

"sharePermissions":["type":"project","project": {"id": "{{webhookResponse.body.id}}"}]

Oh, probably because there's no Smart Value for Project ID. Ugh, what a hassle.

[Andrey Tetyuev]

My few cents...

Target URL:

https://YOUR_SERVER/rest/api/2/filter/YOUR_FILTER_ID/permission

Note 1: you can change the "edit" (and probably "view") value according to your needs. You should also need access rights to the filter to be able apply the changes (e.g. it should be your filter, or it should be editable for you).

Note 2: currently you can't apply several share permissions at ones (also can't apply it directly with creating filter - at least in the server JIRA version). So you should do it after the filter is already existing, adding permission one by one. If you have generic permissions (see below) - you should apply them first because they would remove existing ones.


Examples of JSON data to be send by POST request to add/edit the filter permissions).

// For sharing filter with user:

{"type":"user","userKey":"YOUR_USER_LOGIN_ID_OR_JIRA_USER_KEY","view":true,"edit":true}

// For sharing filter with project:

{"type":"project","projectId":"YOUR_PROJECT_ID","view":true,"edit":true}

// For sharing filter with users-group:

{"type":"group","groupname":"YOUR_GROUP_NAME_AS_SHOWN_IN_JIRA","view":true,"edit":false}

 
There are also few others "generic" permissions types, but if applied - they would remove existing ones by the filter (so need apply them before others and only if needed):

// For sharing filter with all web-users (usually it can't allow editing rights):

{"type":"global","view":true,"edit":false}

// For sharing filter with all logged-in JIRA users (usually it can't allow editing rights):

{"type":"authenticated","view":true,"edit":false}

Example of curl request:

curl.exe -H "Authorization: Bearer %ENVIRONMENT_VARIABLE%" -o "YOUR_PATH\tmp_output.txt" --request POST -H "Content-Type: application/json; charset=utf-8; accept-charset=utf-8" --header "Accept: application/json" --trace-ascii "YOUR_PATH\tmp_trace.txt" -d @YOUR_PATH\permission_data.json --url "https://YOUR_SERVER/rest/api/2/filter/YOUR_FILTER_ID/permission"

where:
ENVIRONMENT_VARIABLE -> name of environment variable containing PAT value to access to JIRA
YOUR_PATH -> a path to your local folder
permission_data.json -> a name of file containing json data with single permission as described in examples above (the file is located within folder at YOUR_PATH)
YOUR_SERVER -> your server url
YOUR_FILTER_ID -> ID of the filter you are applying share permission to.

Hope it helps to someone.