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
64 lines
4.1 KiB
Markdown
64 lines
4.1 KiB
Markdown
# **IIT Manager Agent 多端角色与微信端开发指南**
|
||
|
||
## **1\. 微信端选型分析：为什么必须是企业微信？**
|
||
|
||
在临床研究的长周期中，消息触达的可靠性是第一位的。
|
||
|
||
| 特性 | 微信订阅号 | 微信服务号 | 企业微信 (WeCom) |
|
||
| :---- | :---- | :---- | :---- |
|
||
| **消息主动性** | 极弱（折叠在文件夹） | 中（模板消息有次数限制） | **强**（可直接发给外部联系人/群） |
|
||
| **48小时限制** | 有 | 有（用户不互动则无法发信） | **无**（只要是外部联系人，随时触达） |
|
||
| **身份属性** | 媒体/信息流 | 机构/品牌展示 | **专业/职业属性**（实名认证医生） |
|
||
| **PI 适用性** | 不推荐 | 一般（仅用于简单日报） | **推荐**（用于决策确认与紧急通知） |
|
||
| **患者适用性** | 不推荐 | 不推荐（无法长效随访） | **推荐**（CRC通过企微加患者微信） |
|
||
|
||
## **2\. 规模化部署下的品牌与归属感方案**
|
||
|
||
针对“100 个项目、47 家医院”的规模化场景，传统的“一院一授权”不可行。建议采用 **“中央应用 \+ 动态品牌”** 的架构。
|
||
|
||
### **2.1 品牌展示策略 (Branding Strategy)**
|
||
|
||
1. **企业简称优化**：申请企业微信认证时，将简称设置为“壹证循临床研究”或“临床研究服务中心”（需配合相关商标或软件著作权证明）。
|
||
2. **多应用隔离**：针对不同项目创建不同的“自建应用”。
|
||
* 应用 A：名为“北医三院骨质疏松项目”
|
||
* 应用 B：名为“北大肿瘤肺癌研究组”
|
||
3. **消息发送者自定义**：通过企业微信 API，在给 PI 推送消息时，可以将卡片的摘要（Title）动态修改为具体项目组名称。
|
||
|
||
### **2.2 小程序 vs 企业微信：深度对比**
|
||
|
||
| 维度 | 微信小程序 | 企业微信应用 |
|
||
| :---- | :---- | :---- |
|
||
| **品牌突出度** | **极高**（完全独立命名、Logo） | **中**（受限于企业主体的后缀） |
|
||
| **通知时效性** | **低**（需用户主动订阅，有次数限制） | **极高**（消息直达聊天列表） |
|
||
| **交互深度** | **强**（复杂的表单、可视化图表） | **中**（多为简单的卡片和 H5 链接） |
|
||
| **患者依从性** | 依赖用户主动打开习惯 | 依赖 CRC 的私域互动（更强） |
|
||
|
||
## **3\. 推荐架构：“通知-落地”双轨模式**
|
||
|
||
为了平衡“通知及时性”与“医院品牌感”，推荐以下混合方案：
|
||
|
||
1. **统一通知中枢 (WeCom)**：
|
||
* 使用壹证循统一的企业微信主体。
|
||
* 负责所有项目的：访视提醒、质控警报、日报推送。
|
||
* 用户感官：收到一条来自“临床研究助理”的消息。
|
||
2. **多租户品牌落地 (Mini-Program / H5)**：
|
||
* PI 或 CRC 点击企微消息，跳转到对应项目的**微信小程序**。
|
||
* 小程序界面顶部显著展示：\[北京大学肿瘤医院\] 及其 Logo。
|
||
* 业务逻辑：小程序通过 project\_id 自动渲染对应的品牌元素。
|
||
|
||
## **4\. 微信端开发准备清单 (针对 100+ 项目规模)**
|
||
|
||
1. **资质准备**：
|
||
* \[ \] **企业微信代开发模式**：如果希望未来更灵活，可以申请成为“企业微信服务商”。
|
||
* \[ \] **多域名备案**：准备 1-2 个通用的学术性域名（如 research-support.com）。
|
||
2. **数据隔离技术**：
|
||
* \[ \] **WeCom-ID 映射表**：在 iit\_schema 中记录 user\_id 在不同项目应用中的 OpenID。
|
||
* \[ \] **消息模板引擎**：支持根据不同项目动态生成卡片文案。
|
||
|
||
## **5\. 结论**
|
||
|
||
* **关于更名**：腾讯不允许无资质的泛指词更名。建议以“公司名+服务中心”作为主体，以“项目组”作为应用名。
|
||
* **关于小程序**：小程序不适合作为“第一提醒入口”，但非常适合作为“第一展示窗口”。
|
||
* **最终建议**：**用企业微信推消息，用小程序看报表和填表。** 这样既解决了 47 家医院的对接难点，又通过小程序给足了 PI 面子。
|
||
|
||
**版本**：V3.1 (规模化修正版) | **最后更新**：2025-12-30 |