chengma/cmautobuy
2
0
Fork 0
Code Issues 89 Pull Requests Actions Packages Projects Releases Wiki Activity

Admin：PDD 商品支持批量重新采集已选商品 #123

New Issue
Open
opened 2026-08-10 19:51:52 +08:00 by ila · 1 comment
ila commented 2026-08-10 19:51:52 +08:00
Owner
Copy Link
Copy Source

基本信息

  • 类型：需求 / 交互缺陷修复
  • 父级大工单：#14
  • 所属 MVP / 版本：#15 Admin 四模块可用闭环
  • 阶段：PDD 商品数据与采集任务分配
  • 依赖：#121 已完成单商品明确重新采集入口

要解决什么

PDD 商品列表允许勾选已采集商品，但点击“创建采集任务”时，普通批量接口会按既有规则跳过 collected。采购员只能逐条进入商品详情点击“重新采集”，批量操作效率低；同时列表按钮仍可点击，容易被理解为操作无效。

复现步骤：

  1. 在 PDD 商品列表勾选一条或多条“已采集”商品。
  2. 点击“创建采集任务”并确认。
  3. 系统不创建任务，只在状态栏提示已采集商品被跳过。
  4. 必须逐条进入详情点击“重新采集”才能创建任务。

做什么 / 不做什么

做什么

  • 保留现有“创建采集任务”按钮及规则：处理待采集、失败、采集超时商品，继续跳过已采集商品。
  • 增加独立的“重新采集已选商品”按钮。
  • 只有当前勾选集合中包含已采集商品时，重新采集按钮才可用。
  • 点击后弹出明确确认框，显示将重新采集的已采集商品数量，并允许选择当前账号可见的执行客户端；默认不指定。
  • 后端增加批量明确重新采集入口，允许 collected 原子进入 collecting 并创建任务。
  • 同一批次中未超时的 collecting、已删除或状态已变化的商品分别统计并跳过，向采购员显示准确结果。
  • 重新采集开始时保留旧标题、店铺、规格、价格和采集时间；Client 成功提交后再覆盖。
  • 连续点击或并发提交时，同一商品只允许创建一条未超时的采集任务。
  • 管理员可选择全部可见 Client；采购员只能选择当前归属自己的 Client，服务端必须重新校验。

不做什么

  • 不把现有“创建采集任务”静默改成重采所有已采集商品。
  • 不自动勾选商品，不在筛选或导入完成后自动重新采集。
  • 不提前清空旧采集结果。
  • 不修改数据库结构、Client 四接口、Android 自动化或采购下单流程。
  • 不把失败、待采集商品混入“重新采集已选商品”的创建数量；它们仍由普通创建入口处理。

怎么做

  1. 在 PDD 列表行中保留稳定的采集状态数据属性，使前端可以根据当前页勾选集合计算“已采集”数量。
  2. 在 admin/templates/pdd/list.html 增加“重新采集已选商品”按钮和独立确认弹窗：
    • 未勾选已采集商品时按钮禁用；
    • 弹窗显示“将重新采集 N 个已采集商品”；
    • 提供可选 Client，默认不指定；
    • 只提交勾选集合中的商品 ID，最终状态仍由服务端判断，不能相信前端状态。
  3. 在 admin/static/js/app.js 复用现有勾选和弹窗交互，分别维护普通创建与重新采集按钮状态；不引入前端框架。
  4. 在 Web 路由和 Handler 增加批量 POST 入口，例如 POST /pdd/recollect-selected，通过登录和 CSRF 中间件。
  5. 在 Service 增加批量明确重采编排，按 goods_id 去重、校验 Client 可见范围，并在一个事务中逐项调用重新采集原子占用和任务插入。
  6. Repository 复用 #121 的 MarkRecollecting，不重复实现状态 SQL。
  7. 为模板/JavaScript、Handler、Service 增加回归测试，并更新 Admin 稳定需求和界面说明。

预计修改文件：

  • admin/templates/pdd/list.html
  • admin/static/js/app.js
  • admin/handler/web/pdd.go
  • admin/handler/web/web.go
  • admin/service/pdd.go
  • 相邻测试
  • docs/admin/01-requirements.md
  • docs/admin/05-ui-specification.md
  • 完成后归档 docs/task/<工单号>-admin-pdd批量重新采集已选商品.md

