Inicio Explorar Ayuda
Iniciar sesión
fa88
/
foodie-server
1
0
Fork 0
Archivos Incidencias 0 Pull Requests 0 Wiki
Árbol: 083edc7277
Ramas Etiquetas
foodie-server
/
specs
/
006-orderstate
/
tasks.md

tasks.md 12 KB
Histórico Raw

Tasks: 订单状态四字段分离

Input: Design documents from /specs/test/ Prerequisites: plan.md, spec.md, research.md, data-model.md, contracts/

Tests: 无自动化测试要求，通过手动接口测试验证。

Organization: 按功能模块（用户故事）分组，每个阶段可独立验证。

Format: [ID] [P?] [Story] Description

  • [P]: 可并行（不同文件，无依赖）
  • [Story]: 所属用户故事（US1-US9）
  • 包含具体文件路径

Path Conventions

  • 后端源码: ruoyi-system/src/main/java/com/ruoyi/system/、ruoyi-admin/src/main/java/com/ruoyi/app/order/
  • MyBatis XML: ruoyi-system/src/main/resources/mapper/system/
  • SQL: updatesql/sql.md
  • 前端: E:\QtwCode\foodie\foodie-admin-vue\src\

Phase 1: Setup（数据库 & 实体层）

Purpose: 添加新字段到数据库和实体类，是所有后续任务的基础。

  • T001 在 updatesql/sql.md 末尾追加 ALTER TABLE 语句：添加 delivery_status（BIGINT DEFAULT NULL）、pay_status（BIGINT DEFAULT 0）、after_sale_status（BIGINT DEFAULT 0）三列到 pos_order 表
  • T002 [P] 在 ruoyi-system/src/main/java/com/ruoyi/system/domain/PosOrder.java 新增三个字段：deliveryStatus(Long)、payStatus(Long)、afterSaleStatus(Long)，添加对应 getter/setter
  • T003 在 ruoyi-system/src/main/resources/mapper/system/PosOrderMapper.xml 的 resultMap 中添加三个字段映射（delivery_status→deliveryStatus, pay_status→payStatus, after_sale_status→afterSaleStatus）
  • T004 在 ruoyi-system/src/main/resources/mapper/system/PosOrderMapper.xml 的 insertPosOrder 语句中添加三个新字段
  • T005 在 ruoyi-system/src/main/resources/mapper/system/PosOrderMapper.xml 的 updatePosOrder 语句中添加三个新字段

Checkpoint: 数据库 ALTER TABLE 执行完毕，PosOrder 实体和 Mapper 包含新字段，项目编译通过

Phase 2: Foundational（订单创建 & 支付回调）

Purpose: 确保新订单创建时正确初始化四字段，支付回调正确更新 payStatus。

  • T006 改造 ruoyi-admin/src/main/java/com/ruoyi/app/order/UserOrderController.java 的 createOrder() 方法：创建订单时设置 state=0、afterSaleStatus=0、deliveryStatus=NULL；根据类型和支付方式设置 payStatus（外送到付→1，其他→0）
  • T007 [P] 找到支付回调处理代码（搜索 payUrl 或支付回调相关类），在支付成功后添加 payStatus 从 0 改为 1 的逻辑

Checkpoint: 创建外送/自取/堂食订单后，数据库中四个新字段值正确初始化。模拟支付回调后 payStatus 正确更新为 1。

Phase 3: User Story 1 — 商家操作改造（接单/出餐/完成）

Goal: 商家可以对新状态体系的订单执行接单、出餐、完成操作。

Independent Test: 创建订单→商家接单(state=1)→商家出餐(state=2, 外送deliveryStatus=0)→自取/堂食完成(state=3, payStatus=1)

Implementation for User Story 1

  • T008 改造 ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderShOprateController.java 的接单方法：将 state 从 0 改为 1（替换旧逻辑）
  • T009 改造 ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderShOprateController.java 的 dispatchOrder() 出餐方法：将 state 从 1 改为 2；外送订单(type=0)额外设置 deliveryStatus=0；自取/堂食只改 state=2
  • T010 新增完成方法：在 ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderShOprateController.java 中新增"完成"接口，仅限 type=1(自取)或 type=2(堂食)且 state=2 的订单，将 state 改为 3 同时 payStatus 改为 1

Checkpoint: 商家端接单→出餐→完成流程走通，state/deliveryStatus/payStatus 值符合预期

Phase 4: User Story 2 — 骑手操作改造

Goal: 骑手可以对已出餐的外送订单执行接单、取餐、送达操作。

