[ Question / Feature Request ] - Is there a technical reason we can't have different column permissions on each role

[ShanonJackson]

Have many situations where I'm trying to manage PII user data.

Can we please get column permissions, that are more flexible than just true/false, I know you can create a view but this isn't really a good solution because I can't foreign key to my view, and again because column permissions are binary (on/off) in my view, if I need a different column available under different circumstances, again its another view or custom backend simply to just change permissions.

This has been one of the only pain points with Hasura for me is the permissions system is flexible for everything but columns.

I would love to have a base permissions set, say X equals true or Y equals true.

Then permissions on columns say column "A" is available when Z equals true.

The resulting query would be.... (X equals true OR y equals true ) AND Z equals true, when column "A" is in the query.

Feel like this works for all possible combinations.

[esseswann]

I think that the biggest technical problem is that the columns are not exposed in the schema when they're turned off for a specific role. Having them conditionally shown would require more schema generation on the fly which implies complications both in implementation and performance

[ShanonJackson]

At the moment you could have all the permissions for a role, and a column; But not be able to query it because the check fails; Thus The column is in the schema so you have knowledge of it, but cannot query it.

Isn't this the same?

We would change it so any optionally available column is also in the schema, under your role; However the check of that column can still potentially fail at run time.

TL;DR its true columns turned "off" currently AREN"T in the schema; However the assumption would be the column is turned "on" but the check can pass/fail just like how permissions currently work

[esseswann]

As previously said it would impose on-the-fly generation of the schema which is not the case right now. Right now the schema is generated for each role which is obviously easier to maintain within Hasura code and more performant

[ShanonJackson]

Esse i'm not following this would not be on-the-fly; If a column is optionally available then I'm proposing we put it inside the schema under that role, accessing that column without the correct check passing would fail the query.

Is this not a suitable option?

[esseswann]

This would be on-the-fly while current schema is not. I am explaining the technical difficulty here

[ShanonJackson]

I think this would be a trade-off most people would generally want to make; Let's say optional columns trigger on-the-fly schema; This will likely still be more performant and preferably than multiple views of the same data. The way we're currently solving this is with remote schema with Prisma/Lambda/Nexus which gets nowhere near Hasura's performance, purely for flexibility around column permissions.

Having optional columns will likely result in better world-world performance because Hasura is so much more performant than the average backend setup.