flnxi-Wu/docs/FEATURE_REQUESTS_IMPLEMENTATION.md

功能需求实现报告

📋 需求列表

根据用户提供的需求，以下是各项功能的实现状态：

✅ 1. 用户管理页面的树形结构根为最高权限账号

状态：已实现

实现内容：

• 修改 app/api/admin/users/route.ts，确保返回 isSuperAdmin 和 managedDepartment 字段
• 更新 app/admin/page.tsx 中的 getUserTreeData() 函数，正确识别最高权限账号
• 用户管理页面以最高权限账号为根节点显示树形结构
• 如果没有最高权限账号，fallback到显示管理员列表

代码位置：

• app/api/admin/users/route.ts (第18-39行)
• app/admin/page.tsx (第862-907行, 第1188-1396行)

---

✅ 2. 部门管理员账号显示合并到部门内置顶

状态：已实现

实现内容：

• 在 getUsersByDepartmentWithAdminPinned() 函数中，确保部门管理员在部门用户列表的最前面
• 部门管理员显示特殊的"部门管理员"徽标
• 普通用户显示在部门管理员之后

代码位置：

• app/admin/page.tsx (第877-889行, 第1282-1310行)

---

✅ 3. 系统第一个注册的账号自动设置为最高权限

状态：已实现

实现内容：

• 在 app/api/auth/register/route.ts 中，检查用户总数
• 如果用户总数为0（第一个用户），自动设置 isSuperAdmin: true
• 确保系统初始化时第一个注册的用户获得最高权限

代码位置：

• app/api/auth/register/route.ts (第82-94行)

---

✅ 4. 激活功能开关只有最高权限账号可以操作

状态：已实现

实现内容：

• 在 app/admin/settings/page.tsx 中，激活功能开关只有最高权限账号可以操作
• 非最高权限账号看到开关但无法操作（显示禁用状态和提示文字）
• 后端API (app/api/system-settings/route.ts) 也进行了权限检查

代码位置：

• app/admin/settings/page.tsx (第596-611行)
• app/api/system-settings/route.ts (第66-72行)

---

✅ 5. 邀请功能只有管理员及以上权限才能看到

状态：已实现

实现内容：

• 在 app/admin/page.tsx 中，邀请管理标签页只对管理员显示
• 后端API (app/api/invitations/route.ts) 也进行了权限检查，只有管理员及以上权限可以访问

代码位置：

• app/admin/page.tsx (第1013-1026行)
• app/api/invitations/route.ts (第9-19行, 第44-54行)

---

⚠️ 6. 多账号登录功能（支持每个网页登录不同账号）

状态：待实现

技术挑战：

• NextAuth默认使用Cookie存储session，所有标签页共享同一个session
• 要实现多账号登录，需要修改NextAuth的session存储机制

实现方案（建议）：

方案1：使用多窗口隔离（推荐）

• 每个浏览器窗口使用独立的session storage
• 通过 window.name 或 URL参数区分不同的登录会话
• 优点：实现相对简单，不需要修改NextAuth核心
• 缺点：同一窗口内的标签页仍然共享session

方案2：自定义Session存储

• 修改NextAuth配置，使用自定义session存储（如localStorage + 数据库）
• 每个标签页使用不同的session key
• 优点：完全支持多账号登录
• 缺点：需要大量修改现有代码，可能影响现有功能

方案3：使用iframe隔离

• 每个标签页使用iframe加载应用
• iframe之间隔离，可以使用不同的session
• 优点：完全隔离，支持多账号
• 缺点：用户体验较差，可能影响性能

推荐实现：方案1（多窗口隔离）

实现步骤：

1. 在登录时生成唯一的session key
2. 将session key存储到URL参数或window.name
3. 修改NextAuth配置，根据session key读取不同的session
4. 每个窗口使用独立的session存储

优先级：中 预计工作量：2-3天

---

⚠️ 7. 断点续传功能保存文件上传进度

状态：部分实现（仅localStorage）

当前实现：

• 上传进度保存在 localStorage 中
• 刷新页面后可以恢复表单数据，但文件需要重新选择
• 无法实现真正的断点续传（从上次中断的地方继续上传）