验收标准

  • 勾选集合不含已采集商品时，“重新采集已选商品”不可���。
  • 勾选一个或多个已采集商品时，按钮可用，确认框准确显示将重采数量。
  • 确认后，每个符合条件的已采集商品各创建一条采集任务，并在“采集采购”模块可见。
  • 可默认不指定 Client，也可选择当前账号可见 Client；不可见 Client 请求整体失败且不改变商品状态。
  • 同时勾选已采集、待采集、失败和采集中商品时，批量重采只处理服务端确认仍为已采集的商品，其余按原因统计提示。
  • 重复 goods_id、连续点击和并发请求不会给同一商品创建重复的未超时任务。
  • 重采开始后旧标题、规格、价格和采集时间仍可查看，成功提交新结果后才覆盖。
  • 原“创建采集任务”仍按旧规则工作，继续跳过已采集商品。
  • 所有写请求经过登录、CSRF 和 Client 可见范围校验。
  • 不修改数据库结构和 Client 四接口。
  • Go 1.23.0 build、test、vet 通过；前端 JavaScript 语法检查通过。

怎么验证

从 admin/ 目录执行：

$env:GOTOOLCHAIN='go1.23.0'
gofmt -l .
go build ./...
go test ./... -count=1
go vet ./...
node --check static/js/app.js
Remove-Item Env:GOTOOLCHAIN

人工验证：

  1. 分别勾选“仅待采集”“仅已采集”“已采集 + 采集中 + 失败”的组合，核对两个按钮的启用状态和确认数量。
  2. 对多个已采集商品执行批量重采，检查“采集采购”列表任务数和商品状态。
  3. 在任务未完成前重复提交，确认不产生重复任务。
  4. 使用管理员和采购员分别验证 Client 候选范围，并伪造不可见 Client 请求。
  5. 重采前后打开商品详情，确认旧规格和价格在新结果成功前没有被清空。

风险和回退

  • 风险：采购员误将大量商品重新采集。控制方式是独立按钮、明确数量、二次确认，绝不改变普通创建按钮语义。
  • 风险：前端状态过期。服务端必须重新读取每个商品的实时状态，仅处理提交时仍为 collected 的商品。
  • 风险：并发重复任务。复用 #121 的条件更新进行原子占用，只有占用成功的商品才能插入任务。
  • 风险：越权指定 Client。服务端在事务内按当前账号重新校验，失败时整批回滚。
  • 回退：回退本工单代码即可；无数据库迁移。已创建的采集任务按现有任务状态继续执行。
