@tapis/tapis-typescript-sk 0.0.2 → 0.0.3

package/dist/apis/RoleApi.d.ts

@@ -1,8 +1,8 @@
 /**
  * Tapis Security API
- * The Tapis Security API provides access to the Tapis Security Kernel authorization and secrets facilities.
+ * The Tapis Security API provides for management of Security Kernel (SK) role-based authorization and secrets resources.
  *
- * The version of the OpenAPI document: 0.1
+ * The version of the OpenAPI document: 1.8.2
  * Contact: cicsupport@tacc.utexas.edu
  *
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -10,196 +10,219 @@
  * Do not edit the class manually.
  */
 import * as runtime from '../runtime';
-import { ReqAddChildRole, ReqAddRolePermission, ReqCreateRole, ReqPreviewPathPrefix, ReqRemoveChildRole, ReqRemoveRolePermission, ReqReplacePathPrefix, ReqUpdateRoleDescription, ReqUpdateRoleName, ReqUpdateRoleOwner, RespBasic, RespChangeCount, RespName, RespNameArray, RespPathPrefixes, RespResourceUrl, RespRole } from '../models';
+import type { ReqAddChildRole, ReqAddRolePermission, ReqCreateRole, ReqPreviewPathPrefix, ReqRemoveChildRole, ReqRemovePermissionFromAllRoles, ReqRemoveRolePermission, ReqReplacePathPrefix, ReqRolePermits, ReqUpdateRoleDescription, ReqUpdateRoleName, ReqUpdateRoleOwner, RespAuthorized, RespBasic, RespChangeCount, RespName, RespNameArray, RespPathPrefixes, RespResourceUrl, RespRole, RoleTypeEnum } from '../models/index';
 export interface AddChildRoleRequest {
     reqAddChildRole: ReqAddChildRole;
-    pretty?: boolean;
 }
 export interface AddRolePermissionRequest {
     reqAddRolePermission: ReqAddRolePermission;
-    pretty?: boolean;
 }
 export interface CreateRoleRequest {
     reqCreateRole: ReqCreateRole;
-    pretty?: boolean;
 }
 export interface DeleteRoleByNameRequest {
     roleName: string;
     tenant?: string;
-    pretty?: boolean;
+    roleType?: RoleTypeEnum;
 }
 export interface GetDefaultUserRoleRequest {
     user: string;
-    pretty?: boolean;
 }
 export interface GetRoleByNameRequest {
     roleName: string;
     tenant?: string;
-    pretty?: boolean;
+    roleType?: RoleTypeEnum;
 }
 export interface GetRoleNamesRequest {
     tenant?: string;
-    pretty?: boolean;
+    roleType?: RoleTypeEnum;
 }
 export interface GetRolePermissionsRequest {
     roleName: string;
     tenant?: string;
     immediate?: boolean;
-    pretty?: boolean;
 }
 export interface PreviewPathPrefixRequest {
     reqPreviewPathPrefix: ReqPreviewPathPrefix;
-    pretty?: boolean;
 }
 export interface RemoveChildRoleRequest {
     reqRemoveChildRole: ReqRemoveChildRole;
-    pretty?: boolean;
+}
+export interface RemovePathPermissionFromAllRolesRequest {
+    reqRemovePermissionFromAllRoles: ReqRemovePermissionFromAllRoles;
+}
+export interface RemovePermissionFromAllRolesRequest {
+    reqRemovePermissionFromAllRoles: ReqRemovePermissionFromAllRoles;
 }
 export interface RemoveRolePermissionRequest {
     reqRemoveRolePermission: ReqRemoveRolePermission;
-    pretty?: boolean;
 }
 export interface ReplacePathPrefixRequest {
     reqReplacePathPrefix: ReqReplacePathPrefix;
-    pretty?: boolean;
+}
+export interface RolePermitsRequest {
+    roleName: string;
+    reqRolePermits: ReqRolePermits;
+    immediate?: boolean;
 }
 export interface UpdateRoleDescriptionRequest {
     roleName: string;
     reqUpdateRoleDescription: ReqUpdateRoleDescription;
-    pretty?: boolean;
 }
 export interface UpdateRoleNameRequest {
     roleName: string;
     reqUpdateRoleName: ReqUpdateRoleName;
-    pretty?: boolean;
 }
 export interface UpdateRoleOwnerRequest {
     roleName: string;
     reqUpdateRoleOwner: ReqUpdateRoleOwner;
-    pretty?: boolean;
 }
 /**
  *
  */
 export declare class RoleApi extends runtime.BaseAPI {
     /**
-     * Add a child role to another role using a request body.  If the child already exists, then the request has no effect and the change count returned is zero. Otherwise, the child is added and the change count is one.  The user@tenant identity specified in JWT is authorized to make this request only if that user is an administrator or if the user owns both the parent and child roles.
+     * Add a child role to another role using a request body. If the child already exists, then the request has no effect and the change count returned is zero. Otherwise, the child is added and the change count is one. Supported only for roles of type *USER*.  The user@tenant identity specified in JWT is authorized to make this request only if that user is an administrator or if the user owns both the parent and child roles.
+     */
+    addChildRoleRaw(requestParameters: AddChildRoleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespChangeCount>>;
+    /**
+     * Add a child role to another role using a request body. If the child already exists, then the request has no effect and the change count returned is zero. Otherwise, the child is added and the change count is one. Supported only for roles of type *USER*.  The user@tenant identity specified in JWT is authorized to make this request only if that user is an administrator or if the user owns both the parent and child roles.
+     */
+    addChildRole(requestParameters: AddChildRoleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespChangeCount>;
+    /**
+     * Add a permission to an existing role using a request body. If the permission already exists, then the request has no effect and the change count returned is zero. Otherwise, the permission is added and the change count is one.  Permissions are case-sensitive strings that follow the format defined by Apache Shiro (https://shiro.apache.org/permissions.html). This format defines any number of colon-separated (:) parts, with the possible use of asterisks (*) as wildcards and commas (,) as aggregators. Here are two example permission strings:      system:MyTenant:read,write:system1     system:MyTenant:create,read,write,delete:*  See the Shiro documentation for further details. Note that the three reserved characters, [: * ,], cannot appear in the text of any part. It\'s the application\'s responsibility to escape those characters in a manner that is safe in the application\'s domain.  ### Extended Permissions Tapis extends Shiro permission checking with *path semantics*. Path semantics allows the last part of pre-configured permissions to be treated as hierarchical path names, such as the paths used in POSIX file systems. Currently, only permissions that start with *files:* have their last (5th) component configured with path semantics.  Path semantics treat the extended permission part as the root of the subtree to which the permission is applied recursively. Grantees assigned the permission will have the permission on the path itself and on all its children.  As an example, consider a role that\'s assigned the following permission:      files:iplantc.org:read:stampede2:/home/bud  Users granted the role have read permission on the following file system resources on stampede2:      /home/bud     /home/bud/     /home/bud/myfile     /home/bud/mydir/myfile  Those users, however, will not have access to /home.  When an extended permission part ends with a slash, such as /home/bud/, then that part is interpreted as a directory or, more generally, some type of container. In such cases, the permission applies to the children of the path and to the path as written with a slash. For instance, for the file permission path /home/bud/, the permission allows access to /home/bud/ and /home/bud/myfile, but not to /home/bud.  When an extended permission part does not end with a slash, such as /home/bud, then the permission applies to the children of the path and to the path written with or without a trailing slash. For instance, for the file permission path /home/bud, the permission allows access to /home/bud, /home/bud/ and /home/bud/myfile.  In the previous examples, we assumed /home/bud was a directory. If /home/bud is a file (or more generally a leaf), then specifying the permission path /home/bud/ will not work as intended. Permissions with paths that have trailing slashes should only be used for directories, and they require a trailing slash whenever refering to the root directory. Permissions that don\'t have a trailing slash can represent directories or files, and thus are more general.  Extended permission checking avoids *false capture*. Whether a path has a trailing slash or not, permission checking will not capture similarly named sibling paths. For example, using the file permission path /home/bud, grantees are allowed access to /home/bud and all its children (if it\'s a directory), but not to the file /home/buddy.txt nor the directory /home/bud2.  For roles of type USER the request is authorized only if the requestor is the role owner, a tenant administrator or a site administrator. For roles of type TENANT_ADMIN the requestor must a tenant or site administrator. For roles of type RESTRICTED_SVC the requestor must a site administrator.
+     */
+    addRolePermissionRaw(requestParameters: AddRolePermissionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespChangeCount>>;
+    /**
+     * Add a permission to an existing role using a request body. If the permission already exists, then the request has no effect and the change count returned is zero. Otherwise, the permission is added and the change count is one.  Permissions are case-sensitive strings that follow the format defined by Apache Shiro (https://shiro.apache.org/permissions.html). This format defines any number of colon-separated (:) parts, with the possible use of asterisks (*) as wildcards and commas (,) as aggregators. Here are two example permission strings:      system:MyTenant:read,write:system1     system:MyTenant:create,read,write,delete:*  See the Shiro documentation for further details. Note that the three reserved characters, [: * ,], cannot appear in the text of any part. It\'s the application\'s responsibility to escape those characters in a manner that is safe in the application\'s domain.  ### Extended Permissions Tapis extends Shiro permission checking with *path semantics*. Path semantics allows the last part of pre-configured permissions to be treated as hierarchical path names, such as the paths used in POSIX file systems. Currently, only permissions that start with *files:* have their last (5th) component configured with path semantics.  Path semantics treat the extended permission part as the root of the subtree to which the permission is applied recursively. Grantees assigned the permission will have the permission on the path itself and on all its children.  As an example, consider a role that\'s assigned the following permission:      files:iplantc.org:read:stampede2:/home/bud  Users granted the role have read permission on the following file system resources on stampede2:      /home/bud     /home/bud/     /home/bud/myfile     /home/bud/mydir/myfile  Those users, however, will not have access to /home.  When an extended permission part ends with a slash, such as /home/bud/, then that part is interpreted as a directory or, more generally, some type of container. In such cases, the permission applies to the children of the path and to the path as written with a slash. For instance, for the file permission path /home/bud/, the permission allows access to /home/bud/ and /home/bud/myfile, but not to /home/bud.  When an extended permission part does not end with a slash, such as /home/bud, then the permission applies to the children of the path and to the path written with or without a trailing slash. For instance, for the file permission path /home/bud, the permission allows access to /home/bud, /home/bud/ and /home/bud/myfile.  In the previous examples, we assumed /home/bud was a directory. If /home/bud is a file (or more generally a leaf), then specifying the permission path /home/bud/ will not work as intended. Permissions with paths that have trailing slashes should only be used for directories, and they require a trailing slash whenever refering to the root directory. Permissions that don\'t have a trailing slash can represent directories or files, and thus are more general.  Extended permission checking avoids *false capture*. Whether a path has a trailing slash or not, permission checking will not capture similarly named sibling paths. For example, using the file permission path /home/bud, grantees are allowed access to /home/bud and all its children (if it\'s a directory), but not to the file /home/buddy.txt nor the directory /home/bud2.  For roles of type USER the request is authorized only if the requestor is the role owner, a tenant administrator or a site administrator. For roles of type TENANT_ADMIN the requestor must a tenant or site administrator. For roles of type RESTRICTED_SVC the requestor must a site administrator.
+     */
+    addRolePermission(requestParameters: AddRolePermissionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespChangeCount>;
+    /**
+     * Create a role using a request body. Role names are case sensitive, alpha-numeric strings that can also contain underscores. Role names must start with an alphbetic character and can be no more than 58 characters in length. The desciption can be no more than 2048 characters long. If the role already exists, this request has no effect.  For the request to be authorized, the requestor must be either an administrator or a service allowed to perform updates in the new role\'s tenant.
+     */
+    createRoleRaw(requestParameters: CreateRoleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespResourceUrl>>;
+    /**
+     * Create a role using a request body. Role names are case sensitive, alpha-numeric strings that can also contain underscores. Role names must start with an alphbetic character and can be no more than 58 characters in length. The desciption can be no more than 2048 characters long. If the role already exists, this request has no effect.  For the request to be authorized, the requestor must be either an administrator or a service allowed to perform updates in the new role\'s tenant.
+     */
+    createRole(requestParameters: CreateRoleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespResourceUrl>;
+    /**
+     * Delete the named role. A valid tenant and user must be specified as query parameters.  For roles of type USER the request is authorized only if the requestor is the role owner, a tenant administrator or a site administrator. For roles of type TENANT_ADMIN the requestor must a tenant or site administrator. For roles of type RESTRICTED_SVC the requestor must a site administrator.
      */
-    addChildRoleRaw(requestParameters: AddChildRoleRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespChangeCount>>;
+    deleteRoleByNameRaw(requestParameters: DeleteRoleByNameRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespChangeCount>>;
     /**
-     * Add a child role to another role using a request body.  If the child already exists, then the request has no effect and the change count returned is zero. Otherwise, the child is added and the change count is one.  The user@tenant identity specified in JWT is authorized to make this request only if that user is an administrator or if the user owns both the parent and child roles.
+     * Delete the named role. A valid tenant and user must be specified as query parameters.  For roles of type USER the request is authorized only if the requestor is the role owner, a tenant administrator or a site administrator. For roles of type TENANT_ADMIN the requestor must a tenant or site administrator. For roles of type RESTRICTED_SVC the requestor must a site administrator.
      */
-    addChildRole(requestParameters: AddChildRoleRequest, initOverrides?: RequestInit): Promise<RespChangeCount>;
+    deleteRoleByName(requestParameters: DeleteRoleByNameRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespChangeCount>;
     /**
-     * Add a permission to an existing role using a request body.  If the permission already exists, then the request has no effect and the change count returned is zero. Otherwise, the permission is added and the change count is one.  Permissions are case-sensitive strings that follow the format defined by Apache Shiro (https://shiro.apache.org/permissions.html).  This format defines any number of colon-separated (:) parts, with the possible use of asterisks (*) as wildcards and commas (,) as aggregators.  Here are two example permission strings:      system:MyTenant:read,write:system1     system:MyTenant:create,read,write,delete:*  See the Shiro documentation for further details.  Note that the three reserved characters, [: * ,], cannot appear in the text of any part.  It\'s the application\'s responsibility to escape those characters in a manner that is safe in the application\'s domain.  This request is authorized only if the authenticated user is either the role owner or an administrator.
+     * Get a user\'s default role. The default role is implicitly created by the system when needed if it doesn\'t  already exist. No authorization required.  A user\'s default role is constructed by prepending \'$$\' to the user\'s name. This implies the maximum length of a user name is 58 since role names are limited to 60 characters.
      */
-    addRolePermissionRaw(requestParameters: AddRolePermissionRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespChangeCount>>;
+    getDefaultUserRoleRaw(requestParameters: GetDefaultUserRoleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespName>>;
     /**
-     * Add a permission to an existing role using a request body.  If the permission already exists, then the request has no effect and the change count returned is zero. Otherwise, the permission is added and the change count is one.  Permissions are case-sensitive strings that follow the format defined by Apache Shiro (https://shiro.apache.org/permissions.html).  This format defines any number of colon-separated (:) parts, with the possible use of asterisks (*) as wildcards and commas (,) as aggregators.  Here are two example permission strings:      system:MyTenant:read,write:system1     system:MyTenant:create,read,write,delete:*  See the Shiro documentation for further details.  Note that the three reserved characters, [: * ,], cannot appear in the text of any part.  It\'s the application\'s responsibility to escape those characters in a manner that is safe in the application\'s domain.  This request is authorized only if the authenticated user is either the role owner or an administrator.
+     * Get a user\'s default role. The default role is implicitly created by the system when needed if it doesn\'t  already exist. No authorization required.  A user\'s default role is constructed by prepending \'$$\' to the user\'s name. This implies the maximum length of a user name is 58 since role names are limited to 60 characters.
      */
-    addRolePermission(requestParameters: AddRolePermissionRequest, initOverrides?: RequestInit): Promise<RespChangeCount>;
+    getDefaultUserRole(requestParameters: GetDefaultUserRoleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespName>;
     /**
-     * Create a role using a request body.  Role names are case sensitive, alpha-numeric strings that can also contain underscores.  Role names must start with an alphbetic character and can be no more than 58 characters in length.  The desciption can be no more than 2048 characters long.  If the role already exists, this request has no effect.  For the request to be authorized, the requestor must be either an administrator or a service allowed to perform updates in the new role\'s tenant.
+     * Get the named role\'s definition. A valid tenant must be specified as a query parameter. This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
      */
-    createRoleRaw(requestParameters: CreateRoleRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespResourceUrl>>;
+    getRoleByNameRaw(requestParameters: GetRoleByNameRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespRole>>;
     /**
-     * Create a role using a request body.  Role names are case sensitive, alpha-numeric strings that can also contain underscores.  Role names must start with an alphbetic character and can be no more than 58 characters in length.  The desciption can be no more than 2048 characters long.  If the role already exists, this request has no effect.  For the request to be authorized, the requestor must be either an administrator or a service allowed to perform updates in the new role\'s tenant.
+     * Get the named role\'s definition. A valid tenant must be specified as a query parameter. This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
      */
-    createRole(requestParameters: CreateRoleRequest, initOverrides?: RequestInit): Promise<RespResourceUrl>;
+    getRoleByName(requestParameters: GetRoleByNameRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespRole>;
     /**
-     * Delete the named role. A valid tenant and user must be specified as query parameters.  This request is authorized only if the authenticated user is either the role owner or an administrator.
+     * Get the names of all roles in the tenant in alphabetic order. Future enhancements will include search filtering.  A valid tenant must be specified as a query parameter. This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
      */
-    deleteRoleByNameRaw(requestParameters: DeleteRoleByNameRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespChangeCount>>;
+    getRoleNamesRaw(requestParameters: GetRoleNamesRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespNameArray>>;
     /**
-     * Delete the named role. A valid tenant and user must be specified as query parameters.  This request is authorized only if the authenticated user is either the role owner or an administrator.
+     * Get the names of all roles in the tenant in alphabetic order. Future enhancements will include search filtering.  A valid tenant must be specified as a query parameter. This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
      */
-    deleteRoleByName(requestParameters: DeleteRoleByNameRequest, initOverrides?: RequestInit): Promise<RespChangeCount>;
+    getRoleNames(requestParameters?: GetRoleNamesRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespNameArray>;
     /**
-     * Get a user\'s default role. The default role is implicitly created by the system when needed if it doesn\'t already exist. No authorization required.  A user\'s default role is constructed by prepending \'$$\' to the user\'s name.  This implies the maximum length of a user name is 58 since role names are limited to 60 characters.
+     * Get the named role\'s permissions. By default, all permissions assigned to the role, whether directly and transitively through child roles, are returned. Set the immediate query parameter to only retrieve permissions directly assigned to the role. A valid tenant must be specified.  This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
      */
-    getDefaultUserRoleRaw(requestParameters: GetDefaultUserRoleRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespName>>;
+    getRolePermissionsRaw(requestParameters: GetRolePermissionsRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespNameArray>>;
     /**
-     * Get a user\'s default role. The default role is implicitly created by the system when needed if it doesn\'t already exist. No authorization required.  A user\'s default role is constructed by prepending \'$$\' to the user\'s name.  This implies the maximum length of a user name is 58 since role names are limited to 60 characters.
+     * Get the named role\'s permissions. By default, all permissions assigned to the role, whether directly and transitively through child roles, are returned. Set the immediate query parameter to only retrieve permissions directly assigned to the role. A valid tenant must be specified.  This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
      */
-    getDefaultUserRole(requestParameters: GetDefaultUserRoleRequest, initOverrides?: RequestInit): Promise<RespName>;
+    getRolePermissions(requestParameters: GetRolePermissionsRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespNameArray>;
     /**
-     * Get the named role\'s definition.  A valid tenant must be specified as a query parameter.  This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
+     * This read-only endpoint previews the transformations that would take place if the same input was used on a  replacePathPrefix POST call. This call is also implemented as a POST so that the same input as used on replacePathPrefix can be used here, but this call changes nothing.  This endpoint can be used to get an accounting of existing system/path combinations that match the input specification. Such information is useful when trying to duplicate a set of permissions. For example, one may want to copy a file subtree to another location and assign the same permissions to the new subtree as currently exist on the original subtree. One could use  this call to calculate the users that should be granted permission on the new subtree.  The optional parameters are roleName, oldPrefix and newPrefix. No wildcards are defined for the path prefix parameters. When roleName is specified then only permissions assigned to that role are considered.  When the oldPrefix parameter is provided, it\'s used to filter out permissions whose paths do not begin with the specified string; when not provided, no path prefix filtering occurs.  When the newPrefix parameter is not provided no new characters are prepended to the new path, effectively just removing the oldPrefix from the new path. When neither oldPrefix nor newPrefix are provided, no path transformation occurs, though system IDs can still be transformed.  The result object contains an array of transformation objects, each of which contains the unique permission sequence number, the existing permission that matched the search criteria and the new permission if the specified transformations were applied.  A valid tenant and user must be specified in the request body. This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
      */
-    getRoleByNameRaw(requestParameters: GetRoleByNameRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespRole>>;
+    previewPathPrefixRaw(requestParameters: PreviewPathPrefixRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespPathPrefixes>>;
     /**
-     * Get the named role\'s definition.  A valid tenant must be specified as a query parameter.  This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
+     * This read-only endpoint previews the transformations that would take place if the same input was used on a  replacePathPrefix POST call. This call is also implemented as a POST so that the same input as used on replacePathPrefix can be used here, but this call changes nothing.  This endpoint can be used to get an accounting of existing system/path combinations that match the input specification. Such information is useful when trying to duplicate a set of permissions. For example, one may want to copy a file subtree to another location and assign the same permissions to the new subtree as currently exist on the original subtree. One could use  this call to calculate the users that should be granted permission on the new subtree.  The optional parameters are roleName, oldPrefix and newPrefix. No wildcards are defined for the path prefix parameters. When roleName is specified then only permissions assigned to that role are considered.  When the oldPrefix parameter is provided, it\'s used to filter out permissions whose paths do not begin with the specified string; when not provided, no path prefix filtering occurs.  When the newPrefix parameter is not provided no new characters are prepended to the new path, effectively just removing the oldPrefix from the new path. When neither oldPrefix nor newPrefix are provided, no path transformation occurs, though system IDs can still be transformed.  The result object contains an array of transformation objects, each of which contains the unique permission sequence number, the existing permission that matched the search criteria and the new permission if the specified transformations were applied.  A valid tenant and user must be specified in the request body. This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
      */
-    getRoleByName(requestParameters: GetRoleByNameRequest, initOverrides?: RequestInit): Promise<RespRole>;
+    previewPathPrefix(requestParameters: PreviewPathPrefixRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespPathPrefixes>;
     /**
-     * Get the names of all roles in the tenant in alphabetic order.  Future enhancements will include search filtering.  A valid tenant must be specified as a query parameter.  This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
+     * Remove a child role from a parent role using a request body. A valid tenant and user must be specified in the request body. Supported only for roles of type *USER*.  The user@tenant identity specified in JWT is authorized to make this request only if that user is an administrator or if they own the parent role.
      */
-    getRoleNamesRaw(requestParameters: GetRoleNamesRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespNameArray>>;
+    removeChildRoleRaw(requestParameters: RemoveChildRoleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespChangeCount>>;
     /**
-     * Get the names of all roles in the tenant in alphabetic order.  Future enhancements will include search filtering.  A valid tenant must be specified as a query parameter.  This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
+     * Remove a child role from a parent role using a request body. A valid tenant and user must be specified in the request body. Supported only for roles of type *USER*.  The user@tenant identity specified in JWT is authorized to make this request only if that user is an administrator or if they own the parent role.
      */
-    getRoleNames(requestParameters: GetRoleNamesRequest, initOverrides?: RequestInit): Promise<RespNameArray>;
+    removeChildRole(requestParameters: RemoveChildRoleRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespChangeCount>;
     /**
-     * Get the named role\'s permissions.  By default, all permissions assigned to the role, whether directly and transitively through child roles, are returned.  Set the immediate query parameter to only retrieve permissions directly assigned to the role.  A valid tenant must be specified.  This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
+     * Remove an extended permission from all roles in a tenant using a request body. The tenant and permission must be specified in the request body.  Each role in the tenant is searched for the extended permission string and, where found, that permission is removed. The matching algorithm is string comparison with wildcard semantics on the path component. This is the same as an exact string match for all parts of the permission specification up to the path part. A match on the path part, however, occurs when its path is a prefix of a role permission\'s path. Consider the following permission specification:      files:mytenant:read:mysystem:/my/dir  which will match both of the following role permissions:      files:mytenant:read:mysystem:/my/dir/subdir/myfile     files:mytenant:read:mysystem:/my/dir33/yourfile  Note that a match to the second role permission might be a *false capture* if the intension was to remove all permissions to resources in the /my/dir subtree, but not those in other directories. To avoid this potential problem, callers can make two calls, one to this endpoint with a permSpec that ends with a slash (\"/\") and one to the removePermissionFromeAllRoles endpoint with no trailing slash. The former removes all children from the directory subtree, the latter removes the directory itself.  Only the Files service is authorized to make this call.
      */
-    getRolePermissionsRaw(requestParameters: GetRolePermissionsRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespNameArray>>;
+    removePathPermissionFromAllRolesRaw(requestParameters: RemovePathPermissionFromAllRolesRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespChangeCount>>;
     /**
-     * Get the named role\'s permissions.  By default, all permissions assigned to the role, whether directly and transitively through child roles, are returned.  Set the immediate query parameter to only retrieve permissions directly assigned to the role.  A valid tenant must be specified.  This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
+     * Remove an extended permission from all roles in a tenant using a request body. The tenant and permission must be specified in the request body.  Each role in the tenant is searched for the extended permission string and, where found, that permission is removed. The matching algorithm is string comparison with wildcard semantics on the path component. This is the same as an exact string match for all parts of the permission specification up to the path part. A match on the path part, however, occurs when its path is a prefix of a role permission\'s path. Consider the following permission specification:      files:mytenant:read:mysystem:/my/dir  which will match both of the following role permissions:      files:mytenant:read:mysystem:/my/dir/subdir/myfile     files:mytenant:read:mysystem:/my/dir33/yourfile  Note that a match to the second role permission might be a *false capture* if the intension was to remove all permissions to resources in the /my/dir subtree, but not those in other directories. To avoid this potential problem, callers can make two calls, one to this endpoint with a permSpec that ends with a slash (\"/\") and one to the removePermissionFromeAllRoles endpoint with no trailing slash. The former removes all children from the directory subtree, the latter removes the directory itself.  Only the Files service is authorized to make this call.
      */
-    getRolePermissions(requestParameters: GetRolePermissionsRequest, initOverrides?: RequestInit): Promise<RespNameArray>;
+    removePathPermissionFromAllRoles(requestParameters: RemovePathPermissionFromAllRolesRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespChangeCount>;
     /**
-     * This read-only endpoint previews the transformations that would take place if the same input was used on a replacePathPrefix POST call. This call is also implemented as a POST so that the same input as used on replacePathPrefix can be used here, but this call changes nothing.  This endpoint can be used to get an accounting of existing system/path combinations that match the input specification. Such information is useful when trying to duplicate a set of permissions. For example, one may want to copy a file subtree to another location and assign the same permissions to the new subtree as currently exist on the original subtree. One could use  this call to calculate the users that should be granted permission on the new subtree.  The optional parameters are roleName, oldPrefix and newPrefix. No wildcards are defined for the path prefix parameters.  When roleName is specified then only permissions assigned to that role are considered.  When the oldPrefix parameter is provided, it\'s used to filter out permissions whose paths do not begin with the specified string; when not provided, no path prefix filtering occurs.  When the newPrefix parameter is not provided no new characters are prepended to the new path, effectively just removing the oldPrefix from the new path. When neither oldPrefix nor newPrefix are provided, no path transformation occurs, though system IDs can still be transformed.  The result object contains an array of transformation objects, each of which contains the unique permission sequence number, the existing permission that matched the search criteria and the new permission if the specified transformations were applied.  A valid tenant and user must be specified in the request body.  This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
+     * Remove a permission from all roles in a tenant using a request body. The tenant and permission must be specified in the request body.  Each role in the tenant is searched for the *exact* permission string and, where found, that permission is removed. The matching algorithm is simple, character by character, string comparison.  Permissions are not interpreted. For example, a permission that contains a wildcard (*) will only match a role\'s permission when the same wildcard is found in the exact same position. The same rule applies to permission segments with multiple, comma separated components: a match requires the exact same ordering and spacing of components.  Only services are authorized to make this call.
      */
-    previewPathPrefixRaw(requestParameters: PreviewPathPrefixRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespPathPrefixes>>;
+    removePermissionFromAllRolesRaw(requestParameters: RemovePermissionFromAllRolesRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespChangeCount>>;
     /**
-     * This read-only endpoint previews the transformations that would take place if the same input was used on a replacePathPrefix POST call. This call is also implemented as a POST so that the same input as used on replacePathPrefix can be used here, but this call changes nothing.  This endpoint can be used to get an accounting of existing system/path combinations that match the input specification. Such information is useful when trying to duplicate a set of permissions. For example, one may want to copy a file subtree to another location and assign the same permissions to the new subtree as currently exist on the original subtree. One could use  this call to calculate the users that should be granted permission on the new subtree.  The optional parameters are roleName, oldPrefix and newPrefix. No wildcards are defined for the path prefix parameters.  When roleName is specified then only permissions assigned to that role are considered.  When the oldPrefix parameter is provided, it\'s used to filter out permissions whose paths do not begin with the specified string; when not provided, no path prefix filtering occurs.  When the newPrefix parameter is not provided no new characters are prepended to the new path, effectively just removing the oldPrefix from the new path. When neither oldPrefix nor newPrefix are provided, no path transformation occurs, though system IDs can still be transformed.  The result object contains an array of transformation objects, each of which contains the unique permission sequence number, the existing permission that matched the search criteria and the new permission if the specified transformations were applied.  A valid tenant and user must be specified in the request body.  This request is authorized if the requestor is a user that has access to the specified tenant or if the requestor is a service.
+     * Remove a permission from all roles in a tenant using a request body. The tenant and permission must be specified in the request body.  Each role in the tenant is searched for the *exact* permission string and, where found, that permission is removed. The matching algorithm is simple, character by character, string comparison.  Permissions are not interpreted. For example, a permission that contains a wildcard (*) will only match a role\'s permission when the same wildcard is found in the exact same position. The same rule applies to permission segments with multiple, comma separated components: a match requires the exact same ordering and spacing of components.  Only services are authorized to make this call.
      */
-    previewPathPrefix(requestParameters: PreviewPathPrefixRequest, initOverrides?: RequestInit): Promise<RespPathPrefixes>;
+    removePermissionFromAllRoles(requestParameters: RemovePermissionFromAllRolesRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespChangeCount>;
     /**
-     * Remove a child role from a parent role using a request body.  A valid tenant and user must be specified in the request body.  The user@tenant identity specified in JWT is authorized to make this request only if that user is an administrator or if they own the parent role.
+     * Remove a permission from a role using a request body. A valid role, roleTenant and permission must be specified in the request body.  For roles of type USER the request is authorized only if the requestor is the role owner, a tenant administrator or a site administrator. For roles of type TENANT_ADMIN the requestor must a tenant or site administrator. For roles of type RESTRICTED_SVC the requestor must a site administrator.
      */
-    removeChildRoleRaw(requestParameters: RemoveChildRoleRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespChangeCount>>;
+    removeRolePermissionRaw(requestParameters: RemoveRolePermissionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespChangeCount>>;
     /**
-     * Remove a child role from a parent role using a request body.  A valid tenant and user must be specified in the request body.  The user@tenant identity specified in JWT is authorized to make this request only if that user is an administrator or if they own the parent role.
+     * Remove a permission from a role using a request body. A valid role, roleTenant and permission must be specified in the request body.  For roles of type USER the request is authorized only if the requestor is the role owner, a tenant administrator or a site administrator. For roles of type TENANT_ADMIN the requestor must a tenant or site administrator. For roles of type RESTRICTED_SVC the requestor must a site administrator.
      */
-    removeChildRole(requestParameters: RemoveChildRoleRequest, initOverrides?: RequestInit): Promise<RespChangeCount>;
+    removeRolePermission(requestParameters: RemoveRolePermissionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespChangeCount>;
     /**
-     * Remove a permission from a role using a request body.  A valid role, roleTenant and permission must be specified in the request body.  Only the role owner or administrators are authorized to make this call.
+     * Replace the text in a permission specification when its last component defines an *extended path attribute*. Extended path attributes enhance the standard Shiro matching algorithm with one that treats designated components in a permission specification as a path name, such as a posix file or directory path name. This request is useful when files or directories have been renamed or moved and their authorizations need to be adjusted. Consider, for example, permissions that conform to the following specification:        files:tenantId:op:systemId:path  By definition, the last component is an extended path attribute whose content can be changed by replacePathPrefix requests. Specifically, paths that begin with the oldPrefix will have that prefix replaced with the newPrefix value. Replacement only occurs on permissions that also match the schema and oldSystemId parameter values. The systemId attribute is required to immediately precede the path attribute, which must be the last attribute.  Additionally, the oldSystemId is replaced with the newSystemId when a match is found. If a roleName is provided, then replacement is limited to permissions defined only in that role. Otherwise, permissions in all roles that meet the other matching criteria will be considered.  The optional parameters are roleName, oldPrefix and newPrefix. No wildcards are defined for the path prefix parameters. When roleName is specified then only permissions assigned to that role are considered.  When the oldPrefix parameter is provided, it\'s used to filter out permissions whose paths do not begin with the specified string; when not provided, no path prefix filtering occurs.  When the newPrefix parameter is not provided no new characters are prepended to the new path, effectively just removing the oldPrefix from the new path. When neither oldPrefix nor newPrefix are provided, no path transformation occurs, though system IDs can still be transformed.  The previewPathPrefix request provides a way to do a dry run using the same input as this request. The preview call calculates the permissions that would change and what their new values would be, but it does not actually change those permissions as replacePathPrefix does.  The input parameters are passed in the payload of this request. The response indicates the number of changed permission specifications.  The path prefix replacement operation is authorized if the user@tenant in the JWT represents a tenant administrator or the Files service.
      */
-    removeRolePermissionRaw(requestParameters: RemoveRolePermissionRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespChangeCount>>;
+    replacePathPrefixRaw(requestParameters: ReplacePathPrefixRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespChangeCount>>;
     /**
-     * Remove a permission from a role using a request body.  A valid role, roleTenant and permission must be specified in the request body.  Only the role owner or administrators are authorized to make this call.
+     * Replace the text in a permission specification when its last component defines an *extended path attribute*. Extended path attributes enhance the standard Shiro matching algorithm with one that treats designated components in a permission specification as a path name, such as a posix file or directory path name. This request is useful when files or directories have been renamed or moved and their authorizations need to be adjusted. Consider, for example, permissions that conform to the following specification:        files:tenantId:op:systemId:path  By definition, the last component is an extended path attribute whose content can be changed by replacePathPrefix requests. Specifically, paths that begin with the oldPrefix will have that prefix replaced with the newPrefix value. Replacement only occurs on permissions that also match the schema and oldSystemId parameter values. The systemId attribute is required to immediately precede the path attribute, which must be the last attribute.  Additionally, the oldSystemId is replaced with the newSystemId when a match is found. If a roleName is provided, then replacement is limited to permissions defined only in that role. Otherwise, permissions in all roles that meet the other matching criteria will be considered.  The optional parameters are roleName, oldPrefix and newPrefix. No wildcards are defined for the path prefix parameters. When roleName is specified then only permissions assigned to that role are considered.  When the oldPrefix parameter is provided, it\'s used to filter out permissions whose paths do not begin with the specified string; when not provided, no path prefix filtering occurs.  When the newPrefix parameter is not provided no new characters are prepended to the new path, effectively just removing the oldPrefix from the new path. When neither oldPrefix nor newPrefix are provided, no path transformation occurs, though system IDs can still be transformed.  The previewPathPrefix request provides a way to do a dry run using the same input as this request. The preview call calculates the permissions that would change and what their new values would be, but it does not actually change those permissions as replacePathPrefix does.  The input parameters are passed in the payload of this request. The response indicates the number of changed permission specifications.  The path prefix replacement operation is authorized if the user@tenant in the JWT represents a tenant administrator or the Files service.
      */
-    removeRolePermission(requestParameters: RemoveRolePermissionRequest, initOverrides?: RequestInit): Promise<RespChangeCount>;
+    replacePathPrefix(requestParameters: ReplacePathPrefixRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespChangeCount>;
     /**
-     * Replace the text in a permission specification when its last component defines an *extended path attribute*.  Extended path attributes enhance the standard Shiro matching algorithm with one that treats designated components in a permission specification as a path name, such as a posix file or directory path name.  This request is useful when files or directories have been renamed or moved and their authorizations need to be adjusted.  Consider, for example, permissions that conform to the following specification:        files:tenantId:op:systemId:path  By definition, the last component is an extended path attribute whose content can be changed by replacePathPrefix requests.  Specifically, paths that begin with the oldPrefix will have that prefix replaced with the newPrefix value.  Replacement only occurs on permissions that also match the schema and oldSystemId parameter values.  The systemId attribute is required to immediately precede the path attribute, which must be the last attribute.  Additionally, the oldSystemId is replaced with the newSystemId when a match is found.  If a roleName is provided, then replacement is limited to permissions defined only in that role.  Otherwise, permissions in all roles that meet the other matching criteria will be considered.  The optional parameters are roleName, oldPrefix and newPrefix. No wildcards are defined for the path prefix parameters.  When roleName is specified then only permissions assigned to that role are considered.  When the oldPrefix parameter is provided, it\'s used to filter out permissions whose paths do not begin with the specified string; when not provided, no path prefix filtering occurs.  When the newPrefix parameter is not provided no new characters are prepended to the new path, effectively just removing the oldPrefix from the new path. When neither oldPrefix nor newPrefix are provided, no path transformation occurs, though system IDs can still be transformed.  The previewPathPrefix request provides a way to do a dry run using the same input as this request. The preview call calculates the permissions that would change and what their new values would be, but it does not actually change those permissions as replacePathPrefix does.  The input parameters are passed in the payload of this request.  The response indicates the number of changed permission specifications.  The path prefix replacement operation is authorized if the user@tenant in the JWT represents a tenant administrator or the Files service.
+     * Check to see if the specified role allows the specified permission.  Any authenticated user may make this request.
      */
-    replacePathPrefixRaw(requestParameters: ReplacePathPrefixRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespChangeCount>>;
+    rolePermitsRaw(requestParameters: RolePermitsRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespAuthorized>>;
     /**
-     * Replace the text in a permission specification when its last component defines an *extended path attribute*.  Extended path attributes enhance the standard Shiro matching algorithm with one that treats designated components in a permission specification as a path name, such as a posix file or directory path name.  This request is useful when files or directories have been renamed or moved and their authorizations need to be adjusted.  Consider, for example, permissions that conform to the following specification:        files:tenantId:op:systemId:path  By definition, the last component is an extended path attribute whose content can be changed by replacePathPrefix requests.  Specifically, paths that begin with the oldPrefix will have that prefix replaced with the newPrefix value.  Replacement only occurs on permissions that also match the schema and oldSystemId parameter values.  The systemId attribute is required to immediately precede the path attribute, which must be the last attribute.  Additionally, the oldSystemId is replaced with the newSystemId when a match is found.  If a roleName is provided, then replacement is limited to permissions defined only in that role.  Otherwise, permissions in all roles that meet the other matching criteria will be considered.  The optional parameters are roleName, oldPrefix and newPrefix. No wildcards are defined for the path prefix parameters.  When roleName is specified then only permissions assigned to that role are considered.  When the oldPrefix parameter is provided, it\'s used to filter out permissions whose paths do not begin with the specified string; when not provided, no path prefix filtering occurs.  When the newPrefix parameter is not provided no new characters are prepended to the new path, effectively just removing the oldPrefix from the new path. When neither oldPrefix nor newPrefix are provided, no path transformation occurs, though system IDs can still be transformed.  The previewPathPrefix request provides a way to do a dry run using the same input as this request. The preview call calculates the permissions that would change and what their new values would be, but it does not actually change those permissions as replacePathPrefix does.  The input parameters are passed in the payload of this request.  The response indicates the number of changed permission specifications.  The path prefix replacement operation is authorized if the user@tenant in the JWT represents a tenant administrator or the Files service.
+     * Check to see if the specified role allows the specified permission.  Any authenticated user may make this request.
      */
-    replacePathPrefix(requestParameters: ReplacePathPrefixRequest, initOverrides?: RequestInit): Promise<RespChangeCount>;
+    rolePermits(requestParameters: RolePermitsRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespAuthorized>;
     /**
-     * Update an existing role\'s decription using a request body.  The size limit on a description is 2048 characters.  This request is authorized if the requestor is the role owner or an administrator.
+     * Update an existing role\'s decription using a request body. The size limit on a description is 2048 characters.  This request is authorized if the requestor is the role owner or an administrator.
      */
-    updateRoleDescriptionRaw(requestParameters: UpdateRoleDescriptionRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespBasic>>;
+    updateRoleDescriptionRaw(requestParameters: UpdateRoleDescriptionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespBasic>>;
     /**
-     * Update an existing role\'s decription using a request body.  The size limit on a description is 2048 characters.  This request is authorized if the requestor is the role owner or an administrator.
+     * Update an existing role\'s decription using a request body. The size limit on a description is 2048 characters.  This request is authorized if the requestor is the role owner or an administrator.
      */
-    updateRoleDescription(requestParameters: UpdateRoleDescriptionRequest, initOverrides?: RequestInit): Promise<RespBasic>;
+    updateRoleDescription(requestParameters: UpdateRoleDescriptionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespBasic>;
     /**
-     * Update an existing role\'s name using a request body.  Role names are case sensitive, alphanumeric strings that can contain underscores but must begin with an alphabetic character.  The limit on role name is 58 characters.  This request is authorized if the requestor is the role owner or an administrator.
+     * Update an existing role\'s name using a request body. Role names are case sensitive, alphanumeric strings that can contain underscores but must begin with an alphabetic character. The limit on role name is 58 characters.  This request is authorized if the requestor is the role owner or an administrator.
      */
-    updateRoleNameRaw(requestParameters: UpdateRoleNameRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespBasic>>;
+    updateRoleNameRaw(requestParameters: UpdateRoleNameRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespBasic>>;
     /**
-     * Update an existing role\'s name using a request body.  Role names are case sensitive, alphanumeric strings that can contain underscores but must begin with an alphabetic character.  The limit on role name is 58 characters.  This request is authorized if the requestor is the role owner or an administrator.
+     * Update an existing role\'s name using a request body. Role names are case sensitive, alphanumeric strings that can contain underscores but must begin with an alphabetic character. The limit on role name is 58 characters.  This request is authorized if the requestor is the role owner or an administrator.
      */
-    updateRoleName(requestParameters: UpdateRoleNameRequest, initOverrides?: RequestInit): Promise<RespBasic>;
+    updateRoleName(requestParameters: UpdateRoleNameRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespBasic>;
     /**
      * Update an existing role\'s owner using a request body. Required parameters in the payload are the *roleTenant*, which is the tenant of named role, and *newOwner*, which is the user to which role ownership is being transferred. The *newTenant* payload parameter is optional and only needed when the new owner resides in a different tenant than that of the current owner.  This request is authorized if the requestor is the role owner or an administrator. If a new tenant is specified, then the requestor must also be allowed to act in the new tenant.
      */
-    updateRoleOwnerRaw(requestParameters: UpdateRoleOwnerRequest, initOverrides?: RequestInit): Promise<runtime.ApiResponse<RespBasic>>;
+    updateRoleOwnerRaw(requestParameters: UpdateRoleOwnerRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<RespBasic>>;
     /**
      * Update an existing role\'s owner using a request body. Required parameters in the payload are the *roleTenant*, which is the tenant of named role, and *newOwner*, which is the user to which role ownership is being transferred. The *newTenant* payload parameter is optional and only needed when the new owner resides in a different tenant than that of the current owner.  This request is authorized if the requestor is the role owner or an administrator. If a new tenant is specified, then the requestor must also be allowed to act in the new tenant.
      */
-    updateRoleOwner(requestParameters: UpdateRoleOwnerRequest, initOverrides?: RequestInit): Promise<RespBasic>;
+    updateRoleOwner(requestParameters: UpdateRoleOwnerRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<RespBasic>;
 }