CMS User Management

Overview

The user module manages the accounts of everyone who works inside the CMS. It covers creating, editing, enabling and disabling accounts, soft and hard deletion, admin-initiated password resets, reading one's own permissions, and deciding which LINE OAs each user is allowed to access.

What sets this module apart is that every route is registered on the public group and attaches JwtLoginAuth explicitly rather than relying on the global JwtAuth. This is deliberate: the user management screens must be reachable without a lineOaId bound to the token, which is a prerequisite of the authed group.

Business Flow

Managing user records

1. GET /api/user returns a paginated list with filtering and search driven by QueryParamsUserDto, scoped to the caller's organization.
2. GET /api/user/find-all-object returns an {id: name} shape for populating dropdowns.
3. POST /api/user creates a user. It accepts multipart/form-data so an avatar image can be uploaded; the password is hashed and recorded in the password history.
4. PUT /api/user/:id updates the record, and PUT /api/user/:id/status enables or disables the account.
5. DELETE /api/user/:id performs a soft delete by stamping deleted_date.
6. DELETE /api/user/:id/hard removes the record permanently. It requires a super admin and the ?confirm=true query parameter.

Admin-initiated password reset

POST /api/user/:id/admin-reset-password lets an administrator reset another user's password directly. This is a separate path from the self-service flow described under password management.

Reading your own permissions

GET /api/user/:id/permission carries a special constraint: the service verifies that :id matches the selfId held in CLS, otherwise it responds with 400 and the message Cannot access other userId. The cms-web frontend uses this response to decide which menu items to render.

Per-user OA access

GET /api/user/:id/oa-access and PUT /api/user/:id/oa-access allow an organization administrator to define which LINE OAs a given user can see and select. The result is persisted in the user_line_oa table. This capability is new relative to the original NestJS system.

Key Files & Functions

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

Method	Route	Handler	Policy (metadata)
GET	/api/user	ct.findAll	readAll user
GET	/api/user/find-all-object	ct.findAllObject	—
GET	/api/user/:id	ct.findById	read user
GET	/api/user/:id/permission	ct.findPermissionByUserId	enforced in the service
GET	/api/user/:id/oa-access	ct.getOaAccess	read user
PUT	/api/user/:id/oa-access	ct.updateOaAccess	update user
POST	/api/user	ct.create	create user
POST	/api/user/:id/admin-reset-password	ct.adminResetPassword	update user
PUT	/api/user/:id	ct.update	update user
PUT	/api/user/:id/status	ct.updateStatusById	update user
DELETE	/api/user/:id	ct.delete	delete user
DELETE	/api/user/:id/hard	ct.hardDelete	auth.SuperAdmin()

Every route places ct.jwtLogin (JwtLoginAuth) first in its middleware chain.

Connections to Other Services

• Permissions — the policy metadata is PolicyModuleUser, but it is not yet enforced. The only guard actually applied today is auth.SuperAdmin() on the hard-delete route.
• Tables — user, user_line_oa, organization, system_role, system_role_module, organization_module, password_history, forgot_password
• Cross-module — calls systemmodule.Service.FindAllObject to map module_id values to module names inside FindPermissionByUserID.
• Storage — avatar uploads go through internal/storage.
• Note — the user-driven forgot / reset / change password flows do not live here; they belong to the auth module.