This is a schema definition of the authorization model for Notion, a popular productivity and organization tool.
The model defines several entities, including users, workspaces, pages, databases, blocks, and integrations. It also includes several default roles, such as Admin, Bot, Guest, and Member. Here’s a breakdown of the entities:
user
: Represents a user in the system.
workspace
: Represents a workspace in which users can collaborate. Each workspace has an owner, members, guests, and bots associated with it. The owner and admin users have permission to manage the workspace. Permissions are defined for creating pages, inviting members, viewing the workspace, and managing the workspace. The read and write permissions can be inherited by child entities.
page
: Represents a page within a workspace. Each page is associated with a workspace and has a writer and readers. The read and write permissions are defined based on the writer and readers of the page and can be inherited from the workspace.
database
: Represents a database within a workspace. Each database is associated with a workspace and has an editor and viewers. The read and write permissions are defined based on the editor and viewers of the database and can be inherited from the workspace. Permissions are also defined for creating and deleting databases.
block
: Represents a block within a page or database. Each block is associated with a page or database and has an editor and commenters. The read and write permissions are defined based on the editor and commenters of the block and can be inherited from the database. Commenters are users who have permission to comment on the block.
comment
: Represents a comment on a block. Each comment is associated with a block and has an author. The read and write permissions are defined based on the author of the comment and can be inherited from the block.
template
: Represents a template within a workspace. Each template is associated with a workspace and has a creator and viewers. The read and write permissions are defined based on the creator and viewers of the template and can be inherited from the workspace. Permissions are also defined for creating and deleting templates.
integration
: Represents an integration within a workspace. Each integration is associated with a workspace and has an owner. Permissions are defined for reading and writing to the integration.
We have several actions attached with the entities, which are limited by certain permissions. Let’s examine the read permission of the page entity.
This permission specifies who can read the contents of the page at Notion.
The reader
relation specifies the users who are members of the workspace associated with the page (workspace#member
) or guests of the workspace (workspace#guest
).
Read permission of the workspace inherited as workspace.read
in the page entity. THis permission specifies that any user who has been granted read access to the workspace object (i.e., the workspace that the page belongs to) can also read the page.
In summary, any user who is a member or guest of the workspace and has been granted read access to the page through the reader relation, as well as any user who has been granted read access to the workspace itself, can read the contents of the page.
Based on our schema, let’s create some sample relationships to test both our schema and our authorization logic.
Since we have our schema and the sample relation tuples, let’s check some permissions and test our authorization logic.
Can user:alice write database:task_list ?
According to what we have defined for the ‘write’ permission, users who are either;
database:task_list
)database:task_list#workspace@workspace:engineering_team
)can edit the task list database (database:task_list
)
Based on the relation tuples we created, user:alice
doesn’t have the editor relationship with the database:task_list
.
Since user:alice
is the owner and admin in the engineering team workspace (workspace:engineering_team#admin@user:alice
) it has a write permission defined in the workspace entity, as you can see below:
And as we mentioned the engineering team workspace is the only workspace that task list is associated (database:task_list#workspace@workspace:engineering_team
). Therefore, the user:alice write database:task_list
check request should yield a ‘true’ response.
Can user:charlie write page:product_spec ?
user:charlie
is guest in the workspace (workspace:engineering_team#guest@user:charlie
) and the engineering team workspace is the only workspace that page:product_spec
belongs to.
As we defined, guests doesn’t have write permission in a workspace.
So that, user:charlie
doesn’t have a write relationship in the workspace. And ultimately, the user:charlie write page:product_spec
check request should yield a ‘false’ response.
Let’s test these access checks in our local with using permify validator. We’ll use the below schema for the schema validation file.
After cloning Permify, open up a new file and copy the schema yaml file content inside. Then, build and run Permify instance using the command make serve
.
Then run permify validate {path of your schema validation file}
to start the test process.
The validation result according to our example schema validation file:
This is the end of demonstration of the authorization structure for Facebook groups. To install and implement this see the Set Up Permify section.
If you need any kind of help, our team is happy to help you get started with Permify. If you’d like to learn more about using Permify in your app or have any questions about it, schedule a consultation call with one of our account executives.
This is a schema definition of the authorization model for Notion, a popular productivity and organization tool.
The model defines several entities, including users, workspaces, pages, databases, blocks, and integrations. It also includes several default roles, such as Admin, Bot, Guest, and Member. Here’s a breakdown of the entities:
user
: Represents a user in the system.
workspace
: Represents a workspace in which users can collaborate. Each workspace has an owner, members, guests, and bots associated with it. The owner and admin users have permission to manage the workspace. Permissions are defined for creating pages, inviting members, viewing the workspace, and managing the workspace. The read and write permissions can be inherited by child entities.
page
: Represents a page within a workspace. Each page is associated with a workspace and has a writer and readers. The read and write permissions are defined based on the writer and readers of the page and can be inherited from the workspace.
database
: Represents a database within a workspace. Each database is associated with a workspace and has an editor and viewers. The read and write permissions are defined based on the editor and viewers of the database and can be inherited from the workspace. Permissions are also defined for creating and deleting databases.
block
: Represents a block within a page or database. Each block is associated with a page or database and has an editor and commenters. The read and write permissions are defined based on the editor and commenters of the block and can be inherited from the database. Commenters are users who have permission to comment on the block.
comment
: Represents a comment on a block. Each comment is associated with a block and has an author. The read and write permissions are defined based on the author of the comment and can be inherited from the block.
template
: Represents a template within a workspace. Each template is associated with a workspace and has a creator and viewers. The read and write permissions are defined based on the creator and viewers of the template and can be inherited from the workspace. Permissions are also defined for creating and deleting templates.
integration
: Represents an integration within a workspace. Each integration is associated with a workspace and has an owner. Permissions are defined for reading and writing to the integration.
We have several actions attached with the entities, which are limited by certain permissions. Let’s examine the read permission of the page entity.
This permission specifies who can read the contents of the page at Notion.
The reader
relation specifies the users who are members of the workspace associated with the page (workspace#member
) or guests of the workspace (workspace#guest
).
Read permission of the workspace inherited as workspace.read
in the page entity. THis permission specifies that any user who has been granted read access to the workspace object (i.e., the workspace that the page belongs to) can also read the page.
In summary, any user who is a member or guest of the workspace and has been granted read access to the page through the reader relation, as well as any user who has been granted read access to the workspace itself, can read the contents of the page.
Based on our schema, let’s create some sample relationships to test both our schema and our authorization logic.
Since we have our schema and the sample relation tuples, let’s check some permissions and test our authorization logic.
Can user:alice write database:task_list ?
According to what we have defined for the ‘write’ permission, users who are either;
database:task_list
)database:task_list#workspace@workspace:engineering_team
)can edit the task list database (database:task_list
)
Based on the relation tuples we created, user:alice
doesn’t have the editor relationship with the database:task_list
.
Since user:alice
is the owner and admin in the engineering team workspace (workspace:engineering_team#admin@user:alice
) it has a write permission defined in the workspace entity, as you can see below:
And as we mentioned the engineering team workspace is the only workspace that task list is associated (database:task_list#workspace@workspace:engineering_team
). Therefore, the user:alice write database:task_list
check request should yield a ‘true’ response.
Can user:charlie write page:product_spec ?
user:charlie
is guest in the workspace (workspace:engineering_team#guest@user:charlie
) and the engineering team workspace is the only workspace that page:product_spec
belongs to.
As we defined, guests doesn’t have write permission in a workspace.
So that, user:charlie
doesn’t have a write relationship in the workspace. And ultimately, the user:charlie write page:product_spec
check request should yield a ‘false’ response.
Let’s test these access checks in our local with using permify validator. We’ll use the below schema for the schema validation file.
After cloning Permify, open up a new file and copy the schema yaml file content inside. Then, build and run Permify instance using the command make serve
.
Then run permify validate {path of your schema validation file}
to start the test process.
The validation result according to our example schema validation file:
This is the end of demonstration of the authorization structure for Facebook groups. To install and implement this see the Set Up Permify section.
If you need any kind of help, our team is happy to help you get started with Permify. If you’d like to learn more about using Permify in your app or have any questions about it, schedule a consultation call with one of our account executives.