HaHafeng
66255368b7
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
85 lines
4.8 KiB
Markdown
85 lines
4.8 KiB
Markdown
# **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”的逻辑。
|
||
|
||
1. **数据产生**：CRC 在 **REDCap 原生界面**提交受试者 V1 访视数据。
|
||
2. **监听与推理**：Node.js 接收 Webhook，驱动 **QC Agent** 调用 Dify RAG 检索 Protocol，发现逻辑矛盾。
|
||
3. **影子生成**：系统在 **Postgres (iit\_schema)** 中生成一条状态为 PROPOSED 的影子记录。
|
||
4. **即时提醒**：
|
||
* **PC 端**：CRC 的 Workbench 任务卡片实时更新。
|
||
* **微信端**：若为严重违背，自动给 PI/CRC 推送企微通知。
|
||
5. **复核决策**：CRC 登录 **PC Workbench**，查看证据链对比。
|
||
6. **正式执行**：CRC 点击“确认并更新”，系统调用 REDCap API 将修正值或质疑状态写回 **REDCap**，影子记录状态转为 EXECUTED。
|
||
|
||
### **2.2 任务驱动与患者互动流**
|
||
|
||
该流程体现了“任务引擎 \-\> 企微触达 \-\> AI 知识库回复”的逻辑。
|
||
|
||
1. **任务触发**：任务引擎检测到患者 P001 明日需回访，状态变为 DUE\_SOON。
|
||
2. **消息推送**：系统通过**企业微信 API**，以 CRC 身份向患者微信发送提醒。
|
||
3. **患者追问**：患者在微信回复：“我今天需要停药吗？”。
|
||
4. **AI 处理**：**Counseling Agent** 基于 Dify 知识库生成回答草稿。
|
||
5. **人工介入**：
|
||
* 若为简单科普，Agent 直接回复。
|
||
* 若涉及用药指导，提醒 CRC 在企微侧边栏确认该草稿后再发送。
|
||
|
||
### **2.3 PI 宏观管理流**
|
||
|
||
1. **周期汇报**：**Reporting Agent** 每周生成统计报表。
|
||
2. **品牌化展示**：PI 收到企微通知，点击跳转至**小程序**。
|
||
3. **多租户适配**：小程序根据项目 ID 自动加载 \[北医三院\] 等品牌元素和 Logo。
|
||
4. **移动决策**：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 基础版 | **状态**：待评审 |