Independent Test: 商家出餐后(deliveryStatus=0)→骑手接单(deliveryStatus=1)→取餐(deliveryStatus=2)→送达(deliveryStatus=3, state=3)

Implementation for User Story 2

  • T011 改造 ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderQsOprateController.java 的 acceptOrder()：校验 type=0 且 afterSaleStatus=0，设置 deliveryStatus=1（替换旧 state 逻辑）
  • T012 [P] 改造 ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderQsOprateController.java 的 pickupOrder()：校验 type=0 且 afterSaleStatus=0，设置 deliveryStatus=2（替换旧 state 逻辑）
  • T013 改造 ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderQsOprateController.java 的 deliverOrder()：设置 deliveryStatus=3，同时设置 state=3（替换旧 state 逻辑）
  • T014 改造骑手约束逻辑：在骑手接单防重复逻辑中，原来查 state IN (3,4) 改为查 deliveryStatus IN (1,2)；更新 ruoyi-system/src/main/java/com/ruoyi/system/mapper/RiderPositionMapper.java 和对应的 XML 排除条件

Checkpoint: 骑手端接单→取餐→送达流程走通，deliveryStatus 和 state 值正确流转

Phase 5: User Story 3 — 订单取消

Goal: 用户和商家可以在未接单前取消订单，state 设为 4。

Independent Test: 创建订单→用户/商家取消→state=4, afterSaleStatus=0

Implementation for User Story 3

  • T015 改造 ruoyi-admin/src/main/java/com/ruoyi/app/order/OrderAppealController.java 的 userCancelpOrder()：取消订单时设 state=4, afterSaleStatus 保持 0（替换旧 state=10 逻辑）
  • T016 [P] 在商家端 ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderShOprateController.java 新增商家取消订单接口：校验 state IN (0,1)，设 state=4

Checkpoint: 用户取消和商家取消都正确设 state=4

Phase 6: User Story 4 — 定时任务改造

Goal: 定时任务使用新字段条件执行超时取消和自动完成。

Independent Test: 超时未支付订单自动 state=4；超时未完成订单自动 state=3

Implementation for User Story 4

  • T017 改造 ruoyi-admin/src/main/java/com/ruoyi/app/order/TestTask.java 的 testTiming()（未支付超时取消）：查 payStatus=0 AND state=0 且超时，设 state=4（替换旧 state=0→10 逻辑）
  • T018 改造 ruoyi-admin/src/main/java/com/ruoyi/app/order/TestTask.java 的 zidwancheng()（自动完成兜底）：查 state=2 AND afterSaleStatus=0 且超时，设 state=3（外送同时设 deliveryStatus=3，自取/堂食同时设 payStatus=1）
  • T019 改造 ruoyi-admin/src/main/java/com/ruoyi/app/order/TestTask.java 中作废逻辑：原来设 state=10 改为设 state=4

Checkpoint: 模拟超时场景，确认定时任务正确更新 state 和关联字段

Phase 7: User Story 5 — 新列表接口（三端）

Goal: 用户端、商家端、骑手端各有独立的 Tab 分页列表接口。

Independent Test: 各端各 Tab 返回正确的订单列表，分页格式 {records, total, page, size}

Implementation for User Story 5

  • T020 在 ruoyi-admin/src/main/java/com/ruoyi/app/order/UserOrderController.java 新增 orderList() 方法：GET /system/userOrder/orderList，支持 tab（unpaid/active/completed/cancelled/refund）、page、size、type 参数，使用 LambdaQueryWrapper 查询，返回 PosOrder 全字段 + 关联数据（shanghu/store/shaddress/user/food/parentRemarks）
  • T021 [P] 在 ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderShOprateController.java 新增 orderList() 方法：GET /system/orderShOprate/orderList，支持 tab（pending/preparing/ready/completed/cancelled/refund）、page、size、mdId、type 参数，使用 LambdaQueryWrapper 查询
  • T022 [P] 在 ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderQsOprateController.java 新增 orderList() 方法：GET /system/orderQsOprate/orderList，支持 tab（newTask/toPickup/delivering/completed/cancelled/refund）、page、size、longitude、latitude 参数，newTask Tab 使用 ST_Distance_Sphere 距离排序

Checkpoint: 三端列表接口各 Tab 返回正确数据，分页 total 准确，骑手端 newTask 距离排序正确

Phase 8: User Story 6 — 平台管理端前端改造

Goal: foodie-admin-vue 订单列表页支持四字段筛选和多 Tag 状态展示。

Independent Test: 平台管理端可按 state/payStatus/deliveryStatus/afterSaleStatus 筛选，状态列显示多 Tag 组合

