API to remove inherited permissions

[pco88]

It seems to be years since I've been back to the community but here I am with a question that I didn't quite get a fruitful answer from support.

API Basics say to add viewing for a user for a particular object, you do:

v10.0/optask/issueIDxxxx?updates={"accessRules":[{"accessorID":"groupIDxxxx","accessorObjCode":"GROUP","coreAction":"VIEW"}]}

This is fine and adds the share but I want the reverse, I want to remove inherited permissions for all other users of the object.

I would have tough that the api above would overwrite and set the group with the share permission and remove others but it does not. Apparently, that's how it should work according to support. I asked though what's the API call to remove inherited users and all he said was to remove the permission from the parent object. That's really not what I needed.

So - I'm asking the community whether you have other ideas on how to implement this without me manually going to the issue and removing inherited permissions one by one?

Regards.

[William--]

Hi Polly, glad to see you are still part of our Workfront universe!

Either in the query string or In the JSON after the collection of accessRules, try adding:

"removalOptions":"{}",

"options":"{"removeInheritedAccess":true}"

I don't have time to test it but that should get you pretty close. If not, I'll probably have time to experiment over the weekend.

Good luck!

[pco88]

Glad to be back in the forum!

I tried a few ways to add those but I can't get it to work. I tried the following:

v10.0/optask/IDxxx?updates={"accessRules":[{"removalOptions":"{}"}]}&method=PUT

just to simplify it and it's telling that it does not support field removalOptions (AccessRule).

Could you show me what the whole call write up should be?

[William--]

My bad - when I inspected the call I didn't confirm the URL path on the request. It turns out there are a few challenges:

1. The parameters are attributes of ACSRUL, not OPTASK.
2. I'm able to make API calls and successfully remove inherited permissions, but not in the way that I'm accustomed:
   1. The call doesn't use the /attask/API/v---/ path. I can GET access rules using that path, but not PUT or POST.
   2. The format of the POST call's body is x-www-form-urlencoded as opposed to JSON.
   3. Depending on what tools you are using to compose and send your API calls, the above may be difficult or not possible. I'm testing in Postman.

The URL I used is : https://instance.my.workfront.com/internal/share/setAccessRules

The x-www-form-urlencoded body is:

accessRules=[{"objCode":"ACSRUL","accessorObjCode":"USER","accessorID":"5c4b...90c0","securityObjCode":"OPTASK","coreAction":"DELETE","secondaryActions":[],"forbiddenActions":[]},{"objCode":"ACSRUL","accessorObjCode":"USER","accessorID":"5c53...1e4c","securityObjCode":"OPTASK","coreAction":"DELETE","secondaryActions":[],"forbiddenActions":[]}]&objCode=OPTASK&objIDs=["6040...a342"]&options={"removeInheritedAccess":true}&removalOptions={}

I tried transcoding the above to JSON but wasn't able to get it to work.

It looks like this in Postman. In red, you can see I had to use a different format. Usually I would use a "raw JSON" format (in yellow). And in green you can see the response for this call was successful, which I confirmed in the UI.

I might give it another go when I have more time to experiment. It seems like something we should be able to do via API, it doesn't make sense that the UI would be our only option.

[pco88]

Hi Bill,

Thanks for the clarification. I'll have to dig in my older scripts to see where I may have called to "internal". I feel like I've done it before but it's been quite some time that I had to do a call like that so have to search for it.

I'll try it later today and will post back on the forum if I'm able to make it work.

[Doug_Den_Hoed__AtAppStore]

Ooooh: sweet tip, Bill: it's in The Vault!

Thanks,

Doug

[pco88]

Hey @Doug Den Hoed‚ , glad to "see" familiar/OG names in the forum again.

[fadiwissa]

Has anyone figured this out in a formal API way (without using the internal end-point that is suggested above)?