# Tasks: 扫码桌号点餐 **Input**: Design documents from `/specs/004-qr-table-order/` **Prerequisites**: plan.md (required), spec.md (required) **Tests**: 手动测试,无自动化测试任务。 **Organization**: Tasks grouped by user story to enable independent implementation and testing. ## Format: `[ID] [P?] [Story] Description` - **[P]**: Can run in parallel (different files, no dependencies) - **[Story]**: Which user story this task belongs to (e.g., US1, US2, US3) --- ## Phase 1: Setup (数据库 & 实体基础) **Purpose**: 数据库加字段,实体和 DTO 同步更新 - [ ] T001 在 `pos_order` 表新增 `table_id BIGINT DEFAULT NULL COMMENT '餐桌码ID'` 字段 - [ ] T002 [P] 在 `order_parent` 表新增 `table_id BIGINT DEFAULT NULL COMMENT '餐桌码ID'` 字段 - [ ] T003 [P] 在 `ruoyi-system/src/main/java/com/ruoyi/system/domain/PosOrder.java` 新增 `private Long tableId` 字段 - [ ] T004 [P] 在 `ruoyi-system/src/main/java/com/ruoyi/system/domain/OrderParent.java` 新增 `private Long tableId` 字段 - [ ] T005 [P] 在 `ruoyi-admin/src/main/java/com/ruoyi/app/order/dto/OrderCreateInput.java` 新增 `private Long tableId` 字段 **Checkpoint**: 数据库字段已加,Java 实体和 DTO 已同步 --- ## Phase 2: User Story 1 - 扫码下单关联餐桌码 (Priority: P1) 🎯 MVP **Goal**: 下单接口接收可选 tableId,校验有效性,写入订单 **Independent Test**: 创建一个档口码,模拟下单传入 tableId,检查订单中 tableId 和 tableNum 是否正确 ### Implementation for User Story 1 - [ ] T006 [US1] 在 `UserOrderController.java` 中注入 `ITableQrcodeService` - [ ] T007 [US1] 在 `UserOrderController.java` 中新增独立方法 `validateAndFillTableInfo(OrderCreateInput input)`:若 tableId 不为空则查询 table_qrcode 记录,校验存在且未停用,以码记录的 tableNo 覆盖 input.tableNum;为空则跳过 - [ ] T008 [US1] 在 `createOrder` 方法中调用 `validateAndFillTableInfo(input)`,位置在 `createOrderParent` 调用之前;`createOrderParent` 和 `createOrderChild` 中仅新增 `setTableId(input.getTableId())`,不改动其他逻辑 - [ ] T009 [US1] 手动测试:创建档口码 → 下单传入 tableId → 验证订单 tableId 和 tableNum 正确 → 传入无效 tableId → 验证报错 **Checkpoint**: 扫码下单流程完整,订单正确关联餐桌码 --- ## Phase 3: User Story 2 - 扫通用码点餐 (Priority: P2) **Goal**: 验证通用码场景下 tableId 同样正确关联 **Independent Test**: 创建通用码(type=1),模拟下单传入通用码的 tableId,检查订单正确 ### Implementation for User Story 2 - [ ] T010 [US2] 手动测试:创建通用码 → 下单传入通用码 tableId → 验证订单关联到通用码而非档口码 - [ ] T011 [US2] 手动测试:同一通用码下,选择不同档口分别下单 → 验证每个订单的 tableId 都指向同一个通用码 **Checkpoint**: 通用码场景验证通过 --- ## Phase 4: User Story 3 - 商家查看桌号 (Priority: P3) **Goal**: 商家端订单详情展示桌号 **Independent Test**: 商家端查看带桌号的堂食订单,确认桌号正确显示 ### Implementation for User Story 3 - [ ] T012 [US3] 确认 `PosOrder` 返回的 JSON 中 tableId 和 tableNum 字段在订单详情接口中正确返回(后端无需改动,MyBatis-Plus 自动映射) - [ ] T013 [US3] 手动测试:商家端查看堂食订单详情 → 确认显示桌号 → 查看非堂食订单 → 确认不显示桌号 **Checkpoint**: 商家端能正确看到桌号 --- ## Phase 5: Edge Cases & Polish **Purpose**: 边界情况验证和收尾 - [ ] T014 不传 tableId 下单 → 验证普通下单流程不受影响 - [ ] T015 [P] 传入已停用的 tableId 下单 → 验证报错提示"该餐桌码已停用" - [ ] T016 [P] 传入已删除的 tableId 下单 → 验证报错提示"餐桌码不存在" - [ ] T017 前端扫桌码后中途退出 APP 再回来 → 验证 tableId 丢失后按普通下单处理 --- ## Dependencies & Execution Order ### Phase Dependencies - **Phase 1 (Setup)**: No dependencies - start immediately - **Phase 2 (US1)**: Depends on Phase 1 completion - **Phase 3 (US2)**: Depends on Phase 2 (共用同一套代码逻辑,仅验证场景不同) - **Phase 4 (US3)**: Depends on Phase 1 (数据已有,仅需确认返回) - **Phase 5 (Polish)**: Depends on Phase 2 completion ### Parallel Opportunities - T001, T002 可并行执行(不同表) - T003, T004, T005 可并行执行(不同文件) - Phase 3 和 Phase 4 可并行测试(不同验证维度) --- ## Implementation Strategy ### MVP (Phase 1 + Phase 2) 1. 完成数据库加字段 2. 完成实体和 DTO 加字段 3. 完成下单接口校验逻辑 4. 手动验证核心流程 核心代码改动集中在 `UserOrderController.java`,约 10-15 行新增代码。