236 lines
8.2 KiB
Markdown
236 lines
8.2 KiB
Markdown
# 功能需求实现报告
|
||
|
||
## 📋 需求列表
|
||
|
||
根据用户提供的需求，以下是各项功能的实现状态：
|
||
|
||
### ✅ 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` 数据库表
|
||
```prisma
|
||
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. **评估多账号登录需求**：确认用户是否真的需要多账号登录功能，如果不需要，可以暂缓实现
|
||
|