Schema | Open in playground
Brief Examination of the Model
The model defines several entities and relations, as well as actions and permissions that can be taken by users within the group. Let’s examine them shortly;Entities & Relations
-
user
entity represents a user in the Facebook. -
group
entity represents the Facebook group, and it has several relations including member, admin, and moderator to represent the members, admins, and moderators of the group. Additionally, there are relations to represent the posts and comments in the group. -
post
entity represents a post in the Facebook group, and it has relations to represent the owner of the post and the group that the post belongs to. -
comment
entity represents a comment on a post in the Facebook group, and it has relations to represent the owner of the comment, the post that the comment belongs to, and the comment itself. -
like
entity represents a like on a post in the Facebook group, and it has relations to represent the owner of the like and the post that the like belongs to. -
poll
entity represents a poll in the Facebook group, and it has relations to represent the owner of the poll and the group that the poll belongs to. -
file
entity represents a file in the Facebook group, and it has relations to represent the owner of the file and the group that the file belongs to. -
event
entity represents an event in the Facebook group, and it has relations to represent the owner of the event and the group that the event belongs to.
Permissions
We have several actions attached with the entities, which are limited by certain permissions. For example, thecreate_group
action can only be performed by a member
, as follows:
Creating a group permission
edit_post
action in the post entity, which specifies the permissions required to edit a post in a Facebook group.
Editing a post permission
Nested Hierarchies
For example, we can define a permission “view_comment” if only user is owner of that comment or user is a member of the group which the comment’s post belongs.post.group_member
refers to the members of the group to which the post belongs. We defined it as action in post entity as,
Relationships
Based on our schema, let’s create some sample relationships to test both our schema and our authorization logic.Test & Validation
Finally, let’s check some permissions and test our authorization logic.can user:4 RSVP_to_event event:1 ?
can user:4 RSVP_to_event event:1 ?
event:1
or a member of the group that belongs to event:1
can grant access to RSVP to the event.According to the relation tuples we created, user:4
is not the owner of the event. Furthermore, when we check whether user:4
is a member of the only group (group:1
) that event:1
is part of (event:1#group@group:1
), we see that there is no member relation for user:4
in that group.Therefore, the user:4 RSVP_to_event event:1
check request should yield a ‘false’ response.can user:5 view_comment comment:1 ?
can user:5 view_comment comment:1 ?
user:5
is not the owner of the comment. But member of the group:1
and thats grant user:5
(group:1#member@user:5
) access to perform view the comment:1. In particularly, comment:1
is part of the post:1
(comment:1#post@post:1
) and post:1
is part of the group:1 (post:1#group@group:1
). And from the action definition on above model group:1 members can view the comment:1
.Therefore, the user:5 view_comment comment:1
check request should yield a ‘true’ response.Using Schema Validator in Local
After cloning Permify, open up a new file and copy the schema yaml file content inside. Then, build and run Permify instance using the commandmake serve
.

permify validate {path of your schema validation file}
to start the test process.
The validation result according to our example schema validation file:
