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
102 lines
5.5 KiB
Markdown
102 lines
5.5 KiB
Markdown
# **权限与角色体系梳理报告 \- 审查反馈与修正建议**
|
||
|
||
审查对象： 00-权限与角色体系梳理报告\_v1.0.md
|
||
对比基准： 07-运营与机构管理端PRD\_v2.1.md
|
||
审查结论： 总体通过 (Approved with Modification)。基础架构设计扎实，需补充少量针对业务场景（医院配额、Prompt调试）的字段设计。
|
||
|
||
## **1\. 核心问题与差距分析 (Gap Analysis)**
|
||
|
||
虽然 v1.0 报告构建了坚实的 RBAC 基础，但在支撑 PRD v2.1 的特定业务场景时，存在以下缺失：
|
||
|
||
### **1.1 缺失“精细化配额分配”模型 (Critical)**
|
||
|
||
* **现状**：报告中设计了 tenant\_quotas 表，看似是针对租户的总配额。
|
||
* **PRD 要求**：医院端需要将配额分配给 **科室 (Department)** 或 **个人**。
|
||
* 修正建议：
|
||
需要引入 PRD v2.1 中定义的 TenantQuotaAllocation 表结构，支持 targetType ('DEPARTMENT' | 'USER')。
|
||
model TenantQuotaAllocation {
|
||
id Int @id @default(autoincrement())
|
||
tenantId String @map("tenant\_id") @db.Uuid
|
||
targetType String // 'DEPARTMENT' | 'USER'
|
||
targetKey String // DepartmentID 或 UserID
|
||
limitAmount BigInt // 分配额度
|
||
usedAmount BigInt @default(0)
|
||
|
||
@@unique(\[tenantId, targetType, targetKey\])
|
||
@@map("tenant\_quota\_allocations")
|
||
@@schema("platform\_schema")
|
||
}
|
||
|
||
### **1.2 缺失“Prompt 工程化”相关权限**
|
||
|
||
* **现状**：报告关注了通用的租户管理权限。
|
||
* **PRD 要求**：运营端需要 **Prompt 灰度预览** 功能。这意味着需要一个特殊的权限点 prompt:debug，允许用户在生产环境读取 Draft 数据。
|
||
* **修正建议**：在设计 permissions（如果打算做细粒度控制）或代码常量中，明确预留 PROMPT\_ADMIN 或 DEBUGGER 角色能力。
|
||
|
||
### **1.3 审计日志的合规性要求**
|
||
|
||
* **现状**：报告提到了 admin\_operation\_logs。
|
||
* **PRD 要求**：药企端 (Pharma) 对审计日志有 FDA 21 CFR Part 11 的合规要求（数据修改痕迹）。
|
||
* **修正建议**：确保 Log 表包含 beforeData 和 afterData (已包含，很好)，但建议增加 module 字段（区分是 IIT 模块的日志还是系统配置日志），以便药企端只查询自己相关的日志。
|
||
|
||
## **2\. 数据库设计审查 (Schema Review)**
|
||
|
||
### **2.1 用户表统一策略 (User Table)**
|
||
|
||
你的决策：保留 platform\_schema.users，删除 public.users。
|
||
评价：✅ 完全正确。
|
||
提醒：迁移数据时，务必注意 public.users 中的 id 如果不是 UUID 格式（如果是旧系统生成的），需要做映射处理，否则关联外键会报错。
|
||
|
||
### **2.2 租户成员表命名 (Naming Convention)**
|
||
|
||
你的设计：TenantUser / tenant\_users
|
||
PRD 设计：TenantMember / tenant\_members
|
||
建议：建议统一使用 TenantMember。因为 "User" 通常指登录账号实体，而 "Member" 指某种组织关系中的身份。这种语义区分在代码中（如 member.role vs user.role）会更清晰。
|
||
|
||
### **2.3 部门表结构 (Department)**
|
||
|
||
你的设计：支持树形结构 (parentId)。
|
||
评价：✅ 优秀。这为未来支持大型三甲医院的复杂科室结构（内科 \-\> 心内科 \-\> 一病区）打下了基础。
|
||
|
||
## **3\. 技术路线可行性评估**
|
||
|
||
### **3.1 JWT 方案**
|
||
|
||
* **评价**：使用 jsonwebtoken \+ localStorage 是标准且成熟的 SPA 方案。
|
||
* **风险提示**：localStorage 容易受到 XSS 攻击。虽然 MVP 阶段可接受，但建议后续（特别是药企端上线前）考虑 **HttpOnly Cookie** 方案，或者在前端加强 XSS 防护。
|
||
|
||
### **3.2 权限中间件 (requireTenantAccess)**
|
||
|
||
* **评价**：这是多租户隔离的核心。
|
||
* **补充建议**：除了 API 层的中间件，强烈建议按照我之前提供的 **Prisma Extension** 方案，在数据库访问层（ORM）再加一道锁。
|
||
* *原因*：开发人员可能会忘记在 Controller 里加中间件，但很难绕过全局的 Prisma Client 扩展。
|
||
|
||
### **3.3 品牌定制 (Branding)**
|
||
|
||
* **评价**：报告中已包含 api/public/tenant-config 接口。
|
||
* **提醒**：该接口务必加上 **缓存 (Cache)** 控制（如 Cache-Control: public, max-age=3600），因为每个用户打开登录页都会调用，高并发下不要直接打数据库。
|
||
|
||
## **4\. 开发计划优化建议**
|
||
|
||
报告中的 **8.5 Phase 4 (运营端 MVP)** 和 **8.6 Phase 5 (专属登录)** 排期合理。
|
||
|
||
**建议调整点：**
|
||
|
||
1. **Phase 0 (数据迁移) 必须有回滚方案**：
|
||
* 在删除 public.users 之前，先将其重命名为 public.users\_backup，保留 1 周，防止迁移脚本有 Bug 导致数据丢失。
|
||
2. **提前定义“超级管理员”种子数据**：
|
||
* 在 Prisma Seed 脚本中，硬编码一个超级管理员账号（如 admin@yizhengxun.com），否则系统上线后你进不去后台。
|
||
3. **前端权限 Mock 的平滑过渡**：
|
||
* 在 Phase 3 对接时，不要直接删除 PermissionContext，而是修改其内部实现，从 API 获取数据替代 Mock 数据，这样可以最小化改动前端业务代码。
|
||
|
||
## **5\. 总结**
|
||
|
||
这份《权限与角色体系梳理报告》是一个非常棒的工程起点。它没有过度设计，准确抓住了 MVP 的核心。
|
||
|
||
**下一步行动指令：**
|
||
|
||
1. **采纳**：将表名 TenantUser 修改为 TenantMember。
|
||
2. **增加**：在 Schema 中增加 TenantQuotaAllocation 表（参考 1.1）。
|
||
3. **执行**：按照报告中的 Phase 0 \- Phase 6 开始执行。
|
||
|
||
**结论：** 文档质量高，风险可控，**可以开始开发**。 |