Following discussion, we've agreed that /times will be able to insert errors on the times list when the user uses a filter for a project they don't have permissions on. For example, consider that there are two projects, foo, and bar, and the user has permission to viewfoo, but notbar``.
GET /times
[
{
"project": ["foo"],
...
},
{
"project": ["foo"],
}
]
GET /times?project=foo
[
{
"project": ["foo"],
...
},
{
"project": ["foo"],
}
]
GET /times?project=bar
[
{
"error": "Authorization failure",
"status": "401",
"text": "example-user is not authorized to view times for bar"
}
]
GET /times?project=foo&project=bar&project=foobar
[
{
"project": ["foo"],
...
},
{
"project": ["foo"],
},
{
"error": "Authorization failure",
"status": "401",
"text": "example-user is not authorized to view times for bar"
},
{
"error": "Object not found",
"status": "404",
"text": "Project foobar does not exist"
}
]
Note that the 404 error text is different than documented. We would want to change this.
If the list contains any errors, even if valid times are also sent, the endpoint returns a 400 Bad Request status, to allow clients to find and filter errors during processing. If there are no errors, a 200 OK is returned.
Following discussion, we've agreed that /times will be able to insert errors on the times list when the user uses a filter for a project they don't have permissions on. For example, consider that there are two projects,
foo, andbar, and the user has permission to viewfoo, but notbar``.GET /timesGET /times?project=fooGET /times?project=barGET /times?project=foo&project=bar&project=foobarNote that the 404 error text is different than documented. We would want to change this.
If the list contains any errors, even if valid times are also sent, the endpoint returns a 400 Bad Request status, to allow clients to find and filter errors during processing. If there are no errors, a 200 OK is returned.