Merge pull request #489 from Permify/next

diff --git a/docs/documentation/docs/api-overview.md b/docs/documentation/docs/api-overview.md
@@ -36,6 +36,7 @@ Permify exposes its APIs via both [gRPC](https://buf.build/permify/permify/docs/
 - Read relation tuples and filter them with [Read API](./api-overview/relationship/read-api.md)
 - Check access with [Check API](./api-overview/permission/check-api.md)
 - Check entities permissions with [Lookup Entity](./api-overview/permission/lookup-entity.md)
+- Check subject permissions with [Lookup Subject](./api-overview/permission/lookup-subject.md)
 - Delete relation tuples with [Delete Tuple](./api-overview/relationship/delete-relationships.md)
 - Expand schema actions with [Expand API](./api-overview/permission/expand-api.md)
 

diff --git a/docs/documentation/docs/api-overview/permission/check-api.md b/docs/documentation/docs/api-overview/permission/check-api.md
@@ -16,34 +16,34 @@ In this section we'll look at the resource based check request of Permify. You c
 
 **Path:** POST /v1/permissions/check
 
-| Required | Argument | Type | Default | Description |
-|----------|----------|---------|---------|-------------------------------------------------------------------------------------------|
-| [x]   | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field.
-| [ ]   | schema_version | string | 8 | Version of the schema |
-| [ ]   | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens) |
-| [x]   | entity | object | - | contains entity type and id of the entity. Example: repository:1”.
-| [x]   | permission | string | - | the action the user wants to perform on the resource |
-| [x]   | subject | object | - | the user or user set who wants to take the action. It contains type and id of the subject.  |
-| [ ]   | depth | integer | 8 | Timeout limit when if recursive database queries got in loop|
+| Required | Argument | Type | Default | Description                                                                                                                     |
+|----------|----------|---------|---------|---------------------------------------------------------------------------------------------------------------------------------|
+| [x]   | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field. |
+| [ ]   | schema_version | string | 8 | Version of the schema                                                                                                           |
+| [ ]   | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens).                            |
+| [x]   | entity | object | - | contains entity type and id of the entity. Example: repository:1.                                                               |
+| [x]   | permission | string | - | the action the user wants to perform on the resource                                                                            |
+| [x]   | subject | object | - | the user or user set who wants to take the action. It contains type and id of the subject.                                      |
+| [ ]   | depth | integer | 8 | Timeout limit when if recursive database queries got in loop                                                                    |
 
 
 <Tabs>
 <TabItem value="go" label="Go">
 
 ```go
-cr, err: = client.Permission.Check(context.Background(), & v1.PermissionCheckRequest {
+cr, err: = client.Permission.Check(context.Background(), &v1.PermissionCheckRequest {
     TenantId: "t1",
-    Metadata: & v1.PermissionCheckRequestMetadata {
+    Metadata: &v1.PermissionCheckRequestMetadata {
         SnapToken: ""
         SchemaVersion: ""
         Depth: 20,
     },
-    Entity: & v1.Entity {
+    Entity: &v1.Entity {
         Type: "repository",
         Id: "1",
     },
     Permission: "edit",
-    Subject: & v1.Subject {
+    Subject: &v1.Subject {
         Type: "user",
         Id: "1",
     },

diff --git a/docs/documentation/docs/api-overview/permission/expand-api.md b/docs/documentation/docs/api-overview/permission/expand-api.md
@@ -17,14 +17,13 @@ It is not designed to use as a check access. Expand request has a high latency w
 <TabItem value="go" label="Go">
 
 ```go
