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
3.5 KiB
3.5 KiB
REDCap 生产环境部署：ECS vs SAE 深度决议报告
1. 核心结论：认可 ECS 优先策略
针对 IIT Manager Agent 项目，我们决定将 REDCap 生产环境部署在 ECS (Docker 模式) 运行，而不是 SAE。
为什么我们“认错”并转向 ECS？
在讨论 AI 后端时，SAE 的免运维特性很吸引人，但 REDCap 的三个“致命特性”决定了它在 SAE 上会极其痛苦：
- Cron 依赖（心跳丢失）：REDCap 每分钟都需要运行一次 cron.php。在 SAE 中，你得额外买 SchedulerX 服务；在 ECS，只需一行 crontab 就能搞定且 100% 可靠。
- Session 粘滞（掉线噩梦）：REDCap 默认将会话存本地。SAE 是多实例的，如果没做 Redis 共享，用户登录后会反复掉线，2 人团队去修这个 Bug 会耗费大量时间。
- 文件系统 POSIX 依赖：REDCap 像 10 年前的软件一样极其依赖本地文件夹读写。SAE 必须挂载 NAS，网络延迟会拖慢整个系统的响应。
2. 深度对比：务实派的决策依据
| 维度 | ECS + Docker (我们的选择) | SAE (Serverless) | 结论 |
|---|---|---|---|
| 部署成本 | 低。入门级 ECS (2核4G) 约 1500元/年。 | 高。SAE + NAS + 闲置费用可能更贵。 | ECS 胜 |
| 配置复杂度 | 极简。只需运行 docker-compose.yml。 | 复杂。需解决共享存储、Session同步、定时任务。 | ECS 胜 |
| 系统透明度 | 透明。直接 docker logs 查看 PHP 日志。 | 黑盒。云原生链路长，报错时排查难度大。 | ECS 胜 |
| 可移植性 | 最强。这份 Docker 配置可以原封不动挪到医院内网。 | 差。医院内网通常没有 SAE 这种环境。 | ECS 胜 |
3. 2 人团队的“生存之道”
作为一个只有 2 人的团队，我们的时间应该花在 Agent 的 Prompt 调优 和 业务逻辑 上，而不是花在“调试云产品之间的连接”上。
- ECS 方案：你就像拥有了一台真正的电脑。文件在哪、日志在哪、数据库连没连上，你一眼就能看清。
- SAE 方案：你会陷入“为什么挂载了 NAS 还是没写权限？”、“为什么 Cron 没触发？”这种与业务无关的琐事中。
4. 最终定稿：混合架构蓝图
我们将采取**“混合云”**的思路，发挥各自的长处：
4.1 数据平面 (Data Layer) -> 部署在 ECS
- 组件：REDCap (Apache + PHP 8.1)。
- 方式：使用 Docker-Compose 运行。
- 存储：附件存储在 ECS 挂载的云盘；数据库连接 RDS MySQL。
- 优势：保证了 EDC 系统的绝对稳定和传统运维的简便。
4.2 控制平面 (AI Agent Layer) -> 部署在 SAE
- 组件：Node.js 后端、Python 算法、AI 前端。
- 方式：Serverless 部署。
- 优势：利用 SAE 处理 AI 这种流量波动大、需要弹性伸缩的模块。
5. 对后续开发的意义
- 本地环境即生产环境：由于 ECS 跑的是 Docker，你在本地 03-REDCap本地部署方案.md 里写的代码，直接就能上线，没有任何“环境漂移”。
- 离线交付预演：如果未来医院要求内网部署，我们已经有了一套完整的、基于 ECS/Docker 的交付包，这比 SAE 方案更容易被医院 IT 接受。
当前状态：Deployment Strategy Locked | 建议：立即执行基于 ECS 的生产环境搭建。