Files

HaHafeng 66255368b7 feat(admin): Add user management and upgrade to module permission system

Features - User Management (Phase 4.1):
- Database: Add user_modules table for fine-grained module permissions
- Database: Add 4 user permissions (view/create/edit/delete) to role_permissions
- Backend: UserService (780 lines) - CRUD with tenant isolation
- Backend: UserController + UserRoutes (648 lines) - 13 API endpoints
- Backend: Batch import users from Excel
- Frontend: UserListPage (412 lines) - list/filter/search/pagination
- Frontend: UserFormPage (341 lines) - create/edit with module config
- Frontend: UserDetailPage (393 lines) - details/tenant/module management
- Frontend: 3 modal components (592 lines) - import/assign/configure
- API: GET/POST/PUT/DELETE /api/admin/users/* endpoints

Architecture Upgrade - Module Permission System:
- Backend: Add getUserModules() method in auth.service
- Backend: Login API returns modules array in user object
- Frontend: AuthContext adds hasModule() method
- Frontend: Navigation filters modules based on user.modules
- Frontend: RouteGuard checks requiredModule instead of requiredVersion
- Frontend: Remove deprecated version-based permission system
- UX: Only show accessible modules in navigation (clean UI)
- UX: Smart redirect after login (avoid 403 for regular users)

Fixes:
- Fix UTF-8 encoding corruption in ~100 docs files
- Fix pageSize type conversion in userService (String to Number)
- Fix authUser undefined error in TopNavigation
- Fix login redirect logic with role-based access check
- Update Git commit guidelines v1.2 with UTF-8 safety rules

Database Changes:
- CREATE TABLE user_modules (user_id, tenant_id, module_code, is_enabled)
- ADD UNIQUE CONSTRAINT (user_id, tenant_id, module_code)
- INSERT 4 permissions + role assignments
- UPDATE PUBLIC tenant with 8 module subscriptions

Technical:
- Backend: 5 new files (~2400 lines)
- Frontend: 10 new files (~2500 lines)
- Docs: 1 development record + 2 status updates + 1 guideline update
- Total: ~4900 lines of code

Status: User management 100% complete, module permission system operational

2026-01-16 13:42:10 +08:00

4.8 KiB

Raw Blame History

IIT Manager Agent 多端交互流程与权限设计 (V1.0)

1. 核心角色定义与终端矩阵

系统通过“基础角色 + 扩展权限”模式，支持单中心与多中心项目的灵活配置。

角色代码	角色名称	核心职责	主要终端	核心权限
SYS_ADMIN	系统管理员	平台初始化、多租户管理、Dify 知识库维护	PC 端 (Admin Portal)	全局配置、资源分配
PROJECT_PI	项目负责人 (PI)	项目进度监控、重大偏离决策、智能报表查看	微信端 (企微通知+小程序)	影子状态最终审批、导出报表
CRC_OPERATOR	协调员 (CRC)	数据录入、AI 建议复核、患者随访执行	REDCap (录入) + PC Workbench	质疑处理、数据采集、患者互动
SUBJECT_PATIENT	患者 (受试者)	接收提醒、咨询答疑、AE/随访上报	个人微信 (H5/小程序)	任务反馈、问答咨询
SUB_I / CO_PI	子中心负责人	分中心数据查看、本中心流程审批	微信端	仅限本中心的数据权限

2. 跨终端核心交互流程 (User Journeys)

2.1 智能质控与影子决策流 (核心闭环)

该流程体现了“REDCap 录入 -> AI 发现 -> Workbench 复核 -> 回写 REDCap”的逻辑。

数据产生：CRC 在 REDCap 原生界面提交受试者 V1 访视数据。
监听与推理：Node.js 接收 Webhook，驱动 QC Agent 调用 Dify RAG 检索 Protocol，发现逻辑矛盾。
影子生成：系统在 Postgres (iit_schema) 中生成一条状态为 PROPOSED 的影子记录。
即时提醒：
- PC 端：CRC 的 Workbench 任务卡片实时更新。
- 微信端：若为严重违背，自动给 PI/CRC 推送企微通知。
复核决策：CRC 登录 PC Workbench，查看证据链对比。
正式执行：CRC 点击“确认并更新”，系统调用 REDCap API 将修正值或质疑状态写回 REDCap，影子记录状态转为 EXECUTED。

2.2 任务驱动与患者互动流

该流程体现了“任务引擎 -> 企微触达 -> AI 知识库回复”的逻辑。

任务触发：任务引擎检测到患者 P001 明日需回访，状态变为 DUE_SOON。
消息推送：系统通过企业微信 API，以 CRC 身份向患者微信发送提醒。
患者追问：患者在微信回复：“我今天需要停药吗？”。
AI 处理：Counseling Agent 基于 Dify 知识库生成回答草稿。
人工介入：
- 若为简单科普，Agent 直接回复。
- 若涉及用药指导，提醒 CRC 在企微侧边栏确认该草稿后再发送。

2.3 PI 宏观管理流

周期汇报：Reporting Agent 每周生成统计报表。
品牌化展示：PI 收到企微通知，点击跳转至小程序。
多租户适配：小程序根据项目 ID 自动加载 [北医三院] 等品牌元素和 Logo。
移动决策：PI 在小程序内对 CRC 提交的疑难问题进行远程批示。

3. 终端功能边界划分 (Function Boundary)

功能模块	PC 管理员门户	PC Agent Workbench	微信小程序/H5	企业微信通知
项目初始化	100% (上传方案)	0%	0%	0%
字段映射配置	100%	0%	0%	0%
数据质控审核	0%	100% (深度比对)	20% (紧急确认)	0% (仅入口)
智能采集(OCR)	0%	100%	0%	0%
进度/风险报表	20%	50%	100% (精美可视化)	10% (卡片摘要)
患者沟通记录	0%	100% (归档)	0%	100% (实时交互)

4. 权限与安全模型 (Access Control)

4.1 RBAC 权限设计

系统采用“功能权限 + 数据范围”双重校验：

功能权限 (Permission)：决定能否点击“确认回写”、“导出报表”。
数据范围 (Scope)：
- GLOBAL：可看所有中心数据（项目 PI）。
- SITE_ONLY：仅限本中心（子中心 PI/CRC）。
- PATIENT_ONLY：仅限本人（受试者）。

4.2 异构系统身份映射 (Auth Bridge)

REDCap Token 托管：每个 CRC/PI 的账户下加密存储其 REDCap API Token。
企微 OpenID 绑定：在 iit_schema.user_mapping 中建立 SystemUserID <-> WeComID 的映射，确保消息精准推送。

5. 扩展性设计 (Future Roles)

对于 Co-PI 或 Sub-I 等角色，系统支持在 iit_projects.roles 表中动态添加权限标签：

can_approve_shadow_state: 赋予审批权。
can_view_audit_trail: 赋予审计查看权。
can_manage_patients: 赋予患者管理权。

版本说明：V1.0 基础版 | 状态：待评审

4.8 KiB Raw Blame History Unescape Escape