Interface RoleRequest._FinalStage
- All Known Implementing Classes:
RoleRequest.Builder
- Enclosing class:
RoleRequest
-
Method Summary
Modifier and TypeMethodDescriptionaddAllScopes(List<ScopeClause> scopes) additionalProperties(Map<String, Object> additionalProperties) additionalProperty(String key, Object value) addScopes(ScopeClause scopes) build()description(String description) description(Optional<String> description) An optional free-text description of what the role grants.scopes(List<ScopeClause> scopes) The role's permissions, as one or more scope clauses.
-
Method Details
-
build
RoleRequest build() -
additionalProperty
-
additionalProperties
-
description
An optional free-text description of what the role grants.
-
description
-
scopes
The role's permissions, as one or more scope clauses. Each clause has
allowed_actions(a list of permitted verbs),data_scope(an attribute filter that restricts which records the actions apply to), and an optionalgranted_capabilitieslist. An action is permitted if any clause allows that action and that clause's data scope matches the target record — with one caveat worth knowing before you usegranted_capabilities: a clause naming a capability this release does not recognize is denied ENTIRELY, so itsallowed_actionsstop applying too. To include records whose ownership field is null (account-level shared records), addnullto the allowed values for that field. One exception applies when creating an identity entity: the entity's own-namespace dimension (scope:<namespace>) takes the value of the ID the server is about to generate, so no clause written beforehand could name it, and that one dimension is exempt from the match onPOST /v1/entities/{namespace}. It is matched normally on every read, update, and delete — so a clause whose data scope names only that dimension does not restrict what you may create, and an entity created under one may fall outside it once it exists. -
addScopes
-
addAllScopes
-