停止V4入站双写旧任务
This commit is contained in:
andy
@@ -52,7 +52,7 @@
|
||||
| `POST /api/auth/login` | 用户名密码登录 | 成功后返回 `access_token`、当前用户、可访问酒店、权限码和可见菜单；token 只放 `sessionStorage`，不要放 `localStorage`、URL、日志或错误上报。 |
|
||||
| `GET /api/auth/me` | 恢复当前登录态 | 前端启动后带 `Authorization: Bearer <access_token>` 调用；401 时清理 token 并进入登录页。 |
|
||||
| `POST /api/auth/logout` | 登出当前 session | 带 `Authorization: Bearer <access_token>`；成功后前端必须清理本地 token 和当前用户上下文。 |
|
||||
| `GET /api/reservation/orders` | 查询订单列表 | 必须带 `Authorization: Bearer <access_token>`，需要 `RESERVATION_ORDER_READ`；默认返回全部订单状态；按后端维护的订单最近业务活动时间倒序，当前落库字段为 `workflow_reservation_order.latest_activity_at`，前端不要自行重排；`open_work_item_count` 是订单列表统一待处理展示数量，前端订单列表已用它展示待处理数，第一版等于 V4 未完成订单任务数；`open_task_count` 仍保留为旧 V2/V3 诊断计数，排除 `COMPLETED` 和 `FAILED`；已补齐 V4 继续处理入口字段，前端有 `next_v4_order_task_id` 时优先跳 V4 订单任务详情；隐藏技术订单不返回，因此 S10/S99 和旧 S000/S999 不会在订单列表形成订单。 |
|
||||
| `GET /api/reservation/orders` | 查询订单列表 | 必须带 `Authorization: Bearer <access_token>`，需要 `RESERVATION_ORDER_READ`；默认返回全部订单状态；按后端维护的订单最近业务活动时间倒序，当前落库字段为 `workflow_reservation_order.latest_activity_at`，前端不要自行重排；`open_work_item_count` 是订单列表统一待处理展示数量，前端订单列表已用它展示待处理数，第一版等于 V4 未完成订单任务数；V4 普通业务入站已停止双写旧 `workflow_reservation_task`，开发 / 测试阶段不维护 V2/V3 旧任务兼容，测试数据可重建；`open_task_count` 仍保留为旧任务表原始诊断计数，前端不要用于展示待处理数；已补齐 V4 继续处理入口字段，前端有 `next_v4_order_task_id` 时优先跳 V4 订单任务详情；`next_processable_task_id` 仅作为历史 V2/V3 诊断兼容字段，清理旧任务数据后新 V4 订单不应返回该字段；隐藏技术订单不返回，因此 S10/S99 和旧 S000/S999 不会在订单列表形成订单。 |
|
||||
| `GET /api/reservation/tasks` | 查询任务列表 / 工作台 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`；未传 `order_id` 时按来源消息接收时间倒序，传 `order_id` 时按同订单队列顺序正序；用 `can_process` 和 `readonly_reason_code` 控制入口按钮；列表不返回 AI 原始 payload、邮件正文或附件 URL；已返回来源邮件会话摘要字段，并支持 `order_status` 按任务所属订单状态筛选；旧 S000/S999 和 V3 S10/S99 以 `task_type=SOURCE_MESSAGE_ONLY` 只读任务返回，列表已透出 `result_type`、`ai_task_type`、`route_code`、`system_process_category`。V4 S10/S99 不再进入该旧任务表，应从 V4 工作台来源通知接口展示。 |
|
||||
| `GET /api/reservation/workbench-items` | 查询 V4 工作台统一列表 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`；返回 V4 业务订单任务和 S10/S99 来源通知混排摘要；支持 `hotel_id`、`item_type`、`keyword`、`page_num`、`page_size`；默认按 `source_received_at` 倒序，同一来源时间下按 `updated_at`、`created_at`、数字 `target_id` 倒序；列表不返回邮件正文、附件 URL、`ai_payload_json` 或来源通知原始 payload。 |
|
||||
| `GET /api/reservation/order-tasks` | 查询 V4 业务订单任务列表 | 必须带 Bearer token，需要 `RESERVATION_TASK_READ`；只返回 V4 业务订单任务，不包含 S10/S99 来源通知；支持 `hotel_id`、`order_id`、`order_task_status`、`card_status`、`keyword`、`page_num`、`page_size`；`order_task_status` 非 `OPEN` / `COMPLETED` 返回 400，`card_status` 非 V4 卡状态返回 400；`card_status` 只筛业务 / 可处理卡，固定来源邮件展示卡不参与筛选。 |
|
||||
@@ -104,7 +104,7 @@
|
||||
|
||||
| 接口 | 本轮变化 | 前端接入注意 |
|
||||
| --- | --- | --- |
|
||||
| `GET /api/reservation/orders` | 补齐订单列表 V4 继续处理入口字段，并新增统一 open count 字段；前端展示已接入。 | `order_status` 不传时默认查询全部订单状态；`page_num` 从 1 开始；`page_size` 后端有最大值保护；`open_work_item_count` 是订单列表展示用统一待处理数量，开发阶段不考虑旧数据，第一版直接等于 `v4_open_order_task_count`；前端展示待处理数量时只读该字段，不自行计算旧任务数和 V4 数，也不使用旧 `open_task_count` 作为展示数量；旧 `open_task_count` 和 `next_processable_task_id` 继续保留用于 V2/V3 兼容与排查。V4 新增 `next_v4_order_task_id`、`next_v4_action_card_id`、`next_v4_action_type`、`next_v4_action_status`、`v4_open_order_task_count`；前端“继续处理”已按优先级实现：存在 `next_v4_order_task_id` 时跳 `/reservation/order-tasks/{next_v4_order_task_id}`，否则回退旧 `/reservation/tasks/{next_processable_task_id}`；两者都没有时展示无待处理状态。 |
|
||||
| `GET /api/reservation/orders` | 补齐订单列表 V4 继续处理入口字段，并新增统一 open count 字段；前端展示已接入。 | `order_status` 不传时默认查询全部订单状态；`page_num` 从 1 开始；`page_size` 后端有最大值保护；`open_work_item_count` 是订单列表展示用统一待处理数量，开发阶段不考虑旧数据，第一版直接等于 `v4_open_order_task_count`；前端展示待处理数量时只读该字段，不自行计算旧任务数和 V4 数，也不使用旧 `open_task_count` 作为展示数量；旧 `open_task_count` 保留为旧任务表原始诊断计数。V4 新增 `next_v4_order_task_id`、`next_v4_action_card_id`、`next_v4_action_type`、`next_v4_action_status`、`v4_open_order_task_count`；前端“继续处理”已按优先级实现：存在 `next_v4_order_task_id` 时跳 `/reservation/order-tasks/{next_v4_order_task_id}`；开发 / 测试清理旧任务后，新 V4 订单通常不再回退旧 `/reservation/tasks/{next_processable_task_id}`；两者都没有时展示无待处理状态。 |
|
||||
| `GET /api/reservation/tasks` | 补齐来源邮件会话摘要字段，并新增 `order_status` 查询参数。 | `order_status` 按任务所属订单状态过滤，支持 `TEMPORARY`、`ACTIVE`、`ENDED`、`LOGIC_DELETED`；列表仍然只返回安全摘要，不返回正文、HTML、附件 URL 或 AI 原始 payload；点击邮件入口时使用 `source_message_id` 调会话详情。 |
|
||||
| `GET /api/reservation/orders/{orderId}` | 补齐旧 `tasks[]` 来源邮件会话摘要字段，并新增 V4 总览和 `v4_order_tasks[]` 订单任务时间线；前端订单详情总览页已接入。 | `include_tasks=false` 可只取轻量摘要，此时 `tasks[]`、`v4_order_tasks[]` 和 `related_source_messages[]` 都为空，`order_overview` 为空快照，`next_v4_action.action_type=NONE`；旧 `tasks[]` 顺序由后端按订单队列返回，V4 `v4_order_tasks[]` 按 `source_received_at`、`source_message_id`、`order_context_index`、`created_at`、数字 ID 正序返回；前端不要自行重排。订单详情页只展示 V4 确认快照、下一步入口、关联来源消息和任务卡安全摘要，不在该页确认、复核或编辑任务卡，也不展示 payload、邮件正文或附件 URL。`include_source_summary` 第一版不作为前端裁剪字段的强约束，前端暂不要依赖它减少返回字段。 |
|
||||
| `GET /api/reservation/tasks/{taskId}` | 补齐顶层来源邮件字段，并扩展 `fields[]` 元数据。 | 顶层来源字段用于打开邮件会话；`fields[]` 中的 `result_type`、`task_type`、`task_subtype`、`default_value_source` 用于前端字段分组、调试和白名单对齐。 |
|
||||
@@ -190,11 +190,11 @@ POST /api/auth/logout
|
||||
- `GET /api/reservation/orders` 默认返回全部订单状态，包括 `TEMPORARY`、`ACTIVE`、`ENDED`、`LOGIC_DELETED`。
|
||||
- `keyword` 会匹配订单业务号、临时订单号、展示名、订单状态，也会匹配来源消息安全摘要命中的 SourceMessage ID；前端可以用邮件主题、外部消息 ID 或会话 ID 辅助查订单。
|
||||
- `open_work_item_count` 是订单列表统一展示数量，第一版按 V4 未完成订单任务计算，即等于 `v4_open_order_task_count`；前端展示待处理数量时只使用它，不回退旧 `open_task_count`，也不要自行把旧任务数和 V4 数相加。
|
||||
- `open_task_count` 只统计旧 V2/V3 未关闭任务，排除 `COMPLETED` 和 `FAILED`，当前保留用于兼容和问题排查。
|
||||
- `next_processable_task_id` 是后端按同订单队列实时计算出的下一条可处理任务；前端可以用它做“继续处理”入口。
|
||||
- `open_task_count` 是旧任务表原始未关闭计数，排除 `COMPLETED` 和 `FAILED`，当前保留用于历史接口兼容和问题排查；V4 普通业务入站已停止双写旧任务，开发 / 测试环境应清理旧任务数据，前端展示待处理数量不要使用它。
|
||||
- `next_processable_task_id` 是后端按旧 V2/V3 队列实时计算出的历史兼容字段；开发阶段不维护 V2/V3 旧任务兼容，清理旧任务数据后，新 V4 订单不应再通过它进入旧任务详情。
|
||||
- V4 订单任务入口字段由后端实时派生：`v4_open_order_task_count` 统计当前订单下 `order_task_status!=COMPLETED` 的 V4 订单任务；`next_v4_order_task_id` 是同订单第一条仍需用户处理的 V4 订单任务；`next_v4_action_card_id` 是该订单任务下第一张待处理卡；`next_v4_action_type` 取 `CONFIRM` / `REVIEW` / `NONE`；`next_v4_action_status` 取 `PENDING_CONFIRM` / `REVIEW_REQUIRED` 或空。
|
||||
- V4 派生规则：Basic Information 必须优先于业务卡；Basic 已确认后，业务卡中 `REVIEW_REQUIRED` 优先于普通 `PENDING_CONFIRM`；`COMPLETED` 的 V4 订单任务不计入 open；S10/S99 来源通知不挂订单，不进入这些订单列表字段。
|
||||
- 前端订单列表“继续处理”已按该优先级接入：有 `next_v4_order_task_id` 时跳 V4 订单任务详情；否则有旧 `next_processable_task_id` 时跳旧任务详情；`next_v4_action_type=NONE` 且旧字段为空时展示无待处理状态，查看详情仍固定进入订单详情。
|
||||
- 前端订单列表“继续处理”已按该优先级接入：有 `next_v4_order_task_id` 时跳 V4 订单任务详情；`next_v4_action_type=NONE` 且旧字段为空时展示无待处理状态，查看详情仍固定进入订单详情。开发 / 测试阶段旧任务数据可清理，清理后新 V4 订单不应再出现旧 fallback 入口。
|
||||
- `display_order_key` 是前端优先展示的订单业务号或临时订单号；`group_code` 和 `confirmation_number` 只有在当前订单业务号类型匹配时返回。
|
||||
- 订单 ID、任务 ID、SourceMessage ID 在这些前端接口中按字符串返回，前端不要转换成 JavaScript number。
|
||||
- 当前 V3 / 过渡实现中，源邮件只读通知卡背后有隐藏技术订单用于满足后端任务外键，但订单列表不会返回该订单；任务列表中该类任务的 `display_order_key`、`temporary_order_no`、`group_code`、`confirmation_number` 可能为空，前端不要因此隐藏整条任务。V4 S10/S99 目标模型已改为独立来源通知，不再挂隐藏技术订单。
|
||||
@@ -248,7 +248,7 @@ POST /api/auth/logout
|
||||
|
||||
### 5.6 前端联调演示数据 seed 接口
|
||||
|
||||
后端提供一个受控的 dev/test 演示数据入口，方便前端在空库或本地环境快速看到页面效果。
|
||||
后端提供一个受控的 dev/test 演示数据入口，方便前端在空库或本地环境快速看到历史 V2/V3 页面效果。
|
||||
|
||||
```text
|
||||
POST /api/system/reservation/demo-data
|
||||
@@ -265,6 +265,7 @@ Content-Type: application/json
|
||||
- dev profile 默认开启；test 默认关闭，需要后端环境显式设置 `reservation.demo-data.enabled=true` 或环境变量 `RESERVATION_TEST_DEMO_DATA_ENABLED=true`。
|
||||
- 必须配置 `reservation.demo-data.access-key`；dev 优先使用 `RESERVATION_DEV_DEMO_DATA_ACCESS_KEY`，test 优先使用 `RESERVATION_TEST_DEMO_DATA_ACCESS_KEY`，旧通用变量 `RESERVATION_DEMO_DATA_ACCESS_KEY` 仅作为兼容兜底。
|
||||
- 该接口只用于 dev/test 联调，不允许放进生产普通页面，也不要把访问口令写进前端仓库、浏览器环境变量或构建产物。
|
||||
- 该接口会创建旧 `workflow_reservation_task` 演示数据，是历史 V2/V3 页面演示入口；M002 V4 smoke 不应再使用该接口造数，避免重新制造旧任务残留。V4 smoke 应使用 SuperAgent V4 回调或专门 V4 fixture。
|
||||
|
||||
返回内容：
|
||||
|
||||
|
||||
@@ -42,7 +42,7 @@
|
||||
| `GET /api/source-messages` | 已完成安全摘要列表 | 可以 | 不能替代邮件会话全文接口。 |
|
||||
| `GET /api/source-messages/{id}` | 已完成单条安全摘要 | 可以 | 不能替代邮件会话全文接口。 |
|
||||
| `GET /api/source-messages/{id}/original` | 已完成单封原文权限读取 | 谨慎接入 | 必须带 Bearer token，需要同时拥有 `SOURCE_MESSAGE_READ` 和 `SOURCE_MESSAGE_ORIGINAL_READ`；只能读单封邮件，不能返回同一 conversation 全量邮件。 |
|
||||
| `GET /api/reservation/orders` | 已完成第一版 | 可以 | 默认查询全部订单状态；订单列表待处理展示使用 `open_work_item_count`；旧 `open_task_count` 仅作为 V2/V3 兼容诊断计数。 |
|
||||
| `GET /api/reservation/orders` | 已完成第一版 | 可以 | 默认查询全部订单状态；订单列表待处理展示使用 `open_work_item_count`；V4 普通业务已停止双写旧任务，旧 `open_task_count` 仅作为历史诊断计数。 |
|
||||
| `GET /api/source-messages/{sourceMessageId}/conversation` | 已完成第一版，已补 `html_body_sanitized` 和 `html_render_mode` | 可以 | 必须带 Bearer token，需要同时拥有 `SOURCE_MESSAGE_READ` 和 `SOURCE_MESSAGE_ORIGINAL_READ`；返回完整 text/html、后端清洗后的 HTML、媒体外链和关联订单 / 任务摘要；前端不传原文读取 key，页面展示优先使用 `html_body_sanitized`。 |
|
||||
| `POST /api/system/reservation/demo-data` | 已完成 | 仅本地 / test 联调可用 | 默认关闭，必须后端配置访问口令；不能作为生产页面接口。 |
|
||||
| `POST /api/system/debug/eml-superagent-runs` | 已完成第一版 | 仅 dev/test Debug 页面可用 | 默认关闭，必须后端配置访问口令、阿里云 OSS 和 SuperAgent Open API；第一版只展示 SuperAgent 结果，不创建订单和任务；已能识别旧 S000/S999 和新结构化 S10/S99。 |
|
||||
@@ -353,7 +353,7 @@ GET /api/reservation/orders/{orderId}
|
||||
GET /api/reservation/orders
|
||||
```
|
||||
|
||||
当前状态：后端已完成第一版。默认查询全部订单状态；`open_task_count` 排除旧 V2/V3 的 `COMPLETED` 和 `FAILED`，`next_processable_task_id` 按旧 V2/V3 同订单队列可处理状态实时计算。M002 V4 CP14 已补齐 V4 继续处理入口字段；后端新增 `open_work_item_count` 作为订单列表统一待处理展示数量，第一版直接等于 V4 未完成订单任务数，不叠加旧任务。前端已按 `next_v4_order_task_id` 优先进入 V4 订单任务详情，并在无 V4 入口时回退旧任务详情；订单列表待处理数量已改为只展示 `open_work_item_count`。
|
||||
当前状态：后端已完成第一版。默认查询全部订单状态；`open_task_count` 排除旧任务表中 `COMPLETED` 和 `FAILED`，保留为历史诊断计数。M002 V4 CP14 已补齐 V4 继续处理入口字段；后端新增 `open_work_item_count` 作为订单列表统一待处理展示数量，第一版直接等于 V4 未完成订单任务数，不叠加旧任务。当前开发阶段已停止 V4 普通业务双写旧 `workflow_reservation_task`，开发 / 测试环境旧任务数据可清理且可重建；`next_processable_task_id` 仅作为历史 V2/V3 诊断兼容字段，清理后新 V4 订单不应返回旧任务入口。前端已按 `next_v4_order_task_id` 优先进入 V4 订单任务详情；订单列表待处理数量已改为只展示 `open_work_item_count`。
|
||||
|
||||
默认排序：按后端维护的订单最近业务活动时间倒序返回，保证最近有业务活动的订单排在前面。后端当前使用 `workflow_reservation_order.latest_activity_at` 作为排序字段，并在订单创建、任务创建、草稿保存、最终确认、人工复核解阻、任务状态变更等写路径维护；前端不要再基于任务时间或更新时间自行重排。
|
||||
|
||||
@@ -413,7 +413,7 @@ V4 继续处理字段说明：
|
||||
| `next_v4_action_status` | `PENDING_CONFIRM` / `REVIEW_REQUIRED`；`NONE` 时为空。 |
|
||||
| `v4_open_order_task_count` | 当前订单下未完成 V4 订单任务数，`COMPLETED` 不计入。 |
|
||||
|
||||
前端“继续处理”入口优先级：优先使用 `next_v4_order_task_id` 跳转 V4 订单任务详情；没有 V4 待处理时再使用旧 `next_processable_task_id` 跳旧任务详情；两者都没有时展示无待处理状态。S10/S99 来源通知不创建订单，不进入订单列表字段统计。订单列表展示“待处理数量”时只使用 `open_work_item_count`，不使用旧 `open_task_count` 作为展示数量，也不在前端自行计算 `open_task_count + v4_open_order_task_count`；旧 `open_task_count` 和 `v4_open_order_task_count` 保留用于兼容与排查。
|
||||
前端“继续处理”入口优先级：优先使用 `next_v4_order_task_id` 跳转 V4 订单任务详情；没有 V4 待处理且旧 `next_processable_task_id` 为空时展示无待处理状态。S10/S99 来源通知不创建订单，不进入订单列表字段统计。订单列表展示“待处理数量”时只使用 `open_work_item_count`，不使用旧 `open_task_count` 作为展示数量，也不在前端自行计算 `open_task_count + v4_open_order_task_count`；旧 `open_task_count` 和 `v4_open_order_task_count` 保留用于兼容与排查。V4 新业务主线只写 V4 模型，开发阶段不维护 V2/V3 旧任务兼容，测试数据可重建；清理旧任务数据后，新 V4 订单不应再出现旧继续处理入口。
|
||||
|
||||
## 6. 前端联调演示数据 seed 接口
|
||||
|
||||
@@ -423,7 +423,7 @@ V4 继续处理字段说明：
|
||||
POST /api/system/reservation/demo-data
|
||||
```
|
||||
|
||||
当前状态：后端已完成第一版。该接口只用于本地 / test 联调造数，默认关闭，不是生产业务页面接口。
|
||||
当前状态：后端已完成第一版。该接口只用于本地 / test 联调造数，默认关闭，不是生产业务页面接口。该接口会创建旧 `workflow_reservation_task` 演示数据，是历史 V2/V3 页面演示入口；M002 V4 smoke 不应再使用该接口造数，避免重新制造旧任务残留。V4 smoke 应使用 SuperAgent V4 回调或专门 V4 fixture。
|
||||
|
||||
启用条件：
|
||||
|
||||
|
||||
Reference in New Issue
Block a user