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