Files

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

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

2026-01-16 13:42:10 +08:00

5.1 KiB

Raw Blame History

CTO 代码审查报告：AI临床研究平台部署架构

审核对象：5份独立部署文档 (Dify/Python/Node/Frontend/PostgreSQL)
审核人：虚拟架构师
结论：A- (优秀)。架构设计符合云原生理念，成本与扩展性平衡良好。但存在网络出口和依赖闭环两个关键风险点需解决。

1. 模块级深度审计 (Module-Level Audit)

✅ 1.1 前端 Nginx (SAE)

优点：多阶段构建优秀（体积小）；环境变量注入方案（envsubst）非常专业，解决了静态页面无法动态配置后端的难题。
修正建议：
- 确认 nginx.conf 中开启 gzip，这对 React 大体积 JS 文件至关重要。
- 检查 Nginx 的 client_max_body_size 配置。医疗 PDF/Excel 可能超过默认的 1MB，建议设置为 50M。

✅ 1.2 后端 Node.js (SAE)

优点：Prisma "反向同步" 流程非常务实，解决了开发习惯不规范的问题。Postgres-Only 的架构极大地降低了运维负担。
修正建议：
- 连接泄漏风险：Python 服务如果响应慢，后端的 HTTP Client 设置超时了吗？建议设置 timeout: 30s，防止后端连接数堆积。

✅ 1.3 Python 微服务 (SAE)

优点：明确指出了 libGL 等系统依赖问题，这是 Python 容器化最大的坑，文档已提前规避。
修正建议：
- OOM 风险：Python 进程（尤其是 PyMuPDF/OCR）非常吃内存。在 2G 内存限制下，务必限制并发数（Gunicorn Workers 不要超过 2 个）。

✅ 1.4 Dify (ECS)

优点：选择了 ECS 部署以保证数据私有化，同时使用 Swap 防止 OOM，非常懂行。
修正建议：
- 安全性：ECS 的 Redis 端口 (6379) 和 Weaviate 端口 (8080) 绝对不要对公网开放。仅允许 localhost 和 VPC 内网访问。

✅ 1.5 数据库 (RDS)

优点：Schema 隔离设计极佳。
修正建议：
- Dify 数据库隔离：确认 Dify 使用的是独立的 dify_prod 库，不要和业务表混在 ai_clinical_research 库中，防止 Dify 升级脚本误删业务表。

2. 跨模块集成风险 (Integration Risks)

🚨 风险一：SAE 的"孤岛效应" (Internet Access)

问题：SAE 部署在 VPC 内，默认没有公网出口。
场景：后端调用 DeepSeek API、Python 下载公网 PDF、NPM 安装依赖（构建时）。
对策：必须在 VPC 中配置 NAT 网关 (推荐) 或确保 SAE 有绑定公网 IP 的能力。否则上线当天所有 AI 功能都会超时。

🔄 风险二：部署依赖死锁 (Deployment Deadlock)

现象：
1. 后端启动需要 DIFY_API_KEY。
2. DIFY_API_KEY 需要 Dify 启动并人工登录后才能生成。
3. 后端如果配置了"健康检查失败则重启"，在填入 Key 之前会无限重启。
对策：首次部署时，后端环境变量 DIFY_API_KEY 可以先填个假值（如 temp），让服务跑起来。等 Dify 部署好拿到真 Key 后，更新 SAE 配置并重启。

🌐 风险三：前端与 Dify 的跨域 (CORS)

问题：前端直接调用后端（通过 Nginx 代理）没问题。但如果前端需要直接嵌入 Dify 的 Web UI（如 iframe）或直接调用 Dify API（绕过后端），会遇到 CORS。
对策：坚持**"所有请求走后端"**的原则。前端 -> Nginx -> 后端 -> Dify。不要让前端直连 Dify，既安全又避免 CORS。

3. 架构关系图谱

4. 给 1-2 人团队的生存建议

省钱黑科技：
- SAE 2.0 有闲置计费功能。开发环境（测试环境）务必开启，没人用时不收 CPU/内存费。
- RDS 购买通用型 (2核4G) 即可，不要买独享型，够用很久。
不要自建监控：
- 直接用阿里云 ARMS (应用实时监控服务) 的免费额度或基础版。不要自己搭 Prometheus + Grafana，维护成本太高。
数据备份是底线：
- RDS 开启自动备份（保留7天）。
- ECS 上的 Dify docker-compose.yaml 和 .env 文件，务必在本地或 Git 私有仓库备份一份。ECS 没了可以重买，配置文件没了就得重配。
开发效率：
- 利用 ECS 做跳板机，本地直连 RDS 开发。不要每次都写代码去查数据。

最终结论：这套架构设计得非常扎实，完全可以支撑从 0 到 10 万用户的规模。请重点解决 "SAE 访问公网 (NAT)" 这个问题，即可开始部署。

5.1 KiB Raw Blame History Unescape Escape