技术挑战：

• 真正的断点续传需要分块上传（chunked upload）
• 需要服务器支持分块上传和合并
• 需要数据库存储上传任务和进度

实现方案（建议）：

方案1：服务器端进度保存（简化版）

• 创建上传任务记录（数据库表）
• 在上传开始时创建任务，上传过程中更新进度
• 刷新页面后可以从服务器获取进度
• 优点：即使刷新页面也能看到进度
• 缺点：仍然无法实现真正的断点续传（文件需要重新上传）

方案2：完整的分块上传和断点续传

• 实现分块上传（将大文件分成多个小块）
• 每个小块独立上传，支持失败重试
• 服务器端存储已上传的块，支持从中断处继续
• 所有块上传完成后，服务器端合并文件
• 优点：真正的断点续传，支持网络中断恢复
• 缺点：实现复杂，需要大量开发和测试

推荐实现：方案1（服务器端进度保存）

实现步骤：

1. 创建 UploadTask 数据库表

   model UploadTask {
     id          String   @id @default(uuid())
     userId      String
     fileName    String
     fileSize    BigInt
     progress    Int      @default(0) // 0-100
     status      String   // pending/uploading/completed/failed
     metadata    Json?    // 存储表单数据
     createdAt   DateTime @default(now())
     updatedAt   DateTime @updatedAt
   }
   

2. 创建上传任务API

   • POST /api/upload/tasks - 创建上传任务
   • PATCH /api/upload/tasks/:id - 更新上传进度
   • GET /api/upload/tasks - 获取用户的上传任务列表

3. 修改上传组件

   • 上传开始时创建任务
   • 上传过程中定期更新进度
   • 上传完成后标记任务为完成

4. 修改上传页面

   • 页面加载时检查是否有未完成的上传任务
   • 显示未完成的任务和进度
   • 允许用户继续上传或取消任务

优先级：中 预计工作量：3-5天

---

📊 总结

已完成功能（5/7）

1. ✅ 用户管理页面树形结构根为最高权限账号
2. ✅ 部门管理员账号置顶显示
3. ✅ 系统第一个注册账号自动设置为最高权限
4. ✅ 激活功能开关权限控制
5. ✅ 邀请功能权限控制

待实现功能（2/7）

1. ⚠️ 多账号登录功能（需要修改NextAuth核心机制）
2. ⚠️ 断点续传进度保存（需要实现分块上传）

建议

1. 优先实现断点续传进度保存（方案1）：这是用户更常用的功能，且实现相对简单
2. 多账号登录功能：如果用户确实需要，建议使用方案1（多窗口隔离），实现相对简单且影响范围小

---

🔧 技术细节

数据库变更

• 无需新增数据库表（已完成的功能使用现有表结构）
• 待实现功能可能需要新增表（如 UploadTask 表）

API变更

• ✅ GET /api/admin/users - 已更新，返回 isSuperAdmin 和 managedDepartment
• ⚠️ 待实现：上传任务相关API（如 /api/upload/tasks）

前端变更

• ✅ app/admin/page.tsx - 已更新用户管理页面显示逻辑
• ✅ app/admin/settings/page.tsx - 已更新激活功能开关权限控制
• ⚠️ 待实现：多账号登录相关组件
• ⚠️ 待实现：上传进度保存相关组件

---

📝 注意事项

1. 最高权限账号：确保系统中至少有一个最高权限账号，否则某些功能可能无法正常使用
2. 权限检查：所有权限相关的功能都进行了前后端双重检查，确保安全性
3. 向后兼容：所有修改都保持了向后兼容，不会影响现有功能
4. 测试建议：建议在测试环境中充分测试所有功能，特别是权限控制相关功能

---

🚀 下一步行动

1. 立即部署已完成的修复：将已完成的5个功能部署到生产环境
2. 用户反馈：收集用户对已实现功能的反馈，确认是否符合预期
3. 实现断点续传进度保存：如果用户需要，实现方案1（服务器端进度保存）
4. 评估多账号登录需求：确认用户是否真的需要多账号登录功能，如果不需要，可以暂缓实现