## 基本信息 - 类型：需求 / 交互缺陷修复 - 父级大工单：#14 - 所属 MVP / 版本：#15 Admin 四模块可用闭环 - 阶段：PDD 商品数据与采集任务分配 - 依赖：#121 已完成单商品明确重新采集入口 ## 要解决什么 PDD 商品列表允许勾选已采集商品，但点击“创建采集任务”时，普通批量接口会按既有规则跳过 `collected`。采购员只能逐条进入商品详情点击“重新采集”，批量操作效率低；同时列表按钮仍可点击，容易被理解为操作无效。 复现步骤： 1. 在 PDD 商品列表勾选一条或多条“已采集”商品。 2. 点击“创建采集任务”并确认。 3. 系统不创建任务，只在状态栏提示已采集商品被跳过。 4. 必须逐条进入详情点击“重新采集”才能创建任务。 ## 做什么 / 不做什么 ### 做什么 - 保留现有“创建采集任务”按钮及规则：处理待采集、失败、采集超时商品，继续跳过已采集商品。 - 增加独立的“重新采集已选商品”按钮。 - 只有当前勾选集合中包含已采集商品时，重新采集按钮才可用。 - 点击后弹出明确确认框，显示将重新采集的已采集商品数量，并允许选择当前账号可见的执行客户端；默认不指定。 - 后端增加批量明确重新采集入口，允许 `collected` 原子进入 `collecting` 并创建任务。 - 同一批次中未超时的 `collecting`、已删除或状态已变化的商品分别统计并跳过，向采购员显示准确结果。 - 重新采集开始时保留旧标题、店铺、规格、价格和采集时间；Client 成功提交后再覆盖。 - 连续点击或并发提交时，同一商品只允许创建一条未超时的采集任务。 - 管理员可选择全部可见 Client；采购员只能选择当前归属自己的 Client，服务端必须重新校验。 ### 不做什么 - 不把现有“创建采集任务”静默改成重采所有已采集商品。 - 不自动勾选商品，不在筛选或导入完成后自动重新采集。 - 不提前清空旧采集结果。 - 不修改数据库结构、Client 四接口、Android 自动化或采购下单流程。 - 不把失败、待采集商品混入“重新采集已选商品”的创建数量；它们仍由普通创建入口处理。 ## 怎么做 1. 在 PDD 列表行中保留稳定的采集状态数据属性，使前端可以根据当前页勾选集合计算“已采集”数量。 2. 在 `admin/templates/pdd/list.html` 增加“重新采集已选商品”按钮和独立确认弹窗： - 未勾选已采集商品时按钮禁用； - 弹窗显示“将重新采集 N 个已采集商品”； - 提供可选 Client，默认不指定； - 只提交勾选集合中的商品 ID，最终状态仍由服务端判断，不能相信前端状态。 3. 在 `admin/static/js/app.js` 复用现有勾选和弹窗交互，分别维护普通创建与重新采集按钮状态；不引入前端框架。 4. 在 Web 路由和 Handler 增加批量 POST 入口，例如 `POST /pdd/recollect-selected`，通过登录和 CSRF 中间件。 5. 在 Service 增加批量明确重采编排，按 goods_id 去重、校验 Client 可见范围，并在一个事务中逐项调用重新采集原子占用和任务插入。 6. Repository 复用 #121 的 `MarkRecollecting`，不重复实现状态 SQL。 7. 为模板/JavaScript、Handler、Service 增加回归测试，并更新 Admin 稳定需求和界面说明。 预计修改文件： - `admin/templates/pdd/list.html` - `admin/static/js/app.js` - `admin/handler/web/pdd.go` - `admin/handler/web/web.go` - `admin/service/pdd.go` - 相邻测试 - `docs/admin/01-requirements.md` - `docs/admin/05-ui-specification.md` - 完成后归档 `docs/task/<工单号>-admin-pdd批量重新采集已选商品.md` ## 验收标准 - [ ] 勾选集合不含已采集商品时，“重新采集已选商品”不可���。 - [ ] 勾选一个或多个已采集商品时，按钮可用，确认框准确显示将重采数量。 - [ ] 确认后，每个符合条件的已采集商品各创建一条采集任务，并在“采集采购”模块可见。 - [ ] 可默认不指定 Client，也可选择当前账号可见 Client；不可见 Client 请求整体失败且不改变商品状态。 - [ ] 同时勾选已采集、待采集、失败和采集中商品时，批量重采只处理服务端确认仍为已采集的商品，其余按原因统计提示。 - [ ] 重复 goods_id、连续点击和并发请求不会给同一商品创建重复的未超时任务。 - [ ] 重采开始后旧标题、规格、价格和采集时间仍可查看，成功提交新结果后才覆盖。 - [ ] 原“创建采集任务”仍按旧规则工作，继续跳过已采集商品。 - [ ] 所有写请求经过登录、CSRF 和 Client 可见范围校验。 - [ ] 不修改数据库结构和 Client 四接口。 - [ ] Go 1.23.0 build、test、vet 通过；前端 JavaScript 语法检查通过。 ## 怎么验证 从 `admin/` 目录执行： ```powershell $env:GOTOOLCHAIN='go1.23.0' gofmt -l . go build ./... go test ./... -count=1 go vet ./... node --check static/js/app.js Remove-Item Env:GOTOOLCHAIN ``` 人工验证： 1. 分别勾选“仅待采集”“仅已采集”“已采集 + 采集中 + 失败”的组合，核对两个按钮的启用状态和确认数量。 2. 对多个已采集商品执行批量重采，检查“采集采购”列表任务数和商品状态。 3. 在任务未完成前重复提交，确认不产生重复任务。 4. 使用管理员和采购员分别验证 Client 候选范围，并伪造不可见 Client 请求。 5. 重采前后打开商品详情，确认旧规格和价格在新结果成功前没有被清空。 ## 风险和回退 - 风险：采购员误将大量商品重新采集。控制方式是独立按钮、明确数量、二次确认，绝不改变普通创建按钮语义。 - 风险：前端状态过期。服务端必须重新读取每个商品的实时状态，仅处理提交时仍为 `collected` 的商品。 - 风险：并发重复任务。复用 #121 的条件更新进行原子占用，只有占用成功的商品才能插入任务。 - 风险：越权指定 Client。服务端在事务内按当前账号重新校验，失败时整批回滚。 - 回退：回退本工单代码即可；无数据库迁移。已创建的采集任务按现有任务状态继续执行。
ila commented 2026-08-17 16:08:22 +08:00
Author
Owner
Copy Link
Copy Source

关联新工单 #252：该工单负责 SYB 列表的批量重新采集入口，本工单继续负责 PDD 商品列表入口。

两者实现时必须共用同一批量重采 Service，统一复用 #121 的原子防重、旧数据保留、Client 可见范围和结果统计规则；不要在两个 Handler 或页面各自复制一套状态判断。先实施的一方负责抽取公共 Service，后实施的一方直接复用。

关联新工单 #252：该工单负责 **SYB 列表**的批量重新采集入口，本工单继续负责 **PDD 商品列表**入口。 两者实现时必须共用同一批量重采 Service，统一复用 #121 的原子防重、旧数据保留、Client 可见范围和结果统计规则；不要在两个 Handler 或页面各自复制一套状态判断。先实施的一方负责抽取公共 Service，后实施的一方直接复用。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
admin ila
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: chengma/cmautobuy#123