Inherited/Nested Permissions
The reason we have two keywords for defining permissions (action
and permission
) is that while most permissions are based on actions (such as view, read, edit, etc.), there are still cases where we need to define permissions based on roles or user types, such as admin or member.
Additionally, there may be permissions that need to be inherited by child entities. Using the permission
keyword in these cases is more convenient and provides better reasoning of the schema.
Let’s examine a small snippet from our Facebook Groups real world example.
We have the ‘view’ in the comment entity which represents the comments of the post in Facebook Groups
Users can only view a comment if:
-
The user is the owner of that comment
or
-
The user is a member of the group to which the comment’s post belongs.
The post.group_member
refers to the members of the group to which the post belongs. We defined it as action in post entity as,
Permissions can be inherited as relations in other entities. This allows to form nested hierarchical relationships between entities.
In this example, a comment belongs to a post which is part of a group. Since there is a ‘member’ relation defined for the group entity, we can use the ‘group_member’ permission to inherit the member relation from the group in the post and then use it in the comment.
Examine Further
You can examine our Google Docs example to learn how users can gain direct access to a document through organizational roles or through inherited/nested permissions.