Jira REST API Filter AddSharePermission broken?

[Deleted user]

I pass the exact data that is provided in the example: https://docs.atlassian.com/software/jira/docs/api/REST/7.12.1/#api/2/filter-addSharePermission

I get an error that appears to say is does not want to work with an array:

"Can not deserialize instance of com.atlassian.jira.rest.v2.search.SharePermissionInputBean out of START_ARRAY token\n at [Source: org.apache.catalina.connector.CoyoteInputStream@4af39074; line: 1, column: 1]"

If I provide only a single object, it takes it.

The problem is that if I apply multiple objects each one will overwrite the other.  Seems I cannot apply multiple types of permissions to the same filter.

Anyone have it working?

[Deleted user · Accepted solution]

For posterity (at least on 7.12.3, not sure about later releases), when applying filter permissions via REST API:

1. Filter permission POST data will not accept an array using brackets. "[ ... , ...]" gives error.
2. Even passing comma separated permission objects without brackets results in only the first permission passed being applied. i.e. "{ perm1 }, { perm2}, { perm3}" gives no error, but only adds the first.
3. Allow all users viewable (eg loggedin) is '{"type":"authenticated","view":true,"edit":false}'  NOTE THIS WILL WIPE EXISTING PERMISSIONS.
4. Applying permission '{ "type": "loggedin","view": true,"edit": false }' is not valid input, use input in #3  to achieve this.
5. So if you want to allow anyone to view, apply global 'authenticated/loggedin' first, then apply groups and users if you want to anyone to edit filter.

Thanks to @Earl McCutcheon for the quick response, which probed me in the right direction to piece this together.  Especially 3-5 above which almost made me lose my mind :)

[Earl McCutcheon]

Hi Jorge,

The error that you are receiving looks like it might be a syntax error on the surface.

I just did a CURL to the endpoint on a test instance using a group as the input for the data variable in the following format with a single variable and it went through without issue:

curl -D- -u user:pass -X POST --data '{"type": "group","groupname": "jira-administrators","view": true,"edit": false}' -H "Content-Type: application/json" "http://1{BASE_URL}/rest/api/2/filter/{ID}/permission"

And a double variable of group and user, which also went through OK:

-data '{"type": "group","groupname": "jira-administrators","view": true,"edit": false},{"type": "user","userKey": "admin","view": true,"edit": true}' 

What is the format of your query particularly the data variable?

Regards,
Earl

[Deleted user]

Hi @Earl McCutcheon , thanks for following up.   Not entirely due to syntax error, but I now fix my original problem with a realization I just had, applying type:"authenticated" wipes out all permissions, so applying that first and then other individually works.  Also you cannot apply multiple permissions at the same time, only the first is applied!

In summary (my Jira is version 7.12.3):

1. Yes, the brackets cause the error, but that just means the docs are wrong.  REST docs need to be updated to remove brackets from example input.
2. It appears that only applying type:"authenticated" wipes out the prior entries
3. You example exposes 2 bugs:
   1. An array of objects is not taken even though its valid JSON and documented as such, right?
   2. Passing un-bracketed objects is accepted, but only the FIRST object is applied (see details below).
4. Another BUG #3 bug:
   1. Applying a seemingly inconsistent permission to a Group (only?) {...,"view":false,"edit":true} (ie can edit but not see), actually applies the opposite, sets visible but not editable.
   2. Applying the above to a userKey actually produces acceptable error, states cannot apply such a permission.
5. Realization:  When the docs say "Adding a global permission removes all previous permissions from the filter," this means applying the object '{"type":"authenticated","view":true,"edit":false}' removes all previous permissions.  I though a global permission meant type:"global" as is shown in the example output of getSharePermissions - https://docs.atlassian.com/software/jira/docs/api/REST/7.12.1/?_ga=2.59592043.734763659.1565300840-53935605.1531842267#api/2/filter-getSharePermissions
   1. EG, the UI shows permission type "loggedin", but passing that responds with error message: "Invalid type given. Should be one of [PROJECT, GROUP, PROJECT_ROLE, GLOBAL, AUTHENTICATED, USER]"
   2. Why does the error message distinguish between GLOBAL & AUTHENTICATED, but when I pass type:"authenticated" it wipes all other permissions, which is the behavior attributed to "GLOBAL" in the REST docs.
6. I have endured much heartache and several hours on a simple script because the docs and input/output are inconsistent.  Frankly, the only difference between input and output is expected to be the output contains an assigned permission ID.  All other fields should be identical, and at a minimum, as in the example of a user permission where the output adds extra info such as avatar, self-url, etc, IT SHOULD NOT CHANGE PASSED FIELD VALUES!!!  Case in point, when I apply type:"authenticated", it should not return type:"loggedin", that makes no sense (See details below).

DETAILS (note use of bash variables to protect the innocent):

1. BUG #1: Brackets cause ERROR (REST docs example show they should be accepted):

