Estimated Work Hours for SZ-5: Role-Based Authorization (AuthZ)

Estimated Total: ~6–9 hours

Sztab System Roles

This document lists all predefined system roles and their intended responsibilities in the Sztab project.

Role Hierarchy

While roles are technically flat in the system, the following implied hierarchy reflects how roles relate in terms of responsibility and access:

ADMIN
 ├── PROJECT_MANAGER
 │   ├── DEVELOPER
 │   ├── QA_ENGINEER
 │   ├── DOCUMENT_WRITER
 │   ├── UX_DESIGNER
 │   └── SCRUM_MASTER
 ├── RELEASE_MANAGER
 ├── CUSTOMER_SUPPORT
 └── OBSERVER

Interpretation and Usage

• ADMIN can perform all actions in the system.
• PROJECT_MANAGER coordinates the core delivery team, including developers, testers, and writers.
• RELEASE_MANAGER, CUSTOMER_SUPPORT, and OBSERVER are lateral roles with distinct access patterns such as release pipelines, support dashboards, or audits.
• This hierarchy is not enforced by default, but you can encode it in Spring Security using RoleHierarchyImpl if needed for transitive role permissions.

I think the best approach is to have access permissions to resources and functionality. Then we could create roles on demand when necessary. Each role could be created with selected permissions. This would give us most flexibility.

I understand that "Admin" (or super admin) role must be predefined or hardcoded but other that that all other roles should be configurable. We can of course ship the package with a set of pre-created roles.

On top of the listed roles, there might also be roles like "community user", "customer", etc....

I agree that using permission-based access control with configurable roles would offer greater flexibility. For now, I’ve gone with Spring Security’s built-in role-based approach to secure the MVP endpoints using @PreAuthorize("hasRole(...)"), which is quick to implement and easy to test.

That said, I suggest we follow this phased path: 1. Use static roles (e.g., ADMIN, DEVELOPER) for MVP and seed them at startup. 2. In a follow-up phase, introduce a Permission model and define roles dynamically in the database. 3. Shift controller-level checks from hasRole(...) to hasAuthority(...), based on assigned permissions.

For example, instead of granting access based solely on roles like PROJECT_MANAGER, we could define permissions like ASSIGN_ISSUE, CLOSE_ISSUE, etc., and assign them to roles in the database. This would allow us to create roles like “community user” or “customer” later without changing code.

Let me know if this phased approach sounds good. I’ll proceed with the static model for now and open a follow-up item to track the dynamic permission system.

Please see https://tigase.dev/sztab/~issues/15

If you prefer, I can drop the static role layer altogether and go directly to a fully dynamic RBAC setup now.

It will take more time and introduce some early complexity (e.g., role/permission modeling, UI exposure, etc.), but I’m happy to go that route if you’d rather not build on the static layer at all.

Let me know your preference — I’m good either way.

— Rk

If it is possible to change roles into permissions later without turning everything upside down then go with predefined static roles now. I would prefer to see basics functionality working sooner than later. Just make sure we have all our typical roles we use now, so we can replace OneDev with Sztab. I am also assuming that it will not be too time consuming to add more static roles if needed.

As I said, I would like to see roles like

• "CUSTOMER" - access to specific projects assigned to the customer. Can open issues, comment on them, reassign, change status. Cannot see certain fields like time tracking. Cannot see the code.
• "CUSTOMER_WITH_CODE" - as above but with code access
• "COMMUNITY USER" - read only access to all open source projects + plus opening and discussing issues in any open source project

@andrzej.wojcik @wojtek anything to add?