-
-
Notifications
You must be signed in to change notification settings - Fork 277
docs(testing): grammar and clarity improvements #2685
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -4,7 +4,7 @@ icon: 'vial' | |||||||||||||
| title: 'Testing & Validation' | ||||||||||||||
| --- | ||||||||||||||
|
|
||||||||||||||
| Testing is critical process when building and maintaining an authorization system. This page explains how to ensure the new authorization model and related authorization data works as expected in Permify. | ||||||||||||||
| Testing is a critical process when building and maintaining an authorization system. This page explains how to ensure the new authorization model and related authorization data works as expected in Permify. | ||||||||||||||
|
|
||||||||||||||
| Assuming that you're familiar with creating an authorization model and forming relation tuples in Permify. If not, we're strongly advising you to examine them before testing. | ||||||||||||||
|
|
||||||||||||||
|
|
@@ -40,10 +40,10 @@ If you don't know how to create Github action workflow and add a action to it, y | |||||||||||||
|
|
||||||||||||||
| ## Schema Validation File | ||||||||||||||
|
|
||||||||||||||
| Below you can examine an example schema validation yaml file. It consists 3 parts; | ||||||||||||||
| - `schema` which is the authorization model you want to test, | ||||||||||||||
| - `relationships` sample data to test your model, | ||||||||||||||
| - `scenarios` to test access check queries within created scenarios. | ||||||||||||||
| Below, you can examine an example schema validation yaml file. It consists 3 parts; | ||||||||||||||
mooreds marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||||||||||
| - `schema` which is the authorization model you want to test | ||||||||||||||
| - `relationships` which is the sample data to test your model | ||||||||||||||
| - `scenarios` which is the way to actually test access check queries within created scenarios | ||||||||||||||
|
Comment on lines
+44
to
+46
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
[suggestion]: why use more word when few word do trick? |
||||||||||||||
|
|
||||||||||||||
| ### Defining the Schema: | ||||||||||||||
|
|
||||||||||||||
|
|
@@ -149,17 +149,17 @@ scenarios: | |||||||||||||
| edit : ["58"] | ||||||||||||||
| ``` | ||||||||||||||
|
|
||||||||||||||
| Assuming that you're well-familiar with the `schema` and `relationships` sections of the above YAML file. If not, please see the previous sections to learn how to create an authorization model (schema) and generate data (relationships) according to it. | ||||||||||||||
| You should be familiar with the `schema` and `relationships` sections of the above YAML file. If not, please see the previous sections to learn how to [create an authorization model (the schema)](/getting-started/modeling) and [generate data (relationships)](/getting-started/sync-data) according to a schema. | ||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
[suggestion]: reduce wordiness; phrases like 'you should be familiar with' are mostly filler. let's just get straight to the point instead! |
||||||||||||||
|
|
||||||||||||||
| We'll continue by examining how to create scenarios. | ||||||||||||||
| Next, you'll examinine how to create scenarios. | ||||||||||||||
mooreds marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
coderabbitai[bot] marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||||||||||
|
|
||||||||||||||
| ## Creating Test Scenarios | ||||||||||||||
|
|
||||||||||||||
| You can create multiple access checks at once to test whether your authorization logic behaves as expected or not. | ||||||||||||||
|
|
||||||||||||||
| Besides simple access checks you can also test subject filtering queries and data (entity) filtering with it. | ||||||||||||||
|
|
||||||||||||||
| Let's deconstruct the `scenarios`, | ||||||||||||||
| Let's deconstruct the `scenarios` configuration. | ||||||||||||||
|
|
||||||||||||||
| ### Scenarios | ||||||||||||||
|
|
||||||||||||||
|
|
@@ -187,7 +187,7 @@ checks: | |||||||||||||
| push : true | ||||||||||||||
| ``` | ||||||||||||||
|
|
||||||||||||||
| Semantics for above check is: whether `user:1` can push to `repository:3`, additional to stored tuples take account that user:1 is owner of repository:3 (`repository:3#owner@user:1`). Expected result for that check it **true** - `push : true` | ||||||||||||||
| Semantics for above check is: whether `user:1` can push to `repository:3`, in addition to stored tuples, take into account that user:1 is owner of repository:3 (`repository:3#owner@user:1`). Expected result for that check it **true** - `push : true` | ||||||||||||||
coderabbitai[bot] marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||
|
|
||||||||||||||
| ### Depth Configuration | ||||||||||||||
|
|
||||||||||||||
|
|
@@ -211,8 +211,8 @@ checks: | |||||||||||||
| ``` | ||||||||||||||
|
|
||||||||||||||
| **When to use depth:** | ||||||||||||||
| - Use a lower depth (e.g., 3-5) for shallow permission hierarchies to improve performance | ||||||||||||||
| - Use a higher depth (e.g., 20-50) for deep nested relationships | ||||||||||||||
| - Use a lower depth (e.g., 3-5) for a shallow permission hierarchy to improve performance | ||||||||||||||
| - Use a higher depth (e.g., 20-50) for deeply nested relationships | ||||||||||||||
| - If you encounter "depth not enough" errors, increase the depth value for that specific check | ||||||||||||||
|
|
||||||||||||||
| <Note> | ||||||||||||||
|
|
@@ -228,19 +228,19 @@ You can create `entity_filters` within `scenarios` to test your data filtering q | |||||||||||||
| ```yaml | ||||||||||||||
| entity_filters: | ||||||||||||||
| - entity_type: "repository" # entity that you want to filter | ||||||||||||||
| subject: "user:1" # subject that you want to perform data filtering | ||||||||||||||
| subject: "user:1" # subject for which you want to perform data filtering | ||||||||||||||
| depth: 100 # depth limit for permission check (optional, default: 100, minimum: 3) | ||||||||||||||
| context: null # additional data provided during an access check to be evaluated | ||||||||||||||
| assertions: | ||||||||||||||
| push : ["1", "3", "4", "5"] # IDs of the resources that we expected to return | ||||||||||||||
| edit : [] | ||||||||||||||
| ``` | ||||||||||||||
|
|
||||||||||||||
| The major difference between `check` lies in the assertions part. Since we're performing data filtering with bulk data, instead of a true-false result, we enter the IDs of the resources that we expect to be returned | ||||||||||||||
| The major difference between `entity_filters` and `checks` lies in the assertions part. Since we're performing data filtering with bulk data, instead of a true-false result, we enter the IDs of the resources that we expect to be returned. | ||||||||||||||
|
|
||||||||||||||
| ### Subject Filtering | ||||||||||||||
|
|
||||||||||||||
| You can create `subject_filters` within `scenarios` to test your subject filtering queries, a.k.a which users can perform action Y or have permission X on entity:Z? | ||||||||||||||
| You can create `subject_filters` within `scenarios` to test your subject filtering queries, such as which users can perform action Y or have permission X on entity:Z. | ||||||||||||||
|
|
||||||||||||||
| ```yaml | ||||||||||||||
| - subject_reference: "user" | ||||||||||||||
|
|
@@ -270,7 +270,7 @@ The output of the example provided above is as follows. | |||||||||||||
|
|
||||||||||||||
| You can also test your new authorization model in your local (Permify clone) without using [permify-validate-action] at all. | ||||||||||||||
|
|
||||||||||||||
| For that open up a new file and add a schema yaml file inside. Then build your project with, run `make build` command and run `./permify validate {path of your schema validation file}`. | ||||||||||||||
| For that open up a new file and add a schema yaml file inside. Then build your project, run `make build` command and run `./permify validate {path of your schema validation file}`. | ||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
3 steps is typically where I draw the line and create an ordered list. Also, I think 'build your project' and 'run make build command' are the same step, so even if we don't break this into discrete steps, we ought to ditch that comma! |
||||||||||||||
|
|
||||||||||||||
| If we use the above example schema validation file, after running `./permify validate {path of your schema validation file}` it gives a result on the terminal as: | ||||||||||||||
|
|
||||||||||||||
|
|
@@ -301,7 +301,7 @@ You can find more details about our suggested workflow to handle schema changes | |||||||||||||
|
|
||||||||||||||
| ## Need any 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](hhttps://calendly.com/d/cj79-kyf-b4z). | ||||||||||||||
| 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](https://calendly.com/d/cj79-kyf-b4z). | ||||||||||||||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have to admit, I would have missed this one! Nice eye. |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[suggestion]: reduce duplication of 'authorization' in this paragraph. 3 times is probably too many in such a small paragraph!