feat(api): 完善家谱系统API客户端契约
- 实现家谱管理相关方法,包括创建、详情、概览、我的家谱和选项查询 - 添加家谱加入申请功能,支持申请、审核、取消和待审核列表操作 - 集成通知详情获取方法和通知ID安全验证机制 - 完善功德记录、谱文、相册、视频、祭祀活动的完整CRUD操作契约 - 实现家谱成员管理功能,包含成员列表、更新、移除和转让所有者操作 - 优化路径ID验证逻辑,拒绝不安全的数值ID并提供明确错误提示 - 更新测试用例以验证所有新增API方法的路径和请求体白名单机制
This commit is contained in:
@@ -0,0 +1,119 @@
|
||||
# 阶段 6 PC 功能页面设计
|
||||
|
||||
## 目标
|
||||
|
||||
把当前 PC YAML 与只读后端已经具备完整业务闭环、但前端页面缺失或仍处于待开发状态的功能全部落到现有个人中心中。不得使用 APP 接口、静态业务 ID、手填用户 ID/OSS ID、猜测响应字段或不可重读的停用流程。
|
||||
|
||||
## 实施范围
|
||||
|
||||
### 1. 谱文
|
||||
|
||||
- 开放 `profile-article.html`,提供正常谱文列表、分类筛选、详情和权限化操作入口。
|
||||
- 开放 `profile-article-edit.html`,提供新增与修改。
|
||||
- 新增成功后使用响应中的稳定 `articleId` 重读详情;修改后重读同一详情;删除后重读列表。
|
||||
- `categoryId` 只能来自真实文章分类响应;如果 PC 没有分类列表/选项源,则分类保持省略,不能输入 ID。
|
||||
- 封面只能通过文件选择和上传产生 `coverOssId`。
|
||||
- 普通列表和详情只读取正常状态,因此创建、修改固定提交 `status=0`,不开放停用。
|
||||
|
||||
### 2. 相册与照片
|
||||
|
||||
- 开放 `profile-album.html` 作为相册列表入口。
|
||||
- 新增 `profile-album-edit.html` 负责相册新增、修改。
|
||||
- 新增 `profile-album-detail.html` 负责相册详情、照片列表、照片上传和照片删除。
|
||||
- 相册封面与照片文件都必须通过统一分片上传产生 OSS ID。
|
||||
- 相册或照片写入后重新读取相册/照片列表;删除后重新读取并校正数量。
|
||||
- 普通接口只返回正常记录,因此不开放相册或照片停用状态。
|
||||
- 在没有 PC 文件访问 URL 时,只显示上传状态、标题和业务元数据,不拼接 OSS 地址。
|
||||
|
||||
### 3. 祭祀活动与祭品
|
||||
|
||||
- 保留 `profile-gift.html` 的“我的邀请”能力,并增加进入祭祀活动管理的入口。
|
||||
- 开放 `profile-gift-edit.html`,负责祭祀活动新增、修改。
|
||||
- 新增 `profile-ceremony.html`,负责活动列表和详情。
|
||||
- 新增 `profile-ceremony-detail.html`,负责活动详情、祭品列表、新增祭品、删除祭品和管理员邀约名单。
|
||||
- 活动封面通过统一上传产生 `coverOssId`。
|
||||
- 祭品金额按 YAML `number` 和后端 `BigDecimal` 边界处理;拒绝负数以及 JSON 数值序列化会改变输入值的金额。
|
||||
- 活动与祭品写操作成功后重新读取对应详情/列表。
|
||||
- 普通活动列表只返回正常记录,因此不开放活动停用。
|
||||
|
||||
### 4. 管理员邀约名单
|
||||
|
||||
- 邀约管理放在 `profile-ceremony-detail.html`,不与当前用户“我的邀请”响应流程混合。
|
||||
- 候选人来自 `/genealogy/pc/genealogies/{genealogyId}/members/options`。
|
||||
- 只允许选择拥有稳定 `appUserId` 的同家谱正常成员;当前登录人由后端拒绝,前端不猜测替代账号。
|
||||
- 保存时一次提交完整 `inviteeUserIds`;空数组表示取消所有仍未响应邀请,提交前必须二次确认。
|
||||
- 保存成功后重新读取活动邀请名单。
|
||||
|
||||
### 5. 指定账号绑定世系人物
|
||||
|
||||
- 在 `profile-tree.html` 启用 `SPECIFIED`,仅对具有家谱管理权限的用户开放。
|
||||
- 账号候选来自家谱成员选项;过滤没有 `appUserId` 的成员。
|
||||
- 用户看到成员昵称/成员名称,不看到或手填 `appUserId`。
|
||||
- `NONE`、`SELF`、`SPECIFIED` 继续遵守互斥请求规则;后端负责最终租户、账号状态和重复绑定校验。
|
||||
|
||||
### 6. 家谱成员管理
|
||||
|
||||
- 开放 `profile-family-admin.html`。
|
||||
- 提供成员列表、关键词搜索、成员详情摘要、成员资料/角色修改、成员移除、当前用户退出家谱和所有权转移。
|
||||
- 角色编辑只发送后端实际接受的 `admin/editor/member`,不允许把 `owner/visitor` 作为更新值。
|
||||
- 世系人物关联只能来自真实世系人物选项。
|
||||
- 所有权转移只能从当前正常成员记录中选择稳定 `memberId`。
|
||||
- 移除、退出和所有权转移必须有明确影响说明与二次确认;成功后重新读取成员列表和家谱上下文。
|
||||
|
||||
## 明确保留的阻断
|
||||
|
||||
- PC 没有世系关系解除接口,不创建“解除父母/配偶/兄弟关系”按钮。
|
||||
- PC 没有统一 OSS ID 访问地址解析能力;谱文封面、相册照片、祭祀封面只显示后端已直接返回的 URL,否则不猜 URL。
|
||||
- 普通谱文、相册、照片和祭祀列表过滤停用记录,详情也不能稳定读取停用项;前端固定提交正常状态。
|
||||
- 谱文 YAML 遗漏后端可选 `categoryId` 列表 query,且文章分类选项来源需要单独核实;未确认前不发送该 query。
|
||||
- YAML 中部分 OSS ID 为 string、Java DTO 为 Long;浏览器始终保存十进制字符串,上传响应是唯一来源。
|
||||
- YAML 的文章、相册和祭祀响应仍为泛型包装;页面只消费对应 PC 控制器明确返回的 `ArticleVo`、`AlbumVo`、`AlbumPhotoVo`、`CeremonyVo`、`CeremonyGiftVo`,不读取 APP 路径。
|
||||
|
||||
## 前端结构
|
||||
|
||||
- `utils/ApiClient.js` 是所有 method/path/query/body 的唯一 owner,并为每个 Body 使用字段白名单。
|
||||
- 每个业务模块使用独立脚本:
|
||||
- `public/js/article-pages.js`
|
||||
- `public/js/album-pages.js`
|
||||
- `public/js/ceremony-admin-pages.js`
|
||||
- `public/js/member-admin-pages.js`
|
||||
- `public/js/ceremony-pages.js` 继续只负责当前账号的邀请读取与接受/拒绝,避免管理端与个人端状态混在一起。
|
||||
- `public/js/profile-common.js` 继续作为 `genealogyId` 的唯一上下文 owner。
|
||||
- `public/js/upload-pages.js` 继续作为 OSS ID 的唯一前端产生来源。
|
||||
|
||||
## 数据流与状态
|
||||
|
||||
1. 页面从 URL 和 `profile-common.js` 取得真实家谱上下文。
|
||||
2. 页面先读取家谱详情,按 `canView/canEditContent/canManage` 控制可见入口;后端继续执行最终权限校验。
|
||||
3. 列表记录返回稳定字符串 ID,用户点击后进入详情或编辑。
|
||||
4. 表单只提交 YAML/后端 PC DTO 声明的字段;可选空值默认省略。
|
||||
5. 写操作使用模块级提交锁,完成后重新读取服务端状态。
|
||||
6. 页面分别展示加载、空、校验失败、403、404、业务失败和网络失败状态。
|
||||
7. 所有响应文本经过转义;手机号、内部 ID、OSS ID 和原始 JSON不进入可见页面。
|
||||
|
||||
## 页面入口
|
||||
|
||||
- 个人中心和家谱管理导航开放谱文、相册、祭祀活动、成员管理入口。
|
||||
- 页面缺少 `genealogyId` 时返回家谱选择页,并通过 `next` 保留目标页面。
|
||||
- 已有待开发页面在功能完成并通过测试后移除 `data-feature-status="pending"` 和 `pending-pages.js`。
|
||||
- 新增页面沿用现有个人中心头部、侧边栏、按钮、卡片和移动端断点,不引入新的前端框架。
|
||||
|
||||
## 测试与验收
|
||||
|
||||
每个模块单独执行:
|
||||
|
||||
1. 先新增 `ApiClient` 路径、query、body 白名单和长 ID 失败测试并观察 RED。
|
||||
2. 新增规范化、权限、渲染转义、写后重读、防重复和页面字段测试并观察 RED。
|
||||
3. 最小实现后运行模块聚焦测试直到 GREEN。
|
||||
4. 使用真实登录账号验证读取、空状态和非破坏性筛选。
|
||||
5. 有真实业务数据时验证详情和写操作;没有数据时明确记录未覆盖项,不制造示例数据。
|
||||
6. 每个模块完成后运行相关测试并更新 `docs/PC接口对接规划.md`。
|
||||
7. 阶段完成后运行 `npm test`、JavaScript 语法检查、`git diff --check` 和凭据扫描。
|
||||
|
||||
## 完成标准
|
||||
|
||||
- 所有当前 PC 可闭环功能都有可访问页面和导航入口。
|
||||
- 所有请求字段有真实页面来源,所有 ID 均由响应、选择器或上传产生。
|
||||
- 不存在 APP 路径、旧路径 fallback、手填业务 ID、原始 JSON或静态业务数据。
|
||||
- 所有写操作防重复并在成功后重新读取。
|
||||
- 仍缺后端能力的功能保持明确禁用并写入规划阻断项。
|
||||
Reference in New Issue
Block a user