Validation for RBAC rule creation and update

The system enforces permissions based on the operation performed on a document. The system checks the user's effective permissions against the specific operation being performed:

1. Document read operation

   The system requires the user to have at least one permission defined for the document’s current category to allow the document read operation.

2. Full update operation

   The system requires the submit permission for the document’s current category when processing a full update request (PUT).

3. Partial update operation

   The system enforces permissions based on the type of update performed during a partial update request (PATCH). The system requires edit_document_fields or update_fields when the request modifies entity fields. The system requires edit_table_data or update_fields when the request modifies table data. The system requires the archive permission when the request sets the archive flag to true.

4. Category move operation

   The system requires the move permission for the source category of the document. The system also requires at least one permission for the destination category. The system denies the operation when either condition is not satisfied.

5. Bulk update operation

   The system evaluates each document independently during a bulk update request. The system requires the archive permission for archiving operations, the move permission for category change operations, and the update_fields permission for field-level updates, including reprocessing, visibility updates, and user assignment changes.

The system supports two methods for updating RBAC rules: full update using the PUT operation and partial update using the PATCH operation. Each method follows a defined behavior for handling rule data, including permissions, conditions, and concurrency.

• Full update behavior (PUT)

  The system treats a PUT request as a complete replacement of the RBAC rule. The request must include all rule fields, including permissions and conditions. The system removes existing conditions when the request does not include condition data.

• Partial update behavior (PATCH)

  The system updates only the fields provided in a PATCH request. However, when the request includes permissions or conditions, the system replaces the entire existing set for the corresponding field. The system does not merge permissions or conditions during a PATCH operation. The system retains existing permissions and conditions only when the request does not include those fields

• Permissions and condition replacement

  The system never merges permission or condition arrays during updates. When a rule contains permissions for multiple categories and the update request includes permissions for a subset of categories, the system replaces the entire existing permission set with the provided values. The same behavior applies to condition arrays. To prevent unintended data removal, the client application must retrieve the current rule definition, modify the complete array, and submit the full updated array in the request

• Concurrent update handling

  The system uses optimistic locking to manage concurrent updates. When multiple administrators attempt to update the same RBAC rule simultaneously, the system processes the first request successfully and rejects subsequent conflicting requests with a conflict error. The client application must retrieve the latest version of the rule and resubmit the update request.

The RPA-Admin role provides elevated privileges for administrative operations, but the system does not bypass RBAC permission enforcement when evaluating access to document content. The system applies RBAC evaluation consistently to all users, including users assigned to the RPA-Admin role.

The system allows RPA-Admin users to perform specific administrative operations that are not available to standard users.

• Rule management

  Restrict RBAC rule management operations, including create, update, delete, and list, to users assigned to the RPA-Admin role.

• Delete operations

  Perform document deletion operations, including both single-document and bulk deletion.

The system evaluates document access for RPA-Admin users by using the same RBAC evaluation process applied to all users. The system compares the user identity and group memberships against rule principals, evaluates attribute conditions, and determines effective permissions based on matching rules. The system denies access when no RBAC rule matches the user, even when the user is assigned to the RPA-Admin role.

This section provides examples to use the RBAC APIs for creating rules and retrieving effective permissions.

Example:

This example creates a rule that grants the IFS Security Role "Approver" permission to view and submit documents in the "NEEDSVERIFICATION" category, but only for documents where the DIVISION field equals "US_EAST".

POST /api/v1/rpa/exception/usecasetypes/{id}/rbac/rules

Content-Type: application/json

{

"principal_type": "SECURITY_ROLE",

"principal_value": "Approver",

"principal_display_name": "Approver Role",

"active": true,

"grant_all_documents": false,

"permissions": [

{

"usecase_category": "NEEDSVERIFICATION",

"permissions": ["view_document", "submit"]

}

],

"conditions": [

{

"attribute_source": "DOCUMENT_ENTITY",

"attribute_key": "DIVISION",

"operator": "EQUALS",

"value": "US_EAST"

}

]

}

Example: Creating a rule with grant_all_document

To apply a rule to all documents in the use case type without filtering any specific attribute, set grant_all_document to true. When grant_all_document is enabled, any conditions on the rule are ignored. The following example grants a specific user full permissions across all categories for all documents:

{ "principal_type": "USER", "principal_value": "john.smith", "principal_display_name": "John Smith", "active": true, "grant_all_documents": true, "permissions": [ { "usecase_category": "MISSINGINFORMATION", "permissions": ["view_document", "edit_document_fields", "edit_table_data", "submit", "archive", "move"] }, { "usecase_category": "NEEDSVERIFICATION", "permissions": ["view_document", "edit_document_fields", "edit_table_data", "submit", "archive", "move"] } ] }

Example: Retrieving effective permissions

Any authenticated user can retrieve the effective permissions for a use case type. This is useful for the UI to determine which actions to display or enable for the current user.

GET /api/v1/rpa/exception/usecasetypes/{id}/rbac/permissions/{userId}