Implementation for User Story 6

  • T023 改造 E:\QtwCode\foodie\foodie-admin-vue\src\views\system\order\index.vue 筛选区域：将旧 state 单下拉框替换为四个独立下拉框（state/payStatus/deliveryStatus/afterSaleStatus），选项前端硬编码
  • T024 改造 E:\QtwCode\foodie\foodie-admin-vue\src\views\system\order\index.vue 状态列：从单个 el-tag 改为主 Tag（state）+ 副 Tag（deliveryStatus/payStatus/afterSaleStatus）组合展示
  • T025 改造 E:\QtwCode\foodie\foodie-admin-vue\src\views\system\order\index.vue 订单详情弹窗：进度条从 7 步改为 4 步（0-3），新增支付状态/配送状态/售后状态信息行；修改订单弹窗的 state 下拉改为 0-4
  • T026 改造后端 /system/order/list 接口（PosOrderController）：支持 state/payStatus/deliveryStatus/afterSaleStatus 查询参数，多个条件 AND 关系，deliveryStatus 支持 NULL 筛选

Checkpoint: 平台管理端订单列表页筛选、状态展示、详情弹窗均正常工作

Phase 9: Polish & Cross-Cutting

Purpose: 推送通知更新和最终验证。

  • T027 更新推送通知代码中的 state 值映射：根据 type + state + deliveryStatus + afterSaleStatus 组合发送不同推送内容
  • T028 [P] 清理旧代码中的注释：在 PosOrder.java 中为废弃字段（diningStatus、isAccepted）添加 @Deprecated 注解
  • T029 完整流程验证：外送在线支付全流程→外送到付全流程→自取现金全流程→堂食现金全流程→取消订单→定时任务触发

Dependencies & Execution Order

Phase Dependencies

  • Phase 1 (Setup): 无依赖，立即开始
  • Phase 2 (Foundational): 依赖 Phase 1 — BLOCKS 所有后续
  • Phase 3 (商家操作): 依赖 Phase 2
  • Phase 4 (骑手操作): 依赖 Phase 2
  • Phase 5 (订单取消): 依赖 Phase 2
  • Phase 6 (定时任务): 依赖 Phase 2
  • Phase 7 (列表接口): 依赖 Phase 2（可与 Phase 3-6 并行）
  • Phase 8 (前端改造): 依赖 Phase 7（后端接口就绪）
  • Phase 9 (Polish): 依赖所有其他 Phase

User Story Dependencies

  • US1 (商家操作): Phase 2 完成后可开始，独立
  • US2 (骑手操作): Phase 2 完成后可开始，独立，与 US1 并行
  • US3 (订单取消): Phase 2 完成后可开始，独立
  • US4 (定时任务): Phase 2 完成后可开始，独立
  • US5 (列表接口): Phase 2 完成后可开始，独立，与 US1-US4 并行
  • US6 (前端改造): 依赖 US5（后端接口就绪）

Parallel Opportunities

  • Phase 1: T002 可与 T003-T005 并行
  • Phase 3-6: T008-T019 中不同 Phase 的任务可并行
  • Phase 7: T020、T021、T022 可完全并行（三个不同 Controller）

Parallel Example: Phase 7（列表接口三端并行）

# 三个列表接口互不依赖，可同时开发：
Task T020: "用户端 UserOrderController.orderList()"
Task T021: "商家端 PosOrderShOprateController.orderList()"
Task T022: "骑手端 PosOrderQsOprateController.orderList()"

Implementation Strategy

MVP First (Phase 1-3 + Phase 7 用户端)

  1. Phase 1: 数据库 & 实体层
  2. Phase 2: 订单创建改造
  3. Phase 3: 商家操作改造
  4. Phase 7: 用户端列表接口
  5. STOP and VALIDATE: 商家可以接单→出餐→完成，用户可以查看订单列表

Full Delivery

  1. Phase 1-2 → 基础就绪
  2. + Phase 3 → 商家端可用
  3. + Phase 4 → 骑手端可用
  4. + Phase 5 → 取消功能可用
  5. + Phase 6 → 定时任务就绪
  6. + Phase 7 → 三端列表就绪
  7. + Phase 8 → 平台管理端就绪
  8. + Phase 9 → 完整验证通过

Notes

  • [P] 任务 = 不同文件，无依赖，可并行
  • 每个任务完成后确认编译通过
  • Phase 1 完成后需手动执行 SQL（updatesql/sql.md）
  • 前端文件编辑需用 Python 脚本处理 CRLF 换行符问题
  • 旧方法（PosOrderController 中旧列表查询）保留不删