Develop/AIclinicalresearch
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
HaHafeng
2026-01-16 13:42:10 +08:00
parent 98d862dbd4
commit 66255368b7
560 changed files with 70424 additions and 52353 deletions
Download Patch File Download Diff File Expand all files Collapse all files

111
docs/03-业务模块/IIT Manager Agent/02-技术设计/IIT Manager Agent 多端交互流程与权限设计 (V1.0).md
View File

@@ -1,76 +1,85 @@
# **IIT Manager Agent 螟夂ｫｯ莠､莠呈ｵ∫ｨ倶ｸ取揀髯占ｮｾ隶?(V1.0)**
# **IIT Manager Agent 多端交互流程与权限设计 (V1.0)**
## **1\. 譬ｸ蠢<EFBFBD>ｧ定牡螳壻ｹ我ｸ守ｻ育ｫｯ遏ｩ髦?*
## **1\. 核心角色定义与终端矩阵**
系统通过“基础角色 \+ 扩展权限”模式，支持单中心与多中心项目的灵活配置。
邉ｻ扈滄€夊ｿ<EFBFBD>€懷渕遑€隗定牡 \+ 謇ｩ螻墓揀髯絶€晄ｨ｡蠑擾ｼ梧髪謖∝黒荳ｭ蠢<EFBDAD>ｸ主､壻ｸｭ蠢<EFBDAD>｡ｹ逶ｮ逧<EFBDAE><E980A7>豢ｻ驟咲ｽｮ縲?
| 角色代码 | 角色名称 | 核心职责 | 主要终端 | 核心权限 |
| :---- | :---- | :---- | :---- | :---- |
| **SYS\_ADMIN** | 邉ｻ扈溽ｮ｡逅<EFBFBD><EFBFBD>?| 蟷ｳ蜿ｰ蛻晏ｧ句喧縲∝､夂ｧ滓姐邂｡逅<EFBDA1>€．ify 遏･隸<EFBDA5>ｺ鍋ｻｴ謚?| PC 遶?(Admin Portal) | 蜈ｨ螻€驟咲ｽｮ縲∬ｵ<EFBFBD>ｺ仙<EFBFBD>驟?|
| **PROJECT\_PI** | 鬘ｹ逶ｮ雍溯ｴ｣莠?(PI) | 鬘ｹ逶ｮ霑帛ｺｦ逶第而縲<E8808C>㍾螟ｧ蛛冗ｦｻ蜀ｳ遲悶€∵匱閭ｽ謚･陦ｨ譟･逵?| 蠕ｮ菫｡遶?(莨∝ｾｮ騾夂衍+蟆冗ｨ句ｺ? | 蠖ｱ蟄千憾諤∵怙扈亥ｮ｡謇ｹ縲∝ｯｼ蜃ｺ謚･陦?|
| **CRC\_OPERATOR** | 蜊剰ｰ<EFBFBD><EFBFBD>?(CRC) | 謨ｰ謐ｮ蠖募<EFBFBD>縲、I 蟒ｺ隶ｮ螟肴<E89E9F>ｸ縲∵ぅ閠<E38185>囂隶ｿ謇ｧ陦?| REDCap (蠖募<EFBFBD>) \+ PC Workbench | 雍ｨ逍大､<EFBFBD>炊縲∵焚謐ｮ驥<EFBFBD>寔縲∵ぅ閠<EFBFBD>ｺ貞<EFBFBD>?|
| **SUBJECT\_PATIENT** | 謔｣閠?(蜿苓ｯ戊€? | 謗･謾ｶ謠宣<E8ACA0>縲∝暢隸｢遲皮桝縲、E/髫剰ｮｿ荳頑冠 | 荳ｪ莠ｺ蠕ｮ菫｡ (H5/蟆冗ｨ句ｺ? | 莉ｻ蜉｡蜿埼ｦ医€<E58CBB>琉遲泌暢隸?|
| **SUB\_I / CO\_PI** | 蟄蝉ｸｭ蠢<EFBFBD>ｴ溯ｴ｣莠ｺ | 蛻<>ｸｭ蠢<EFBDAD>焚謐ｮ譟･逵九€∵悽荳ｭ蠢<EFBDAD>ｵ∫ｨ句ｮ｡謇ｹ | 蠕ｮ菫｡遶?| 莉<>剞譛ｬ荳ｭ蠢<EFBDAD>噪謨ｰ謐ｮ譚<EFBDAE>剞 |
| **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\. 霍ｨ扈育ｫｯ譬ｸ蠢<EFBFBD>ｺ､莠呈ｵ∫ｨ?(User Journeys)**
## **2\. 跨终端核心交互流程 (User Journeys)**
### **2.1 智能质控与影子决策流 (核心闭环)**
隸･豬∫ｨ倶ｽ鍋鴫莠<EFBFBD>€彝EDCap 蠖募<EFBFBD> \-\> AI 蜿醍鴫 \-\> Workbench 螟肴<EFBFBD>ｸ \-\> 蝗槫<EFBFBD> REDCap窶晉噪騾ｻ霎代€?
1. **謨ｰ謐ｮ莠ｧ逕<EFBDA7>**<EFBFBD>咾RC 蝨?**REDCap 蜴溽函逡碁擇**謠蝉ｺ､蜿苓ｯ戊€?V1 隶ｿ隗<EFBDBF>焚謐ｮ縲?
2. **逶大成荳取耳逅?*<2A>哢ode.js 謗･謾ｶ Webhook<6F>碁ｩｱ蜉?**QC Agent** 隹<>畑 Dify RAG 譽€邏?Protocol<6F>悟書邇ｰ騾ｻ霎醍泝逶ｾ縲?
3. **蠖ｱ蟄千函謌<EFBFBD>**<EFBFBD>夂ｳｻ扈溷惠 **Postgres (iit\_schema)** 荳ｭ逕滓<E98095>荳€譚｡迥ｶ諤∽ｸｺ PROPOSED 逧<>ｽｱ蟄占ｮｰ蠖輔€?
4. **蜊ｳ譌ｶ謠宣<EFBFBD>**<EFBFBD>?
* **PC 遶?*<2A>咾RC 逧?Workbench 莉ｻ蜉｡蜊｡迚<EFBDA1>ｮ樊慮譖ｴ譁ｰ縲?
* **蠕ｮ菫｡遶?*<2A>夊凶荳ｺ荳･驥崎ｿ晁レ<E69981>瑚<EFBFBD>蜉ｨ扈?PI/CRC 謗ｨ騾∽ｼ∝ｾｮ騾夂衍縲?
5. **螟肴<EFBFBD>ｸ蜀ｳ遲<EFBFBD>**<EFBFBD>咾RC 逋ｻ蠖<EFBDBB> **PC Workbench**<EFBFBD>梧衍逵玖ｯ∵紺體ｾ蟇ｹ豈斐€?
6. **豁｣蠑乗鴬陦<EFBFBD>**<EFBFBD>咾RC 轤ｹ蜃ｻ窶懃｡ｮ隶､蟷ｶ譖ｴ譁ｰ窶晢ｼ檎ｳｻ扈溯ｰ<E6BAAF>畑 REDCap API 蟆<>ｿｮ豁｣蛟ｼ謌冶ｴｨ逍醍憾諤∝<E8ABA4>蝗?**REDCap**<2A>悟ｽｱ蟄占ｮｰ蠖慕憾諤∬ｽｬ荳?EXECUTED縲?
该流程体现了“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 任务驱动与患者互动流**
隸･豬∫ｨ倶ｽ鍋鴫莠<EFBFBD>€應ｻｻ蜉｡蠑墓<EFBFBD>?\-\> 莨∝ｾｮ隗ｦ霎ｾ \-\> AI 遏･隸<EFBDA5>ｺ灘屓螟坂€晉噪騾ｻ霎代€?
1. **莉ｻ蜉｡隗ｦ蜿<EFBDA6>**<EFBFBD>壻ｻｻ蜉｡蠑墓梼譽€豬句芦謔｣閠?P001 譏取律髴€蝗櫁ｮｿ<EFBDAE>檎憾諤∝序荳?DUE\_SOON縲?
2. **豸域<EFBFBD>謗ｨ騾?*<2A>夂ｳｻ扈滄€夊ｿ<E5A48A>**莨∽ｸ壼ｾｮ菫｡ API**<EFBFBD>御ｻ･ CRC 霄ｫ莉ｽ蜷第ぅ閠<E38185>ｾｮ菫｡蜿鷹€∵署驢偵€?
3. **謔｣閠<EFBFBD>ｿｽ髣?*<2A>壽ぅ閠<E38185>惠蠕ｮ菫｡蝗槫､搾ｼ壺€懈<C280>莉雁､ｩ髴€隕∝●闕ｯ蜷暦ｼ溪€昴€?
4. **AI 螟<>炊**<EFBFBD>?*Counseling Agent** 蝓ｺ莠<EFBDBA> Dify 遏･隸<EFBDA5>ｺ鍋函謌仙屓遲碑拷遞ｿ縲?
5. **莠ｺ蟾･莉句<EFBFBD>**<EFBFBD>?
* 闍･荳ｺ邂€蜊慕ｧ第勸<E7ACAC>窟gent 逶ｴ謗･蝗槫､阪€?
* 闍･豸牙所逕ｨ闕ｯ謖<EFBFBD>ｯｼ<EFBFBD>梧署驢<EFBFBD> CRC 蝨ｨ莨∝ｾｮ萓ｧ霎ｹ譬冗｡ｮ隶､隸･闕臥ｨｿ蜷主<E89CB7>蜿鷹€√€?
### **2.3 PI 螳剰ｧらｮ｡逅<EFBDA1>ｵ?*
该流程体现了“任务引擎 \-\> 企微触达 \-\> 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 提交的疑难问题进行远程批示。
1. **蜻ｨ譛滓ｱ<E6BB93>冠**<EFBFBD>?*Reporting Agent** 豈丞捉逕滓<E98095>扈溯ｮ｡謚･陦ｨ縲?
2. **蜩∫煙蛹門ｱ慕､?*<2A>啀I 謾ｶ蛻ｰ莨∝ｾｮ騾夂衍<E5A482>檎せ蜃ｻ霍ｳ霓ｬ閾ｳ**蟆冗ｨ句ｺ?*縲?
3. **螟夂ｧ滓姐騾る<E9A8BE>**<EFBFBD>壼ｰ冗ｨ句ｺ乗<EFBFBD>ｹ謐ｮ鬘ｹ逶ｮ ID 閾ｪ蜉ｨ蜉<EFBDA8>霓ｽ \[蛹怜現荳蛾劼\] 遲牙刀迚悟<E8BF9A>邏<EFBFBD>蜥<EFBFBD> Logo縲?
4. **遘ｻ蜉ｨ蜀ｳ遲<EFBDB3>**<EFBFBD>啀I 蝨ｨ蟆冗ｨ句ｺ丞<EFBDBA>蟇ｹ CRC 謠蝉ｺ､逧<EFBDA4>桝髫ｾ髣ｮ鬚倩ｿ幄｡瑚ｿ懃ｨ区音遉ｺ縲?
## **3\. 终端功能边界划分 (Function Boundary)**
| 蜉溯<EFBFBD>讓｡蝮<EFBFBD> | PC 邂｡逅<EFBDA1>遭髣ｨ謌?| PC Agent Workbench | 蠕ｮ菫｡蟆冗ｨ句ｺ?H5 | 莨∽ｸ壼ｾｮ菫｡騾夂衍 |
| 功能模块 | PC 管理员门户 | PC Agent Workbench | 微信小程序/H5 | 企业微信通知 |
| :---- | :---- | :---- | :---- | :---- |
| **鬘ｹ逶ｮ蛻晏ｧ句<EFBFBD>?* | 100% (荳贋ｼ<EFBFBD>譁ｹ譯<EFBFBD>) | 0% | 0% | 0% |
| **项目初始化** | 100% (上传方案) | 0% | 0% | 0% |
| **字段映射配置** | 100% | 0% | 0% | 0% |
| **謨ｰ謐ｮ雍ｨ謗ｧ螳｡譬ｸ** | 0% | 100% (豺ｱ蠎ｦ豈泌ｯｹ) | 20% (邏ｧ諤･遑ｮ隶? | 0% (莉<EFBFBD><EFBFBD>蜿? |
| **数据质控审核** | 0% | 100% (深度比对) | 20% (紧急确认) | 0% (仅入口) |
| **智能采集(OCR)** | 0% | 100% | 0% | 0% |
| **霑帛ｺｦ/鬟朱勦謚･陦ｨ** | 20% | 50% | 100% (邊ｾ鄒主庄隗<EFBFBD><EFBFBD>? | 10% (蜊｡迚<EFBFBD>遭隕<EFBFBD>) |
| **謔｣閠<EFBFBD>ｲ滄€夊ｮｰ蠖?* | 0% | 100% (蠖呈｡｣) | 0% | 100% (螳樊慮莠､莠<EFBFBD>) |
| **进度/风险报表** | 20% | 50% | 100% (精美可视化) | 10% (卡片摘要) |
| **患者沟通记录** | 0% | 100% (归档) | 0% | 100% (实时交互) |
## **4\. 譚<EFBFBD>剞荳主ｮ牙<EFBFBD>讓｡蝙?(Access Control)**
## **4\. 权限与安全模型 (Access Control)**
### **4.1 RBAC 权限设计**
邉ｻ扈滄㊦逕ｨ窶懷粥閭ｽ譚<EFBFBD><EFBFBD>?\+ 謨ｰ謐ｮ闌<EFBDAE>峩窶晏曙驥肴<E9A9A5>｡鬪鯉ｼ<E9AF89>
系统采用“功能权限 \+ 数据范围”双重校验：
* **功能权限 (Permission)**：决定能否点击“确认回写”、“导出报表”。
* **数据范围 (Scope)**：
* GLOBAL：可看所有中心数据（项目 PI）。
* SITE\_ONLY：仅限本中心（子中心 PI/CRC）。
* PATIENT\_ONLY：仅限本人（受试者）。
* **蜉溯<E89C89>譚<EFBFBD>剞 (Permission)**<2A>壼<EFBFBD>螳夊<E89EB3>蜷ｦ轤ｹ蜃ｻ窶懃｡ｮ隶､蝗槫<E89D97>窶昴€≫€懷ｯｼ蜃ｺ謚･陦ｨ窶昴€?
* **謨ｰ謐ｮ闌<EFBDAE>峩 (Scope)**<2A>?
* GLOBAL<41>壼庄逵区園譛我ｸｭ蠢<EFBDAD>焚謐ｮ<E8AC90>磯｡ｹ逶ｮ PI<50>峨€?
* SITE\_ONLY<4C>壻ｻ<E5A3BB>剞譛ｬ荳ｭ蠢<EFBDAD>ｼ亥ｭ蝉ｸｭ蠢<EFBDAD> PI/CRC<52>峨€?
* PATIENT\_ONLY<4C>壻ｻ<E5A3BB>剞譛ｬ莠ｺ<E88EA0>亥女隸戊€<E6888A>ｼ峨€?
### **4.2 异构系统身份映射 (Auth Bridge)**
* **REDCap Token 謇倡ｮ｡**<2A>壽ｯ丈ｸ?CRC/PI 逧<>ｴｦ謌ｷ荳句刈蟇<E58888>ｭ伜お蜈?REDCap API Token縲?
* **莨∝ｾｮ OpenID 扈大ｮ<EFBFBD>**<2A>壼惠 iit\_schema.user\_mapping 荳ｭ蟒ｺ遶?SystemUserID \<-\> WeComID 逧<EFBFBD>丐蟆<EFBFBD>ｼ檎｡ｮ菫晄ｶ域<EFBFBD>邊ｾ蜃<EFBFBD>耳騾√€?
## **5\. 謇ｩ螻墓€ｧ隶ｾ隶?(Future Roles)**
* **REDCap Token 托管**：每个 CRC/PI 的账户下加密存储其 REDCap API Token。
* **企微 OpenID 绑定**：在 iit\_schema.user\_mapping 中建立 SystemUserID \<-\> WeComID 的映射，确保消息精准推送。
蟇ｹ莠<EFBFBD> **Co-PI** 謌?**Sub-I** 遲芽ｧ定牡<E5AE9A>檎ｳｻ扈滓髪謖∝<E8AC96>?iit\_projects.roles 陦ｨ荳ｭ蜉ｨ諤∵ｷｻ蜉<EFBDBB>譚<EFBFBD>剞譬<E5899E>ｭｾ<EFBDAD><EFBDBE>
## **5\. 扩展性设计 (Future Roles)**
* can\_approve\_shadow\_state: 襍倶ｺ亥ｮ｡謇ｹ譚<EFBDB9>€?
* can\_view\_audit\_trail: 襍倶ｺ亥ｮ｡隶｡譟･逵区揀縲?
* can\_manage\_patients: 襍倶ｺ域ぅ閠<E38185>ｮ｡逅<EFBDA1>揀縲?
**迚域悽隸ｴ譏<EFBDB4>**<2A>啖1.0 蝓ｺ遑€迚?| **迥ｶ諤?*<2A>壼ｾ<E5A3BC>ｯ<EFBFBD>ｮ｡
对于 **Co-PI** 或 **Sub-I** 等角色，系统支持在 iit\_projects.roles 表中动态添加权限标签：
* can\_approve\_shadow\_state: 赋予审批权。
* can\_view\_audit\_trail: 赋予审计查看权。
* can\_manage\_patients: 赋予患者管理权。
**版本说明**：V1.0 基础版 | **状态**：待评审