Changing sharing permissions on document folders via Fusion

[JohnJOSullivan]

Hi again,

As usual, I have a question on something which feels like it should be easy...but then it isn't.

I have an ask from a user where she wants Fusion to create a folder, remove inherited permissions, and set access to the folder to a particular team. 

Currently, I have Fusion adjust permissions for Projects and Issues. This doesn't seem to follow the same pattern wherein you can make a Custom API call and set accessorID, accessorObjCode, and coreActions. I tried that and Fusion didn't like it. 

Why isn't this templated? The folders in question are linked to SharePoint in order to store Word docs. We already do this; the only difference here is that we want this particular folder to only be visible to the people who need to add and access files in it. 

Sharing permissions on folders is relatively "new," so I'm unsure if they are managed differently than other objects inside of Workfront. 

Any help would be amazing. Thanks!

-j

[JohnJOSullivan]

Alright, so I made progress, but I'm being held up by something weird.

I did an API search using the browser (https://cvshealth.sb02.workfront.com/attask/api/v14.0/DOCFDR/search?ID=64f7be34000422c4bb651f60e8ce2...). This was great. It brought up all of the GUIDs of everyone who had visibility to the folder. Hurray!

This list included all users/groups/teams/companies which had inherited visibility rights to the folder. I mapped all out just to be sure.

What I found odd was that there were no accessorObjCode for these IDs like just about any other shared item in Workfront.

Anyhow, I tried running a custom API call in Fusion to replace all of these with one team. When I did, I got an error: 

Well, that makes sense to me. So, I attempted to correct like I do when I change sharing permissions on any other item in WF:

I attempt to run the scenario...it still says that the accessorObjCode can't be null. Um. It's not.  

But weirder: I go into the API explorer to find accessorObjCode for document folders. Aaaaaand, it's not there:

And if I attempt to search for accessorObjCode...API doesn't like:

I'm so close that I can taste it. Please tell me what I'm missing here. 

-j

[ChrisStephens]

John,

Try this.

Create a JSON with this structure:

{
  "objCode": "string",
  "accessorID": "string",
  "coreAction": "string",
  "securityObjID": "string",
  "accessorObjCode": "string",
  "forbiddenActions": ["string"],
  "secondaryActions": ["string"]
}

How to fill out the json:

objCode: ACSRUL

accessorID: {id you want to give access}

coreAction: {whatever core permission you want}

securityObjID: {folder ID}

accessorObjCode: {Object type of accessor ID}

securityObjCode: DOCFDR

forbiddenActions: {Array of actions you want to expressly exlude}

secondaryActions: {Array of actions you want to additionally include}

and then for the URL, {target object type}/{target object ID}?fields=accessRules, method is PUT, and put above JSON in the body. Note, you may have to use the unsupported API.

[JohnJOSullivan]

Thank you for the response! This gives a lot more useful context on how these things work on the back end.

This is what I did; unfortunately it didn't work. At least I got a new error: [422] invalid id. 

I double-checked the user and folder IDs; both are correct. Is this referring to a different ID#?

Thanks again!

-j

[ChrisStephens]

Sorry, forgot one thing on that JSON. It should be this:

{"accessRules": [
{everything from above}
]}