Skip to main content

User Roles (System Role)

Overview​

system_role is the role table that defines which modules each role has rights to, with the detailed permissions stored in system_role_module.

On the API side this module is deliberately minimal: it exposes a single endpoint that feeds the role dropdown on the user create and edit screens. Roles and permissions are not edited through this API at all — they are master data configured in the database and overridden per organization through the organization_module table.

One role value carries special meaning in code: roleId == 1 is SUPER_ADMIN, the value that auth.SuperAdmin() checks for.

Business Flow​

  1. The user management screen in cms-web needs the list of roles to render a dropdown.
  2. It calls GET /api/system-role/find-all-object behind JwtLoginAuth, which is reachable before an OA has been selected.
  3. The service queries system_role and returns an object/dropdown structure ordered the same way the original NestJS implementation did.
  4. When a user is created with a roleId, their baseline permissions come from that role's entries in system_role_module.
  5. When cms-web needs the effective permissions, it calls GET /api/user/:id/permission, which merges the role baseline with the organization-level overrides.

Parity note: @CheckPolicies(read, ORGANIZATION) was commented out in the original TypeScript source, so the Go route carries no policy annotation either.

Key Files & Functions​

The code lives in internal/modules/systemrole/, consisting of controller.go, service.go, repository.go, and dto.go.

MethodRouteHandlerGuard
GET/api/system-role/find-all-objectfindAllObject(c, svc)JwtLoginAuth on the public group

RegisterRoutes uses only the public group; the _ = authed line confirms the authed group is intentionally unused.

A sibling concept with no routes of its own is system_role_module, which has no separate Go module (its TypeScript controller was empty too). Its data is read through the User.SystemRoleModule relation inside the user module.

Connections to Other Services​

  • Permissions — requires a token that passes JwtLoginAuth; no lineOaId is needed and no policy check is applied.
  • Tables — system_role, system_role_module
  • Related modules — the system module registry (the module master list), the permission resolution and module gate mechanism, and CMS user management, which consumes this dropdown.