Reusing permissions

It would be very useful to be able to reuse permission definitions in some way. Let’s say you have these tables (should be self-explanatory, a basic setup for groups with users who can author comment on posts)

user
group
post
comment

group_member (user+group relation)
group_post (post+group relation)
group_post_comment (post+comment relation)

The overarching permission setup here is through the group_member table. If there is an entry for a given group and a given user, that user can access any post and comment in the group.

Currently I have to duplicate this permission check (“user is member of group”) in the group, post, comment, group_post and group_post_comment. All that duplication makes the configuration tedious and error-prone.

What I’m suggesting is some sort of functionality to indicate that a user has access to a post if they have access to the corresponding group, ie. delegate a select/insert/update/delete permission to another type. It gets even trickier when managing roles, so being able to indicate that you can delete a post if user_id = x-hasura-user-id or if “x-hasura-user-id is an admin or owner of <group>” would be amazing.

Is there currently an easier way to handle this than the duplication permissions? I realize this is a huge task, and would likely require a remake of the permission editor, but I’d like to know if anyone else is struggling a bit with this.

All that said, it’s not impossibly hard to do this currently, it could just be very much easier.

(Sorry if this has come up before, I couldn’t find any issues mentioning it)

[Bessonov]

Run in the same challenge. I have an entity, let say A, with a little bit complex permission rules. Entity B has a FK to entity A and entity C has a FK to entity B. Both B and C follows the same rules like entity A: is entity A selectable, then B&C are selectable too. Same for update and delete. It would be great if I could specify in entity C something like {"b":{"a":{"_use_perm_from": "select"}}}.

[esseswann]

1. Delegation by foreign key: on a group_post (a table containing posts in a group), with a foreign key to groups, you would say that if you have access to the referenced group, you also have access to the group_post.

This is probably a valid approach since if the referenced table row’s key is not accessible because of some permissions seems logical that another table rows referencing it through foreign key shouldn’t also be accessible. The problem is a possible explosion of joins when the algorithm is gonna traverse upwards and for each table does the same thing – check if the rows having foregin keys are accessible through parents