User categories

Cabinee defines several user categories that differ by access level and management capabilities.

This document describes the application access model inside the system and is not related to Keycloak roles.

1. User

Description
A regular system user without administrative or management rights.

Available

• Tasks where the user is assigned as Assignee (task.assignee);
• Tickets where the user is responsible (ticket.responsible) or owner (ticket.owner);
• Records related to available tickets: Attachments and Activity feed ;
• Service catalog with the ability to start related processes.

Restrictions

• No access to the list of workspaces;
• No ability to change process or ticket settings that are not directly related to the user.

2. Space participant (Workflow Participant)

Description
A user who has access (Permission) to a specific space .

Available

• Creating tickets from an available workspace;
• Viewing, commenting on, or changing tickets depending on the access level: RO, COMMENT, RW, OWNER;
• Viewing all tickets in the space if the access level allows reading.

Restrictions

• RO provides read-only access;
• COMMENT adds the ability to comment;
• RW adds the ability to change tickets, but not to manage settings and access;
• Space settings and access are available only to the owner or a participant with the OWNER level.

3. Ticket participant (TicketPermission)

Description A user, group, or service account that has been granted point ticket access (TicketPermission).

Available

• Viewing a specific ticket;
• Commenting on or changing that ticket if allowed by the READ, COMMENT, or EDIT level;
• Working only with the ticket for which access was granted.

Restrictions

• Does not receive access to the entire space;
• Cannot manage space settings;
• Cannot manage access unless a separate access-management right is granted.

4. Space owner (Workflow Owner)

Description
A space participant who additionally has rights to manage this space’s settings (workflow.owner).

Available

• All rights of a space participant;
• Managing space configuration (BPMN model, task screen forms, templates, notifications, and similar);
• Adding space participants and assigning their access.

5. System administrator (System Administrator)

Description
A user with the administrative role specified in the application.admin-role-name parameter
(default — ROLE_cabinee-admin; the legacy code default is ROLE_unibpm-admin until the Cabinee installer is updated).

Available

• Full access to all spaces and tickets;
• Managing users, groups, access categories, and system settings;
• Access to the Administration section.

Managing users and groups

The system administrator has access to the Administration → Users and groups section, which provides the following operations:

• viewing system users;
• viewing groups;
• creating local groups;
• changing the name and description of local groups;
• deleting local groups;
• adding users to groups;
• removing users from groups.

Keycloak integration details

If background user and group synchronization through Keycloak is enabled (identity.keycloak.sync-enabled=true), Keycloak is the source of truth.

During the next synchronization:

• locally created groups that are missing in Keycloak are archived;
• manual group membership changes may be overwritten by Keycloak data.

To use local user and group management only, it is recommended to disable background synchronization:

identity.keycloak.sync-enabled=false

When JIT provisioning is enabled, users are created and updated automatically after successful authentication through Keycloak. Groups must already exist in the local database and can be created by an administrator or by legacy sync. JIT matches them to the JWT by name regardless of the creation source and does not change the group’s source or metadata. The user’s membership is aligned with the set of existing groups from the JWT; a missing or empty claim clears membership. Manual additions and removals remain allowed, but may be overwritten on the next sign-in.

Task visibility

The task visibility feature determines which tasks are displayed to a user in Cabinee.

A user can see tasks:

• in the admin panel, Tasks section;
• in a ticket, Tasks section.

General logic

Each user sees only the tasks they have access to based on their role.

Technical implementation

Task visibility logic is implemented at the backend level and is split between two main components:
PermissionServiceImpl and TaskQueryService.

Task visibility is implemented at the backend level and is determined by a combination of services:

• PermissionServiceImpl.limitAccess() restricts task visibility depending on the user role.
• PermissionServiceImpl.isWorkflowOwner() determines whether the user is the owner of one or more spaces.
• PermissionServiceImpl.applyUserAccessFilters() adds filters by assignee and related tasks.
• TaskQueryService.createPermissionSpecification() builds queries with access filtering.
• TaskController.getList() applies the access restriction before retrieving the task list.

Filtering is performed before the database is queried, so that inaccessible tasks are never displayed.

💡 Note

Cabinee user categories are not Keycloak roles.
Keycloak is used for authentication and basic access control,
while user categories define application access inside the system.

📘 Comparison table