docs(house): clarify reject disabled when assignments exist

这个提交包含在:
API Changelog Bot 2026-07-07 13:22:12 +08:00
父节点 ab87358753
当前提交 cbc05a9650

查看文件

@ -131,3 +131,65 @@ DELETE /v3/admin/order/hotel-requirements/{requirementId}/assignments/days/{dayN
- 两晚订单第 1 晚、第 2 晚都有独立“清空”按钮。 - 两晚订单第 1 晚、第 2 晚都有独立“清空”按钮。
- 清空第 1 晚后,第 1 晚回到待配房,第 2 晚配房仍保留。 - 清空第 1 晚后,第 1 晚回到待配房,第 2 晚配房仍保留。
- 清空不扣系统库存的配房时,不应释放资源库存。 - 清空不扣系统库存的配房时,不应释放资源库存。
## 2026-07-07 补充:有任意配房/询房数据时禁止驳回
本次补充针对前端底部“驳回需求”按钮误展示问题。后端口径不变,但前端需要严格按详情动作字段渲染,不能只看 `houseStatus` / 流程节点 / 是否处于“配房中”。
### 后端已验证行为
测试订单 `2074303545149980674` 当前第 1 晚已有配房/询房数据:
```json
{
"actions": {
"canRejectRequirement": {
"enabled": false,
"code": "REJECT_REQUIREMENT",
"label": "驳回需求",
"disabledReason": "已有配房, 不能驳回, 请先清空/删除配房"
},
"canClearAssignments": {
"enabled": true,
"code": "CLEAR_ASSIGNMENTS",
"label": "清空配房"
}
},
"requirement": {
"actions": {
"canRejectRequirement": false,
"canClearAssignments": true
}
}
}
```
即使前端绕过按钮直接调用:
```http
POST /v3/admin/order/2074303545149980674/hotel-requirement/supplier-reject
```
后端也返回:
```json
{
"code": 582086,
"success": false,
"message": "该需求已有配房记录, 不能驳回, 请走替换/修改配房"
}
```
### 前端必须调整
1. 底部“驳回需求”按钮以 `data.actions.canRejectRequirement.enabled` 为唯一可点击依据。
2. `enabled=false` 时必须隐藏或禁用按钮,并展示/保留 `disabledReason`,不能因为当前是 `CLAIMING` / “配房中”就展示可点击按钮。
3. 判断“有数据”包括所有 active 配房行:已配房、已确认、询房中、替换中,只要详情里该需求还存在配房/询房行,就不能驳回。
4. 每个 day 行清空后必须重新拉取订单详情;只有全部 day 清空到没有 active 配房行,后端返回 `enabled=true` 时,才允许驳回。
5. 如果同时存在底部整体清空和 day 行清空,驳回按钮仍然只看刷新后的后端 action,不在前端自行推算。
### 补充验收
- 第 1 晚有“询房中”或已选酒店数据、第 2 晚待配房:底部“驳回需求”不可点击。
- 清空第 1 晚后刷新详情,如果所有 day 都无配房/询房数据,底部“驳回需求”才可点击。
- 前端强制调用驳回接口时,收到 `582086` 必须提示错误并刷新详情,不能把订单展示为已驳回。