chore: sync changes from updated openapi doc

.openapi-generator/FILES

@@ -78,6 +78,7 @@ docs/TupleToUserset.md
 docs/TypeDefinition.md
 docs/TypeName.md
 docs/TypedWildcard.md
+docs/UnauthenticatedResponse.md
 docs/UnprocessableContentErrorCode.md
 docs/UnprocessableContentMessageResponse.md
 docs/User.md
@@ -225,6 +226,7 @@ src/OpenFga.Sdk/Model/TupleToUserset.cs
 src/OpenFga.Sdk/Model/TypeDefinition.cs
 src/OpenFga.Sdk/Model/TypeName.cs
 src/OpenFga.Sdk/Model/TypedWildcard.cs
+src/OpenFga.Sdk/Model/UnauthenticatedResponse.cs
 src/OpenFga.Sdk/Model/UnprocessableContentErrorCode.cs
 src/OpenFga.Sdk/Model/UnprocessableContentMessageResponse.cs
 src/OpenFga.Sdk/Model/User.cs

README.md

@@ -833,7 +833,7 @@ namespace Example {
 | [**GetStore**](docs/OpenFgaApi.md#getstore) | **GET** /stores/{store_id} | Get a store |
 | [**ListObjects**](docs/OpenFgaApi.md#listobjects) | **POST** /stores/{store_id}/list-objects | List all objects of the given type that the user has a relation with |
 | [**ListStores**](docs/OpenFgaApi.md#liststores) | **GET** /stores | List all stores |
-| [**ListUsers**](docs/OpenFgaApi.md#listusers) | **POST** /stores/{store_id}/list-users | List all users of the given type that the object has a relation with |
+| [**ListUsers**](docs/OpenFgaApi.md#listusers) | **POST** /stores/{store_id}/list-users | [EXPERIMENTAL] List the users matching the provided filter who have a certain relation to a particular type. |
 | [**Read**](docs/OpenFgaApi.md#read) | **POST** /stores/{store_id}/read | Get tuples from the store that matches a query, without following userset rewrite rules |
 | [**ReadAssertions**](docs/OpenFgaApi.md#readassertions) | **GET** /stores/{store_id}/assertions/{authorization_model_id} | Read assertions for an authorization model ID |
 | [**ReadAuthorizationModel**](docs/OpenFgaApi.md#readauthorizationmodel) | **GET** /stores/{store_id}/authorization-models/{id} | Return a particular version of an authorization model |
@@ -907,6 +907,7 @@ namespace Example {
  - [Model.TypeDefinition](docs/TypeDefinition.md)
  - [Model.TypeName](docs/TypeName.md)
  - [Model.TypedWildcard](docs/TypedWildcard.md)
+ - [Model.UnauthenticatedResponse](docs/UnauthenticatedResponse.md)
  - [Model.UnprocessableContentErrorCode](docs/UnprocessableContentErrorCode.md)
  - [Model.UnprocessableContentMessageResponse](docs/UnprocessableContentMessageResponse.md)
  - [Model.User](docs/User.md)

docs/ListUsersRequest.md

@@ -7,7 +7,7 @@ Name | Type | Description | Notes
 **AuthorizationModelId** | **string** | | [optional] 
 **Object** | [**FgaObject**](FgaObject.md) | | 
 **Relation** | **string** | | 
-**UserFilters** | [**List<UserTypeFilter>**](UserTypeFilter.md) | | 
+**UserFilters** | [**List<UserTypeFilter>**](UserTypeFilter.md) | The type of results returned. Only accepts exactly one value. | 
 **ContextualTuples** | [**List<TupleKey>**](TupleKey.md) | | [optional] 
 **Context** | **Object** | Additional request context that will be used to evaluate any ABAC conditions encountered in the query evaluation. | [optional] 
 

docs/TypedWildcard.md

@@ -1,4 +1,5 @@
 # OpenFga.Sdk.Model.TypedWildcard
+Type bound public access. Normally represented using the `<type>:*` syntax `employee:*` represents every object of type `employee`, including those not currently present in the system See https://openfga.dev/docs/concepts#what-is-type-bound-public-access
 
 ## Properties
 

docs/UnauthenticatedResponse.md

@@ -0,0 +1,11 @@
+# OpenFga.Sdk.Model.UnauthenticatedResponse
+
+## Properties
+
+Name | Type | Description | Notes
+------------ | ------------- | ------------- | -------------
+**Code** | **ErrorCode** | | [optional] 
+**Message** | **string** | | [optional] 
+
+[[Back to Model list]](../README.md#models) [[Back to API list]](../README.md#api-endpoints) [[Back to README]](../README.md)
+

docs/User.md

@@ -1,4 +1,5 @@
 # OpenFga.Sdk.Model.User
+User. Represents any possible value for a user (subject or principal). Can be a: - Specific user object e.g.: 'user:will', 'folder:marketing', 'org:contoso', ...) - Specific userset (e.g. 'group:engineering#member') - Public-typed wildcard (e.g. 'user:*') See https://openfga.dev/docs/concepts#what-is-a-user
 
 ## Properties
 

docs/UsersetUser.md

@@ -1,4 +1,5 @@
 # OpenFga.Sdk.Model.UsersetUser
+Userset. A set or group of users, represented in the `<type>:<id>#<relation>` format `group:fga#member` represents all members of group FGA, not to be confused by `group:fga` which represents the group itself as a specific object. See: https://openfga.dev/docs/modeling/building-blocks/usersets#what-is-a-userset
 
 ## Properties
 

src/OpenFga.Sdk.Test/Api/OpenFgaApiTests.cs

@@ -1,7 +1,7 @@
 //
 // OpenFGA/.NET SDK for OpenFGA
 //
-// API version: 0.1
+// API version: 1.x
 // Website: https://openfga.dev
 // Documentation: https://openfga.dev/docs
 // Support: https://openfga.dev/community

src/OpenFga.Sdk.Test/Client/OpenFgaClientTests.cs

@@ -1,7 +1,7 @@
 //
 // OpenFGA/.NET SDK for OpenFGA
 //
-// API version: 0.1
+// API version: 1.x
 // Website: https://openfga.dev
 // Documentation: https://openfga.dev/docs
 // Support: https://openfga.dev/community

src/OpenFga.Sdk.Test/Models/ModelTests.cs

@@ -1,7 +1,7 @@
 //
 // OpenFGA/.NET SDK for OpenFGA
 //
-// API version: 0.1
+// API version: 1.x
 // Website: https://openfga.dev
 // Documentation: https://openfga.dev/docs
 // Support: https://openfga.dev/community

src/OpenFga.Sdk/Api/OpenFgaApi.cs

@@ -1,7 +1,7 @@
 //
 // OpenFGA/.NET SDK for OpenFGA
 //
-// API version: 0.1
+// API version: 1.x
 // Website: https://openfga.dev
 // Documentation: https://openfga.dev/docs
 // Support: https://openfga.dev/community
@@ -36,7 +36,7 @@ public OpenFgaApi(
  }
 
  /// <summary>
- /// Check whether a user is authorized to access an object The Check API returns whether a given user has a relationship with a given object in a given store. The &#x60;user&#x60; field of the request can be a specific target, such as &#x60;user:anne&#x60;, or a userset (set of users) such as &#x60;group:marketing#member&#x60; or a type-bound public access &#x60;user:*&#x60;. To arrive at a result, the API uses: an authorization model, explicit tuples written through the Write API, contextual tuples present in the request, and implicit tuples that exist by virtue of applying set theory (such as &#x60;document:2021-budget#viewer@document:2021-budget#viewer&#x60;; the set of users who are viewers of &#x60;document:2021-budget&#x60; are the set of users who are the viewers of &#x60;document:2021-budget&#x60;). A &#x60;contextual_tuples&#x60; object may also be included in the body of the request. This object contains one field &#x60;tuple_keys&#x60;, which is an array of tuple keys. Each of these tuples may have an associated &#x60;condition&#x60;. You may also provide an &#x60;authorization_model_id&#x60; in the body. This will be used to assert that the input &#x60;tuple_key&#x60; is valid for the model specified. If not specified, the assertion will be made against the latest authorization model ID. It is strongly recommended to specify authorization model id for better performance. You may also provide a &#x60;context&#x60; object that will be used to evaluate the conditioned tuples in the system. It is strongly recommended to provide a value for all the input parameters of all the conditions, to ensure that all tuples be evaluated correctly. The response will return whether the relationship exists in the field &#x60;allowed&#x60;. Some exceptions apply, but in general, if a Check API responds with &#x60;{allowed: true}&#x60;, then you can expect the equivalent ListObjects query to return the object, and viceversa. For example, if &#x60;Check(user:anne, reader, document:2021-budget)&#x60; responds with &#x60;{allowed: true}&#x60;, then &#x60;ListObjects(user:anne, reader, document)&#x60; may include &#x60;document:2021-budget&#x60; in the response. ## Examples ### Querying with contextual tuples In order to check if user &#x60;user:anne&#x60; of type &#x60;user&#x60; has a &#x60;reader&#x60; relationship with object &#x60;document:2021-budget&#x60; given the following contextual tuple &#x60;&#x60;&#x60;json { \&quot;user\&quot;: \&quot;user:anne\&quot;, \&quot;relation\&quot;: \&quot;member\&quot;, \&quot;object\&quot;: \&quot;time_slot:office_hours\&quot; } &#x60;&#x60;&#x60; the Check API can be used with the following request body: &#x60;&#x60;&#x60;json { \&quot;tuple_key\&quot;: { \&quot;user\&quot;: \&quot;user:anne\&quot;, \&quot;relation\&quot;: \&quot;reader\&quot;, \&quot;object\&quot;: \&quot;document:2021-budget\&quot; }, \&quot;contextual_tuples\&quot;: { \&quot;tuple_keys\&quot;: [ { \&quot;user\&quot;: \&quot;user:anne\&quot;, \&quot;relation\&quot;: \&quot;member\&quot;, \&quot;object\&quot;: \&quot;time_slot:office_hours\&quot; } ] }, \&quot;authorization_model_id\&quot;: \&quot;01G50QVV17PECNVAHX1GG4Y5NC\&quot; } &#x60;&#x60;&#x60; ### Querying usersets Some Checks will always return &#x60;true&#x60;, even without any tuples. For example, for the following authorization model &#x60;&#x60;&#x60;python model schema 1.1 type user type document relations define reader: [user] &#x60;&#x60;&#x60; the following query &#x60;&#x60;&#x60;json { \&quot;tuple_key\&quot;: { \&quot;user\&quot;: \&quot;document:2021-budget#reader\&quot;, \&quot;relation\&quot;: \&quot;reader\&quot;, \&quot;object\&quot;: \&quot;document:2021-budget\&quot; } } &#x60;&#x60;&#x60; will always return &#x60;{ \&quot;allowed\&quot;: true }&#x60;. This is because usersets are self-defining: the userset &#x60;document:2021-budget#reader&#x60; will always have the &#x60;reader&#x60; relation with &#x60;document:2021-budget&#x60;. ### Querying usersets with exclusion in the model A Check for a userset can yield results that must be treated carefully if the model involves exclusion. For example, for the following authorization model &#x60;&#x60;&#x60;python model schema 1.1 type user type group relations define member: [user] type document relations define blocked: [user] define reader: [group#member] but not blocked &#x60;&#x60;&#x60; the following query &#x60;&#x60;&#x60;json { \&quot;tuple_key\&quot;: { \&quot;user\&quot;: \&quot;group:finance#member\&quot;, \&quot;relation\&quot;: \&quot;reader\&quot;, \&quot;object\&quot;: \&quot;document:2021-budget\&quot; }, \&quot;contextual_tuples\&quot;: { \&quot;tuple_keys\&quot;: [ { \&quot;user\&quot;: \&quot;user:anne\&quot;, \&quot;relation\&quot;: \&quot;member\&quot;, \&quot;object\&quot;: \&quot;group:finance\&quot; }, { \&quot;user\&quot;: \&quot;group:finance#member\&quot;, \&quot;relation\&quot;: \&quot;reader\&quot;, \&quot;object\&quot;: \&quot;document:2021-budget\&quot; }, { \&quot;user\&quot;: \&quot;user:anne\&quot;, \&quot;relation\&quot;: \&quot;blocked\&quot;, \&quot;object\&quot;: \&quot;document:2021-budget\&quot; } ] }, } &#x60;&#x60;&#x60; will return &#x60;{ \&quot;allowed\&quot;: true }&#x60;, even though a specific user of the userset &#x60;group:finance#member&#x60; does not have the &#x60;reader&#x60; relationship with the given object. 
+ /// Check whether a user is authorized to access an object The Check API returns whether a given user has a relationship with a given object in a given store. The &#x60;user&#x60; field of the request can be a specific target, such as &#x60;user:anne&#x60;, or a userset (set of users) such as &#x60;group:marketing#member&#x60; or a type-bound public access &#x60;user:*&#x60;. To arrive at a result, the API uses: an authorization model, explicit tuples written through the Write API, contextual tuples present in the request, and implicit tuples that exist by virtue of applying set theory (such as &#x60;document:2021-budget#viewer@document:2021-budget#viewer&#x60;; the set of users who are viewers of &#x60;document:2021-budget&#x60; are the set of users who are the viewers of &#x60;document:2021-budget&#x60;). A &#x60;contextual_tuples&#x60; object may also be included in the body of the request. This object contains one field &#x60;tuple_keys&#x60;, which is an array of tuple keys. Each of these tuples may have an associated &#x60;condition&#x60;. You may also provide an &#x60;authorization_model_id&#x60; in the body. This will be used to assert that the input &#x60;tuple_key&#x60; is valid for the model specified. If not specified, the assertion will be made against the latest authorization model ID. It is strongly recommended to specify authorization model id for better performance. You may also provide a &#x60;context&#x60; object that will be used to evaluate the conditioned tuples in the system. It is strongly recommended to provide a value for all the input parameters of all the conditions, to ensure that all tuples be evaluated correctly. The response will return whether the relationship exists in the field &#x60;allowed&#x60;. Some exceptions apply, but in general, if a Check API responds with &#x60;{allowed: true}&#x60;, then you can expect the equivalent ListObjects query to return the object, and viceversa. For example, if &#x60;Check(user:anne, reader, document:2021-budget)&#x60; responds with &#x60;{allowed: true}&#x60;, then &#x60;ListObjects(user:anne, reader, document)&#x60; may include &#x60;document:2021-budget&#x60; in the response. ## Examples ### Querying with contextual tuples In order to check if user &#x60;user:anne&#x60; of type &#x60;user&#x60; has a &#x60;reader&#x60; relationship with object &#x60;document:2021-budget&#x60; given the following contextual tuple &#x60;&#x60;&#x60;json { \&quot;user\&quot;: \&quot;user:anne\&quot;, \&quot;relation\&quot;: \&quot;member\&quot;, \&quot;object\&quot;: \&quot;time_slot:office_hours\&quot; } &#x60;&#x60;&#x60; the Check API can be used with the following request body: &#x60;&#x60;&#x60;json { \&quot;tuple_key\&quot;: { \&quot;user\&quot;: \&quot;user:anne\&quot;, \&quot;relation\&quot;: \&quot;reader\&quot;, \&quot;object\&quot;: \&quot;document:2021-budget\&quot; }, \&quot;contextual_tuples\&quot;: { \&quot;tuple_keys\&quot;: [ { \&quot;user\&quot;: \&quot;user:anne\&quot;, \&quot;relation\&quot;: \&quot;member\&quot;, \&quot;object\&quot;: \&quot;time_slot:office_hours\&quot; } ] }, \&quot;authorization_model_id\&quot;: \&quot;01G50QVV17PECNVAHX1GG4Y5NC\&quot; } &#x60;&#x60;&#x60; ### Querying usersets Some Checks will always return &#x60;true&#x60;, even without any tuples. For example, for the following authorization model &#x60;&#x60;&#x60;python model schema 1.1 type user type document relations define reader: [user] &#x60;&#x60;&#x60; the following query &#x60;&#x60;&#x60;json { \&quot;tuple_key\&quot;: { \&quot;user\&quot;: \&quot;document:2021-budget#reader\&quot;, \&quot;relation\&quot;: \&quot;reader\&quot;, \&quot;object\&quot;: \&quot;document:2021-budget\&quot; } } &#x60;&#x60;&#x60; will always return &#x60;{ \&quot;allowed\&quot;: true }&#x60;. This is because usersets are self-defining: the userset &#x60;document:2021-budget#reader&#x60; will always have the &#x60;reader&#x60; relation with &#x60;document:2021-budget&#x60;. ### Querying usersets with difference in the model A Check for a userset can yield results that must be treated carefully if the model involves difference. For example, for the following authorization model &#x60;&#x60;&#x60;python model schema 1.1 type user type group relations define member: [user] type document relations define blocked: [user] define reader: [group#member] but not blocked &#x60;&#x60;&#x60; the following query &#x60;&#x60;&#x60;json { \&quot;tuple_key\&quot;: { \&quot;user\&quot;: \&quot;group:finance#member\&quot;, \&quot;relation\&quot;: \&quot;reader\&quot;, \&quot;object\&quot;: \&quot;document:2021-budget\&quot; }, \&quot;contextual_tuples\&quot;: { \&quot;tuple_keys\&quot;: [ { \&quot;user\&quot;: \&quot;user:anne\&quot;, \&quot;relation\&quot;: \&quot;member\&quot;, \&quot;object\&quot;: \&quot;group:finance\&quot; }, { \&quot;user\&quot;: \&quot;group:finance#member\&quot;, \&quot;relation\&quot;: \&quot;reader\&quot;, \&quot;object\&quot;: \&quot;document:2021-budget\&quot; }, { \&quot;user\&quot;: \&quot;user:anne\&quot;, \&quot;relation\&quot;: \&quot;blocked\&quot;, \&quot;object\&quot;: \&quot;document:2021-budget\&quot; } ] }, } &#x60;&#x60;&#x60; will return &#x60;{ \&quot;allowed\&quot;: true }&#x60;, even though a specific user of the userset &#x60;group:finance#member&#x60; does not have the &#x60;reader&#x60; relationship with the given object. 
  /// </summary>
  /// <exception cref="ApiException">Thrown when fails to make API call</exception>
  /// <param name="storeId"></param>
@@ -248,7 +248,7 @@ public async Task<ListObjectsResponse> ListObjects(string storeId, ListObjectsRe
  }
 
  /// <summary>
- /// List all users of the given type that the object has a relation with 
+ /// [EXPERIMENTAL] List the users matching the provided filter who have a certain relation to a particular type. The ListUsers API returns a list of all the users of a specific type that have a relation to a given object. This API is available in an experimental capacity and can be enabled with the &#x60;- -experimentals enable-list-users&#x60; flag. To arrive at a result, the API uses: an authorization model, explicit tuples written through the Write API, contextual tuples present in the request, and implicit tuples that exist by virtue of applying set theory (such as &#x60;document:2021-budget#viewer@document:2021-budget#viewer&#x60;; the set of users who are viewers of &#x60;document:2021-budget&#x60; are the set of users who are the viewers of &#x60;document:2021-budget&#x60;). An &#x60;authorization_model_id&#x60; may be specified in the body. If it is not specified, the latest authorization model ID will be used. It is strongly recommended to specify authorization model id for better performance. You may also specify &#x60;contextual_tuples&#x60; that will be treated as regular tuples. Each of these tuples may have an associated &#x60;condition&#x60;. You may also provide a &#x60;context&#x60; object that will be used to evaluate the conditioned tuples in the system. It is strongly recommended to provide a value for all the input parameters of all the conditions, to ensure that all tuples be evaluated correctly. The response will contain the related users in an array in the \&quot;users\&quot; field of the response. These results may include specific objects, usersets or type-bound public access. Each of these types of results is encoded in its own type and not represented as a string.In certain cases of negation via the &#x60;but not&#x60; operator, some results are marked as excluded from the main set of results. These exclusions are returned in the &#x60;excluded_users&#x60; property and should be handled appropriately at the point of implementation.The number of users in the response array will be limited by the execution timeout specified in the flag OPENFGA_LIST_USERS_DEADLINE and by the upper bound specified in the flag OPENFGA_LIST_USERS_MAX_RESULTS, whichever is hit first. The returned users will not be sorted, and therefore two identical calls may yield different sets of users.
  /// </summary>
  /// <exception cref="ApiException">Thrown when fails to make API call</exception>
  /// <param name="storeId"></param>

src/OpenFga.Sdk/ApiClient/ApiClient.cs

@@ -1,7 +1,7 @@
 //
 // OpenFGA/.NET SDK for OpenFGA
 //
-// API version: 0.1
+// API version: 1.x
 // Website: https://openfga.dev
 // Documentation: https://openfga.dev/docs
 // Support: https://openfga.dev/community

src/OpenFga.Sdk/ApiClient/BaseClient.cs

@@ -1,7 +1,7 @@
 //
 // OpenFGA/.NET SDK for OpenFGA
 //
-// API version: 0.1
+// API version: 1.x
 // Website: https://openfga.dev
 // Documentation: https://openfga.dev/docs
 // Support: https://openfga.dev/community

src/OpenFga.Sdk/ApiClient/OAuth2Client.cs

@@ -1,7 +1,7 @@
 //
 // OpenFGA/.NET SDK for OpenFGA
 //
-// API version: 0.1
+// API version: 1.x
 // Website: https://openfga.dev
 // Documentation: https://openfga.dev/docs
 // Support: https://openfga.dev/community

src/OpenFga.Sdk/ApiClient/RequestBuilder.cs

@@ -1,7 +1,7 @@
 //
 // OpenFGA/.NET SDK for OpenFGA
 //
-// API version: 0.1
+// API version: 1.x
 // Website: https://openfga.dev
 // Documentation: https://openfga.dev/docs
 // Support: https://openfga.dev/community