Here's an example scenario
user { id name user_groups }
user_group { id user_id group_id user group }
group { id title }
article { id user_id title body user }
Permissions are simple. User role can select all article fields without check and update/delete if user_id matches permission variables
But i want to control who can insert articles without bringing a new role (I have the same scenario for many tables and don't want to introduce a new role for every table which only has a single difference compared to the user role.
So my idea was if it was possible to do insert "With custom check:" which checks based on the user table. I would like to be able to do check similar to this:
user { user_groups { group { title { _eq: "insert-articles" } } } }
This would be referencing the user based on the "X-Hasura-User-Id" variable and not based on the user relationship on the article table.
Interesting! So maybe we should allow checking a condition on a different table? For example, in your case you want to check if the user is part of a certain group. So, the condition for inserting on articles table is to check if the condition
{
"user_id": "x-hasura-user-id",
"group": {
"title": { "_eq": "insert-articles" }
}
}
holds on the user_group table!
Yes exactly! you got it. I think this would make for a much more flexible permission system and compliments the current design perfectly as well. Since you would be able to use the _AND, _OR etc based on both the acting table row and the table row referenced by the session variables.
This can also be useful for many other scenarios. Maybe you want users to be able to modify or delete a table row only if they are both in a specific group and the owner of that particular row based on user_id.
Another scenario. Let's say you use X-Hasura-Client-Id for each client. Then you can add the client to client_group to easily enable a specific feature on that client. If you have 20 features you want to control access to and keep adding more, it get's messy real fast to add a new role for each new feature. Having roles like manager/group-admin/user/public etc for each client makes sense. Then being able to add the client to new groups to add new features to the client which can affect each of the roles in a different way would be really nice.
Taking this a step further for super fine grained control you could also do something like:
user > user_group > group > group_permission > permission
You would then define the individual permissions in hasura on the permissions table. And then create your groups in group table. Add the permissions you want for groups in group_permission. And add your users to specific groups in user_group.
I discovered a hacky way to do this already in the current system.
Add field "dummy" to user table and any table you want to check with value 1 in all rows on both tables.
Add array relationship "all_users" referencing dummy -> dummy

Except for the hackish approach this works perfectly and is totally awesome for ultra flexible & fine grained permission control. Could be done without the dummy fields if #2298 is implemented
Best approach would probably be to add the root_query object in the permission builder so you don't need to add any relationship.
Closing this in favour of #2512
Most helpful comment
Interesting! So maybe we should allow checking a condition on a different table? For example, in your case you want to check if the user is part of a certain group. So, the condition for inserting on
articlestable is to check if the conditionholds on the
user_grouptable!