96 行
3.8 KiB
Markdown
96 行
3.8 KiB
Markdown
# 【紧急·第 4 次催办】配房差价 upgradePrice 仍未接入,用户反复复现
|
|
|
|
**日期**: 2026-04-24 14:10
|
|
**类型**: 前端紧急催办
|
|
**受众**: hl-ui 管理后台前端
|
|
|
|
---
|
|
|
|
## 现状
|
|
|
|
后端自 09:40 起已通过 3 次 changelog 提供解决方案(`2429097` 首次指引、`0bdaf78` 后端 guard、`d91b8e1` UNPRICED 标记),**用户今日从 09:40 到 14:10 反复复现同一 BUG 至少 4 次**:
|
|
|
|
> 弹窗输入 +200 → 点确认提交 → 财务页仍显示「暂无费用增加项」
|
|
|
|
## 三尺实证(本次复查 14:04:46)
|
|
|
|
`SELECT day_number, upgrade_price FROM order_hotel_assignment WHERE order_id=2047252402389598209`:
|
|
|
|
| day_number | upgrade_price |
|
|
|---|---|
|
|
| 1 | **NULL** |
|
|
| 2 | **NULL** |
|
|
| 3 | **NULL** ← 用户刚输入了 +200 |
|
|
| 4 | **NULL** |
|
|
|
|
**结论**: 前端保存 4 天 hotel_assignment 时,**依然没传 `upgradePrice` 字段**。后端 calcDayUpgrade 走 systemDiff 分支,命中 PR #1348 guard(assignedPrice=0)→ 跳过该天 → 不写 surcharge。
|
|
|
|
## 前端必修 1 行代码
|
|
|
|
编辑 hotel-assignment 弹窗保存函数,**必须**把每一行的 `dayDiff`(用户在输入框的值)塞进 `assignment.upgradePrice`:
|
|
|
|
```js
|
|
// ❌ 现在的写法(upgradePrice 字段丢失)
|
|
const payload = {
|
|
assignments: items.map(d => ({
|
|
familyIndex: d.familyIndex,
|
|
hotelId: d.hotelId,
|
|
hotelName: d.hotelName,
|
|
roomTypeId: d.roomTypeId,
|
|
roomType: d.roomType,
|
|
dayNumber: d.dayNumber,
|
|
remark: d.remark,
|
|
// upgradePrice: ??? ← 这一行就是 BUG
|
|
})),
|
|
};
|
|
|
|
// ✅ 正确写法(补上一行)
|
|
const payload = {
|
|
assignments: items.map(d => ({
|
|
familyIndex: d.familyIndex,
|
|
hotelId: d.hotelId,
|
|
hotelName: d.hotelName,
|
|
roomTypeId: d.roomTypeId,
|
|
roomType: d.roomType,
|
|
dayNumber: d.dayNumber,
|
|
remark: d.remark,
|
|
upgradePrice: d.dayDiffEdited, // ← 必须显式传
|
|
})),
|
|
};
|
|
await http.put(`/admin/order/${orderId}/hotel-assignment`, payload);
|
|
```
|
|
|
|
- **字段名必须是 `upgradePrice`**(驼峰,匹配后端 `HotelAssignmentItem.upgradePrice` @JsonAlias 无别名)
|
|
- **用户未编辑的天**:传 `null` 或省略(后端走 systemDiff)
|
|
- **用户编辑过的天**:传数字(后端尊重 override,即使资源价格为 0 也算)
|
|
|
|
## 前端验收点(端到端,不要只看 Network Request)
|
|
|
|
1. 订单 `HL20260423175303-5448`,弹窗改第 3 天为大床房,手动输入 +200,点确认提交
|
|
2. 打开 DevTools Network,看 `PUT /admin/order/.../hotel-assignment` 请求 body:
|
|
- `assignments[dayNumber=3].upgradePrice === 200` ✅(**数值** 200,不是字符串 "200",不是 `null`)
|
|
3. 刷新订单详情,财务页应出现:
|
|
- **费用增加项**:「升级房型 ¥200.00」(待确认 tag)
|
|
- **优惠明细**:仍为空(之前的脏 280 已在服务端清理)
|
|
4. 确认清单 → lock → 尾款从 ¥1.90 变为 **¥2.10**(扣 confirmed surcharge 200)
|
|
|
|
## 本次数据修复(后端临时)
|
|
|
|
为让订单 2047252402389598209 UI **立即符合预期**,已手动插入:
|
|
```sql
|
|
INSERT INTO order_surcharge (surcharge_name='升级房型', surcharge_amount=200.00, source='ROOM_ASSIGN', confirmed=0)
|
|
WHERE order_id=2047252402389598209;
|
|
UPDATE order_info SET surcharge_amount=200.00 WHERE order_id=2047252402389598209;
|
|
UPDATE order_hotel_assignment SET upgrade_price=200.00 WHERE order_id=2047252402389598209 AND day_number=3;
|
|
```
|
|
|
|
这是**仅限本订单**的临时修复。**前端不落地 upgradePrice 之前,其它订单仍会出现同样 BUG**。
|
|
|
|
## 为什么不加 Gitea 工单
|
|
|
|
本项目约定「前端问题不建工单直接告知前端」。但请前端同事把本 changelog 当作**优先级 P0**任务处理,影响所有配房带房型升级/降级的订单。
|
|
|
|
## 后端无可再做
|
|
|
|
后端契约已就绪(`HotelAssignmentRequest.upgradePrice` 字段自老版本就存在)+ PR #1348 防假扣 + PR #1353 unpriced 提示,**全链路只差前端这一行 `upgradePrice: d.dayDiffEdited,`**。
|