Tmsagarofficial patch 1 (#42)

* Update README.md * Update README.md * Update README.md * Update README.md * Update stores/abac-with-rebac/README.md Co-authored-by: Andrés Aguiar <[email protected]> --------- Co-authored-by: Andrés Aguiar <[email protected]> Co-authored-by: Andrés Aguiar <[email protected]>
openfga · Oct 7, 2024 · 0fc4d08 · 0fc4d08
1 parent 7b1f1ea
commit 0fc4d08
Show file tree

Hide file tree

Showing 4 changed files with 32 additions and 32 deletions.
diff --git a/stores/abac-with-rebac/README.md b/stores/abac-with-rebac/README.md
@@ -1,8 +1,8 @@
-# OpenFGA Modeling Attribute-Based Access Control with Relationship Based Access Control
+# OpenFGA Modeling Attribute-Based Access Control with Relationship-Based Access Control
 
 ## Use-Case
 
-This example demonstrates how to model Attribute-Based access control scenarios purely with Relationship Based Access Control constructs.
+This example demonstrates how to model Attribute-Based access control scenarios with relationship-based access Control constructs.
 
 In ABAC, you make authorization decisions based on different attributes of the user, the resource, and the environment. Depending on the kind of attribute, you can model them pretty easily in ReBAC or not.
 
@@ -51,7 +51,7 @@ type document
         define can_view : viewer from published
 ```
 
-If the attribute is a discrete variable with many possible values, e.g. birth date, age, IP address, a a currency amount, then it's not possible to be modeled with pure ReBAC and you need to resort to using [OpenFGA conditions](https://openfga.dev/docs/modeling/conditions). 
+If the attribute is a discrete variable with many possible values, e.g. birth date, age, IP address, a currency amount, then it's not possible to be modeled with pure ReBAC and you need to resort to using [OpenFGA conditions](https://openfga.dev/docs/modeling/conditions). 
 
 If you can model your attribute as a relation, you should do so, as it will make your model simpler and more efficient.
 

diff --git a/stores/advanced-entitlements/README.md b/stores/advanced-entitlements/README.md
@@ -2,11 +2,11 @@
 
 ## Use-Case
 
-This entitlements model is inspired on [Notion's subscription plans](https://www.notion.so/pricing).
+This entitlements model is inspired by [Notion's subscription plans](https://www.notion.so/pricing).
 
-Entitlements limits can be defined based on feature usage like number of collaborators, rows synced, page history days.
+Entitlement limits can be defined based on feature usage like number of collaborators, rows synced, and page history days.
 
-The model, tuples and unit tests are detailed in [store.fga.yaml](./store.fga.yaml).
+The model, tuples, and unit tests are detailed in [store.fga.yaml](./store.fga.yaml).
 
 ## Try It Out
 

diff --git a/stores/github/README.md b/stores/github/README.md
@@ -27,26 +27,26 @@ This model is based on GitHub's permission model according to their [documentati
 
 ### Scenario
 
-There are users, organizations, teams and repositories
+There are users, organizations, teams, and repositories
 
-- There are five users: Anne, Beth, Charles, Diane and Erik
+- There are five users: Anne, Beth, Charles, Diane, and Erik
 - There is an OpenFGA organization that owns the openfga/openfga repository
-- There is an openfga/core team and a openfga/backend team
+- There is an openfga/core team and an openfga/backend team
 - Members of the openfga/backend team are members of the openfga/core team
 - Members of the openfga/core team are admins of the openfga/openfga repository
 - Erik is a member of the OpenFGA organization
 - Diane is a member of the openfga/backend team
 - Charles is a member of the openfga/core team
-- Anne is a reader on the openfga/openfga repository
+- Anne is a reader of the openfga/openfga repository
 - Beth is a writer on the openfga/openfga repository
 - The OpenFGA organization has been configured with the "repository admin" base permission, which means all the organization members have the admin role on all the repositories the organization owns 
 
 ### Expected Outcomes
 
-- Anne is a reader on the openfga/openfga repository
+- Anne is a reader of the openfga/openfga repository
 - Anne **is not** a triager on the openfga/openfga repository
 - Diane is an admin on the openfga/openfga repository
-- Erik is a reader on the openfga/openfga repository
+- Erik is a reader of the openfga/openfga repository
 - Charles is a writer on the openfga/openfga repository
 - Beth **is not** an admin on the openfga/openfga repository
 
@@ -62,38 +62,38 @@ model
 # There are users
 type user
 
-# there are organizations
+# There are organizations
 type organization
   relations
     # Organizations can have users who own them
     define owner: [user]
     # Organizations can have members (any owner of the organization is automatically a member)
     define member: [user] or owner
-    # Organizations has a set of base permissions, such as repository admin, writer and reader
+    # Organizations have a set of base permissions, such as repository admin, writer, and reader
     define repo_admin: [user, organization#member]
     define repo_reader: [user, organization#member]
     define repo_writer: [user, organization#member]
 
-# there are teams
+# There are teams
 type team
   relations
     # teams have members
     define member: [user, team#member]
 
-# there are repositories
+# There are repositories
 type repo
   relations
-    # repositories have organizations who own them
+    # Repositories have organizations that own them
     define owner: [organization]
-    # repository have admins, they can be assigned or inherited (anyone who has the repository admin role on the owner organization is an owner on the repo)
+    # Repositories have admins, they can be assigned or inherited (anyone who has the repository admin role on the owner organization is an owner on the repo)
     define admin: [user, team#member] or repo_admin from owner
-    # maintainers on a repo are anyone who is directly assigned or anyone who is an owner on the repo
+    # Maintainers on a repo are anyone who is directly assigned or anyone who is an owner of the repo
     define maintainer: [user, team#member] or admin
-    # repo writers are users who are directly assigned, anyone who is a maintainer or anyone who has the repository writer role on the owner organization
+    # Repo writers are users who are directly assigned, anyone who is a maintainer, or anyone who has the repository writer role on the owner organization
     define writer: [user, team#member] or maintainer or repo_writer from owner
-    # triagers on a repo are anyone who is directly assigned or anyone who is a writer on the repo
+    # Triagers on a repo are anyone who is directly assigned or anyone who is a writer on the repo
     define triager: [user, team#member] or writer
-    # repo readers are users who are directly assigned, anyone who is a triager or anyone who has the repository reader role on the owner organization
+    # Repo readers are users who are directly assigned, anyone who is a triager or anyone who has the repository reader role on the owner organization
     define reader: [user, team#member] or triager or repo_reader from owner
 ```
 

diff --git a/stores/slack/README.md b/stores/slack/README.md
@@ -19,7 +19,7 @@
 
 This model is inspired by Slack and some of their publicly documented roles and permissions.
 
-> As reference, Slack's publicly available docs were used:
+> As a reference, Slack's publicly available docs were used:
 >
 > - [Role Management at Slack](https://slack.engineering/role-management-at-slack/)
 > - [Types of Roles in Slack](https://slack.com/intl/en-ca/help/articles/360018112273-Types-of-roles-in-Slack)
@@ -36,7 +36,7 @@ Workspace Roles:
 
 System Roles:
 
-- **Channels Admin**: This type of user has the permission to archive channels, rename channels, create private channels, and convert public channels into private channels.
+- **Channels Admin**: This type of user has permission to archive channels, rename channels, create private channels, and convert public channels into private channels.
 
 Channel Settings:
 
@@ -57,7 +57,7 @@ There are users, workspaces and channels.
 - #general channel is a public channel, anyone who is a member of the Sandcastle workspace can view it
 - In the Sandcastle workspace:
   - Amy has a legacy admin role
-  - Bob has a channels admin role
+  - Bob has a channel admin role
   - Catherine and Emily are members
   - David is a guest
 - Catherine and Emily are normal members of the Sandcastle workspace, they can view all public channels, as well as channels they have been invited to
@@ -89,23 +89,23 @@ type user
 # There are workspaces
 type workspace
   relations
-    # users can have the legacy admin role on workspaces
+    # Users can have the legacy admin role on workspaces
     define legacy_admin: [user]
-    # users can have the new channels admin role on workspaces (anyone with a legacy admin role also gets all the channels admin role access) 
+    # Users can have the new channels admin role on workspaces (anyone with a legacy admin role also gets all the channels admin role access) 
     define channels_admin: [user] or legacy_admin
-    # users can have the member role on workspaces, admins automatically get all access granted to members
+    # Users can have the member role on workspaces, admins automatically get all access granted to members
     define member: [user] or legacy_admin or channels_admin
-    # users can have the guest role on workspaces
+    # Users can have the guest role on workspaces
     define guest: [user]
 
 # There are channels
 type channel
   relations
-    # channels have a parent workspace
+    # Channels have a parent workspace
     define parent_workspace: [workspace]
-    # users can be writers on channels
+    # Users can be writers on channels
     define writer: [user,workspace#member]
-    # users can be viewers on channels, writers inherit any access viewers have
+    # Users can be viewers on channels, writers inherit any access viewers have
     define commenter: [user,workspace#member] or writer
 ```