-cr, err: = client.Permission.Expand(context.Background(), & v1.PermissionExpandRequest {
+cr, err: = client.Permission.Expand(context.Background(), &v1.PermissionExpandRequest{
     TenantId: "t1",
-    Metadata: & v1.PermissionExpandRequestMetadata {
-        SnapToken: ""
-        SchemaVersion: ""
-        Depth: 20,
+    Metadata: &v1.PermissionExpandRequestMetadata{
+        SnapToken: "",
+        SchemaVersion: "",
     },
-    Entity: & v1.Entity {
+    Entity: &v1.Entity{
         Type: "repository",
         Id: "1",
     },
@@ -41,8 +40,7 @@ client.permission.expand({
   tenantId: "t1",
   metadata: {
         snapToken: "",
-        schemaVersion: "",
-        depth: 20
+        schemaVersion: ""
     },
     entity: {
         type: "repository",
@@ -213,7 +211,6 @@ We can use expand API to reason the access actions. If we want to reason access
       },
       "relation": "read"
     },
-    "exclusion": false,
     "expand": {
       "operation": "OPERATION_INTERSECTION",
       "children": [
@@ -225,7 +222,6 @@ We can use expand API to reason the access actions. If we want to reason access
             },
             "relation": "owner"
           },
-          "exclusion": false,
           "leaf": {
             "subjects": [
               {
@@ -244,7 +240,6 @@ We can use expand API to reason the access actions. If we want to reason access
             },
             "relation": "read"
           },
-          "exclusion": false,
           "expand": {
             "operation": "OPERATION_UNION",
             "children": [
@@ -256,7 +251,6 @@ We can use expand API to reason the access actions. If we want to reason access
                   },
                   "relation": "read"
                 },
-                "exclusion": false,
                 "expand": {
                   "operation": "OPERATION_UNION",
                   "children": [
@@ -268,7 +262,6 @@ We can use expand API to reason the access actions. If we want to reason access
                         },
                         "relation": "admin"
                       },
-                      "exclusion": false,
                       "leaf": {
                         "subjects": [
                           {
@@ -290,7 +283,6 @@ We can use expand API to reason the access actions. If we want to reason access
                   },
                   "relation": "read"
                 },
-                "exclusion": false,
                 "expand": {
                   "operation": "OPERATION_UNION",
                   "children": [
@@ -302,7 +294,6 @@ We can use expand API to reason the access actions. If we want to reason access
                         },
                         "relation": "member"
                       },
-                      "exclusion": false,
                       "leaf": {
                         "subjects": []
                       }

diff --git a/docs/documentation/docs/api-overview/permission/lookup-entity.md b/docs/documentation/docs/api-overview/permission/lookup-entity.md
@@ -22,10 +22,10 @@ In this endpoint you'll get directly the IDs' of the entities that are authorize
 
 | Required | Argument | Type | Default | Description |
 |----------|----------|---------|---------|-------------------------------------------------------------------------------------------|
-| [x]   | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field.
+| [x]   | tenant_id | string | - | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field.|
 | [ ]   | schema_version | string | 8 | Version of the schema |
 | [ ]   | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens) |
-| [x]   | entity_type | object | - | type of the  entity. Example: repository”.
+| [x]   | entity_type | object | - | type of the  entity. Example: repository”.|
 | [x]   | permission | string | - | the action the user wants to perform on the resource |
 | [x]   | subject | object | - | the user or user set who wants to take the action. It contains type and id of the subject.  |
 
@@ -104,23 +104,23 @@ The difference between this endpoint from direct Lookup Entity is response of th
 |----------|----------|---------|---------|-------------------------------------------------------------------------------------------|
 | [ ]   | schema_version | string | 8 | Version of the schema |
 | [ ]   | snap_token | string | - | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens) |
-| [x]   | entity_type | object | - | type of the  entity. Example: repository”.
+| [x]   | entity_type | object | - | type of the  entity. Example: repository”.|
 | [x]   | permission | string | - | the action the user wants to perform on the resource |
 | [x]   | subject | object | - | the user or user set who wants to take the action. It contains type and id of the subject.  |
 
 <Tabs>
 <TabItem value="go" label="Go">
 
 ```go
-str, err: = client.Permission.LookupEntityStream(context.Background(), & v1.PermissionLookupEntityRequest {
-    Metadata: & v1.PermissionLookupEntityRequestMetadata {
+str, err: = client.Permission.LookupEntityStream(context.Background(), &v1.PermissionLookupEntityRequest {
+    Metadata: &v1.PermissionLookupEntityRequestMetadata {
         SnapToken: "", 
         SchemaVersion: "" 
         Depth: 50,
     },
     EntityType: "document",
     Permission: "view",
-    Subject: & v1.Subject {
+    Subject: &v1.Subject {
         Type: "user",
         Id: "1",
     },

diff --git a/docs/documentation/docs/api-overview/permission/lookup-subject.md b/docs/documentation/docs/api-overview/permission/lookup-subject.md
@@ -0,0 +1,101 @@
+---
+title: Check Subjects' Permissions
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Check Subjects' Permissions
+
+Lookup Subject endpoint lets you ask questions in form of **“Which subjects can do action Y on entity:X?”**. As a response of this you’ll get a subject results in a format of string array.
+
+So, we provide 1 endpoint for subject filtering request,
+
+- [/v1/permissions/lookup-subject](#lookup-subject)
+
+## Lookup Subject
+
+In this endpoint you'll get directly the IDs' of the subjects that are authorized in an array.
+
+**POST** /v1/permissions/lookup-subject
+
+| Required | Argument            | Type      | Default | Description                                                                                                                      |
+|----------|---------------------|-----------|---------|----------------------------------------------------------------------------------------------------------------------------------|
+| [x]      | tenant_id           | string    | -       | identifier of the tenant, if you are not using multi-tenancy (have only one tenant) use pre-inserted tenant `t1` for this field. |
+| [ ]      | schema_version      | string    | -       | Version of the schema                                                                                                            |
+| [ ]      | snap_token          | string    | -       | the snap token to avoid stale cache, see more details on [Snap Tokens](../../reference/snap-tokens).                             |
+| [x]      | entity              | object    | -       | contains entity type and id of the entity. Example: repository:1                                                                 |
+| [x]      | permission          | string    | -       | the action the user wants to perform on the resource                                                                             |
+| [x]      | subject_reference   | object    | -       | the subject or subject reference who wants to take the action. It contains type and relation of the subject.                     |
+
+<Tabs>
+<TabItem value="go" label="Go">
+
+```go
+cr, err: = client.Permission.LookupSubject(context.Background(), &v1.PermissionLookupSubjectRequest {
+    TenantId: "t1",
+    Metadata: &v1.PermissionLookupSubjectRequestMetadata{
+        SnapToken: "",
+        SchemaVersion: "",
+    },
+    Entity: &v1.Entity{
+        Type: "document",
+        Id: "1",
+    },
+    Permission: "edit",
+    SubjectReference: &v1.RelationReference{
+        Type: "user",
+        Relation: "",
+    }
+})
+```
+
+</TabItem>
+<TabItem value="node" label="Node">
+
+```javascript
+client.permission.lookupSubject({
+    tenantId: "t1",
+    metadata: {
+        snapToken: "",
+        schemaVersion: ""
+    },
+    Entity: {
+        Type: "document",
+        Id: "1",
+    },
+    permission: "edit",
+    subject_reference: {
+        type: "user",
+        relation: ""
+    }
+}).then((response) => {
+    console.log(response.subject_ids)
+})
+```
+
+</TabItem>
+<TabItem value="curl" label="cURL">
+
+```curl
+curl --location --request POST 'localhost:3476/v1/tenants/{tenant_id}/permissions/lookup-subject' \
+--header 'Content-Type: application/json' \
+--data-raw '{
+  "metadata":{
+    "snap_token": "",
+    "schema_version": ""
+  },
+  "entity": {
+    type: "document",
+    id: "1'
+  },
+  "permission": "edit",
+  "subject_reference": {
+    "type": "user",
+    "relation": ""
+  }
+}'
+```
+
+</TabItem>
+</Tabs>
diff --git a/docs/documentation/docs/getting-started/modeling.md b/docs/documentation/docs/getting-started/modeling.md
@@ -169,7 +169,7 @@ Defining multiple relation types totally optional. The goal behind it to improve
 
 Actions describe what relations, or relation’s relation can do. Think of actions as permissions of the entity it belongs. So actions defines who can perform a specific action on a resource in which circumstances. So, the basic form of authorization check in Permify is **_Can the user U perform action X on a resource Y ?_**. 
 
-The Permify Schema supports `and`, `or`, `and not` and `or not` operators for defining actions. The keywords  **_action_** or **_permission_**  can be used with those operators to form rules for your authorization logic.
+The Permify Schema supports `and`, `or`and `not` operators for defining actions. The keywords  **_action_** or **_permission_**  can be used with those operators to form rules for your authorization logic.
 
 Lets get back to our github example and create some actions on repository entity,
 

diff --git a/docs/documentation/docs/getting-started/testing.md b/docs/documentation/docs/getting-started/testing.md
@@ -105,7 +105,12 @@ scenarios:
         assertions:
           push : ["1"]
           edit : []
-
+    subject_filters:
+      - subject_reference: "user"
+        entity: "repository:1"
+        assertions:
+          push : ["1", "43"]
+          edit : []
 ```
 
 ## Coverage Analysis

diff --git a/docs/documentation/docs/use-cases/simple-rbac.md b/docs/documentation/docs/use-cases/simple-rbac.md
@@ -22,7 +22,7 @@ entity organization {
     relation agent @user  
 
     //organization files access permissions
-    action view_files = admin or manager or (member and not agent)
+    action view_files = admin or manager or (member not agent)
     action edit_files = admin or manager
     action delete_file = admin 
 
@@ -72,7 +72,7 @@ Roles (relations) can be scoped with different kinds of entities. But for simpli
 
 Actions describe what relations, or relation’s relation can do, think of actions as entities' permissions. Actions defines who can perform a specific action in which circumstances.
 
-Permify Schema supports ***and***, ***or***, ***and not*** and ***or not*** operators to define actions. 
+Permify Schema supports ***and***, ***or*** and ***not*** operators to define actions. 
 
 #### organization actions
 
@@ -82,7 +82,7 @@ In our schema, we define several actions for controlling access permissions on o
 entity organization {
 
     //organization files access permissions
-    action view_files = admin or manager or (member and not agent)
+    action view_files = admin or manager or (member not agent)
     action edit_files = admin or manager
     action delete_file = admin 
 
@@ -99,7 +99,7 @@ let's take a look at some of the actions:
 - ``action edit_files = admin or manager`` 
 indicates that only the admin or manager has permission to edit files in the organization.
 
-- ``action view_files = admin or manager or (member and not agent)``
+- ``action view_files = admin or manager or (member not agent)``
 indicates that the admin, manager, or members (without having the agent role) can view organization files.
 
 

diff --git a/docs/documentation/docs/use-cases/user-groups.md b/docs/documentation/docs/use-cases/user-groups.md
@@ -123,7 +123,7 @@ entity project {
 
 Actions describe what relations, or relation’s relation can do, think of actions as entities' permissions. Actions defines who can perform a specific action in which circumstances.
 
-Permify Schema supports ***and***, ***or***, ***and not*** and ***or not*** operators to define actions. 
+Permify Schema supports ***and***, ***or*** and ***not*** operators to define actions. 
 
 #### team actions
 

diff --git a/docs/documentation/sidebars.js b/docs/documentation/sidebars.js
@@ -109,6 +109,7 @@ module.exports = {
 					items: [
 						"api-overview/permission/check-api",
 						"api-overview/permission/lookup-entity",
+						"api-overview/permission/lookup-subject",
 						"api-overview/permission/expand-api"
 					],
 				  },