$ echo "Start with private (no permissions) filter"
Start with private (no permissions) filter
optadmin@172.25.35.70 bvafcmd01 DEV [Thu Aug 08 20:03:12] ~/REST/jira/create_pmo_dash
$ curl -s -w "\n%{http_code}" -u $myuser:$mypwd -X GET "https://${myurl}/rest/api/2/filter/28536/permission" | { read body; read code; echo "$code"; jq <<< "$body"; }
200
[]
$ curl -s -w "\n%{http_code}" -u $myuser:$mypwd -X POST --data '[ {"type":"group","groupname":"jira-administrators","view":false,"edit":true},{"type":"group","groupname":"PMO","view":true,"edit":false} ]' -H "Content-Type: application/json" "https://${myurl}/rest/api/2/filter/28536/permission" | { read body; read code; echo "$code"; jq <<< "$body"| sed -e "s/$myurl/<myurl>/g" -e "s/$myuser/<myuser>/g"; }
400
{
"errorMessages": [
"Can not deserialize instance of com.atlassian.jira.rest.v2.search.SharePermissionInputBean out of START_ARRAY tokenn at [Source: org.apache.catalina.connector.CoyoteInputStream@79160be6; line: 1, column: 1]"
]
}

 2. BUG #2: Multiple objects without brackets are accepted, but only the first is processed:

$ curl -s -w "\n%{http_code}" -u $myuser:$mypwd -X GET "https://${myurl}/rest/api/2/filter/28536/permission" | { read body; read code; echo "$code"; jq <<< "$body"; }
200
[]
optadmin@172.25.35.70 bvafcmd01 DEV [Thu Aug 08 20:03:28] ~/REST/jira/create_pmo_dash
$ curl -s -w "\n%{http_code}" -u $myuser:$mypwd -X POST --data ' {"type":"group","groupname":"jira-administrators","view":false,"edit":true},{"type":"group","groupname":"PMO","view":true,"edit":false} ' -H "Content-Type: application/json" "https://${myurl}/rest/api/2/filter/28536/permission" | { read body; read code; echo "$code"; jq <<< "$body"| sed -e "s/$myurl/<myurl>/g" -e "s/$myuser/<myuser>/g"; }
201
[
{
"id": 34458,
"type": "group",
"group": {
"name": "jira-administrators",
"self": "https://<myurl>/rest/api/2/group?groupname=jira-administrators"
},
"view": true,
"edit": false
}
]

 
3. BUG #3:  view=false,edit=true results in opposite application for groups.  For users, it properly returns an error.

<See BUG #2, I passed view=false and edit=true, but returned output shows the opposite! >

 4.  Inconsistent data, input, output:

     UI view permission for all logged in users shows "Shared with logged-in users",  REST GET returns type="loggedin":

$ curl -s -w "\n%{http_code}" -u $myuser:$mypwd -X GET "https://${myurl}/rest/api/2/filter/28536/permission" | { read body; read code; echo "$code"; jq <<< "$body"; }
200
[
{
"id": 34459,
"type": "loggedin",
"view": true,
"edit": false
}
]

     But applying type="loggedin" returns error:

$ curl -s -w "\n%{http_code}" -u $myuser:$mypwd -X POST --data '{"type":"loggedin","view":true,"edit":false}' -H "Content-Type: application/json" "https://${myurl}/rest/api/2/filter/28536/permission" | { read body; read code; echo "$code"; jq <<< "$body"| sed -e "s/$myurl/<myurl>/g" -e "s/$myuser/<myuser>/g"; }
400
{
"errorMessages": [
"Invalid type given. Should be one of [PROJECT, GROUP, PROJECT_ROLE, GLOBAL, AUTHENTICATED, USER]"
],
"errors": {}
}

    Error message shown above implies GLOBAL and AUTHENTICATE are different, but applying type="authenticated" results in wiping all other permissions, which is what the REST docs state is the behavior of authenticated!!!

$ curl -s -w "\n%{http_code}" -u $myuser:$mypwd -X POST --data '{"type":"group","groupname":"jira-administrators","view":false,"edit":true},{"type":"group","groupname":"PMO","view":false,"edit":true}' -H "Content-Type: application/json" "https://${myurl}/rest/api/2/filter/28536/permission" | { read body; read code; echo "$code"; jq <<< "$body"| sed -e "s/$myurl/<myurl>/g" -e "s/$myuser/<myuser>/g"; }
201
[
{
"id": 34462,
"type": "group",
"group": {
"name": "jira-administrators",
"self": "https://<myurl>/rest/api/2/group?groupname=jira-administrators"
},
"view": true,
"edit": false
}
]

$ curl -s -w "\n%{http_code}" -u $myuser:$mypwd -X POST --data '{"type":"group","groupname":"PMO","view":false,"edit":true}' -H "Content-Type: application/json" "https://${myurl}/rest/api/2/filter/28536/permission" | { read body; read code; echo "$code"; jq <<< "$body"| sed -e "s/$myurl/<myurl>/g" -e "s/$myuser/<myuser>/g"; }
201
[
{
"id": 34463,
"type": "group",
"group": {
"name": "jira-administrators",
"self": "https://<myurl>/rest/api/2/group?groupname=jira-administrators"
},
"view": true,
"edit": false
},
{
"id": 34464,
"type": "group",
"group": {
"name": "PMO",
"self": "https://<myurl>/rest/api/2/group?groupname=PMO"
},
"view": true,
"edit": false
}
]

$ curl -s -w "\n%{http_code}" -u $myuser:$mypwd -X POST --data '{"type":"authenticated","view":true,"edit":false}' -H "Content-Type: application/json" "https://${myurl}/rest/api/2/filter/28536/permission" | { read body; read code; echo "$code"; jq <<< "$body"| sed -e "s/$myurl/<myurl>/g" -e "s/$myuser/<myuser>/g"; }
201
[
{
"id": 34465,
"type": "loggedin",
"view": true,
"edit": false
}
]