When calling POST /api/v1/tasks/changestatuses with API-key auth (private task, entityId set to the target user), I get:
[
{
"code": "unauthorized",
"description": "The tasks with ids: <TASK_ID> blocked by insufficient permissions.",
"link": "https://developers.awork.com"
}
]
But checking the task afterwards in the awork UI, the status has actually been changed to the target status. The API reports failure, but the write succeeds server-side.
Could someone from the awork team confirm whether changestatuses is meant to fully support API-key auth for private tasks, and if there’s a known permissions gap here, whether the error could be returned before the change is applied?
@Armin i checked the code and it does not look like the described behavior is possible. For a none oauth api key token you should not be able to change a private task because private tasks can only be changed by the creator or assignee of the task. So if you would like to change private tasks of users you need to do the oauth flow for that user and use that token. There is no code path where we evaluate 401 for that operation and then change it. Could you give us the trace id from the response headers to check why you observe different behavior?
Thanks Nils — tested again via a different tool (n8n) with the same request structure and it returned 204 No Content, with the status actually changed to „done“.
Hi @Armin, the permission model allows the creator and assignee of a private task to modify them. In this case this task was created by the API key user and assigned to a different user, so both should be allowed to change the status.
The entityId you’re passing in the request has no effect on the permissions.
Update: found it — I had used a different API key in Postman than the one in my actual integration. That explains the 401, matches your explanation exactly (that key wasn’t creator or assignee on those tasks). No bug on your end, sorry for the noise — and thanks for the quick help!
