Why invisible objects return 404

When: POST /read/{id}

Result: When reading, the role comes first: without the read role you get 403, even for an invisible object.

When: POST /query

Invisible rows are missing from data and do not count in totalCount. There is no error.

Result: The hit count never reveals how many objects there are in total.

When: reference or list you read along

An invisible single reference comes back as null. In a list, invisible entries are missing.

Result: So null can mean: not set or invisible to you.

When: PUT /update/{id}, PATCH /update/{id}

Result: When writing, visibility comes first: invisible gives 404, even without the role.

When: A child with an id in a nested write

The same filters as reading, applied to the target: if it is invisible to you, the answer is 404 missing-object|<id>|<model> — the same answer an id that never existed gets. Read permission for the target model is required as well.

Result: You can only connect to what you could have looked at. See The four cases.

When: DELETE /delete/{id}

Same as changing: visibility first (404), then the delete role (403). You do not need a read role, but the read filters still apply.

Result: See How a DELETE runs.

When: POST /{id}/rollback/{revision}

Same as changing: visibility first (404), then the rollback role (403). A deleted object no longer exists; that also gives 404. If the rollback re-links a single reference, the old and the new target are checked as for linking.

Result: You can only roll back what you can see now.

When: GET /{id}/file

The download first reads the object like a read. Invisible → 404, before any file flows.

Result: See Downloading.

When: POST /{id}/history

First the two roles (403), then visibility: invisible → 404 missing-object|<id>|<model>. If the object has been deleted, its last state before the deletion counts. On a model with a filter, an unknown id cannot be told apart from a hidden one.

Result: See Reading the history.