Hi,
I couldn't let go of it, so I gave it a try. I get the same error message again with the PUT call.
So, I would create a support ticket, as everything from here would be based on workarounds...
One possible solution could be to "simulate" the UI action as you already traced using your browsers dev tools.
In this thread you can read, how that is done to turn of inheritance of permissions, as there is no regular API-way for it yet...
Regards
Lars
Hi Lars,
just to let you know the adobe's response on this. It seems that there is a workaround to solve the problem and that is to use the new authentication/custom call module to be able to log in first and then do what we need.
Steps
- Generate an AEM Technical Cccount
- Add the technical account to Workfront
- Ensure it has API privileges in the admin console
- Run a Workfront API call against the user endpoint for that account (hit the initializeStatelessDocumentProviderForUser action)
- Use the Adobe Authenticator module to then send the moveToFolder action to Workfront:
Once steps 1-4 are completed step 5 should always work (if you get a 403 error, one of the above steps wasn't completed correctly)
And here is what i did
1) call to search user to get the user id in workfront (tech user)
/attask/api/v18.0/USER/search
2) for next step we need the documentProviderConfigID, for this is used this endpoint
/attask/api-internal/DOCCFG/search
3) userID from point 1, docProvId from point 2
attask/api-internal/USER/{{userID}}/initializeStatelessDocumentProviderForUser?documentProviderConfigID={{docProvId}}&providerType=AEM
4) add the Adobe Authenticator module on fusion scenario, configure the technical user account for login and call
PUT /attask/api-internal/DOCU/moveToFolder