only partial schema is visible when backend only perm is true

[aaronhayes]

It appears having nested object relationships that have backend only insert permissions breaks schema introspection when the parent object has insert permissions without the backend only flag set. (For the same role)

Error produced when:
Parent Table Insert: backend-only = false
Child Table Insert: backend-only = true

No error is produced when both the parent and child insert permissions have the same value for backend-only.

The server outputs this error:

"error":{"path":"$","error":"type info not found for: 'audiences_obj_rel_insert_input'","code":"unexpected"}

Server Version: 1.2.2
CLI Version 1.2.2
Metadata Version: 2

[aaronhayes]

okay it seems when I set x-hasura-use-backend-only-permissions true I actually doesn't have access to any permissions where backend-only is false; for the provided x-hasura-role.

I would have assumed all permissions (for the given role) would be available to the trusted backend rather than just those that have explicitly been set to backend-only true.

Is this a bug? Expected?

IMO when setting x-hasura-use-backend-only-permissions to be true the user should be able to run any insert mutation that the role has permissions for regardless of if backend_only true OR false. Currently it only has access to insert mutations that at backend_only true.

EDIT: This explains why the schema introspection is broken.

[rakeshkky]

We are not treating the absence of backend_only configuration and backend_only: false same. Hence the bug exist.

[husniadil]

This has been happening to me as well, happily I found this, I thought it was happening only on my side.

[aaronhayes]

@husniadil in the interim I've just been user an extra user-backend role.

[pacoccino]

UP this as I have the same problem on v1.3.3

On the console, when I switch to the Relay API, the introspection works. On the regular GraphQL endpoint I get the schema introspection failed for {table}_obj_rel_insert_input

[dminkovsky]

On 10/20/2020 @tirumaraiselvan wrote on #6035 that this was a dupe and fixed in master. Is that correct?

Edit: This appears to be fixed in 2.0.2

[aaronhayes]

I'm pretty sure this has been fixed, so going to close the issue.