cangku

yanhui/cangku

Fork 0

forked from lunanting/cangku

Commit Graph

Author	SHA1	Message	Date
yanhui	6a5f6e8ae0	refactor(wst): 页面名去掉「24 小时」，改为「发货时效（到点未发即超时）」规则完全不动，只改名字，消除误导。 ## 为什么改页面原名「仓储中心 24 小时发货时效」，但判定规则是「到 13:00 / 18:00 核验时刻仍未发货即超时」，没有满 24 小时的门槛（业务 2026-10-20 已三次纠偏定版）。名字和规则打架，导致看的人以为「不满 24 小时不该算超时」。实测例子：10-27 16:00 创建的单，今天 13:00 核验时只等了 21 小时就被判超时； 13:00 轮 599 单里有 416 单属于 10-27 16 点后创建。业务看到就问「创建时间都在 7 点后，为什么算超时」—— 其实是名字里的「24 小时」在误导（那些是昨天晚上的单，不是今天的）。 ## 改了什么用户可见（2 处）： - 侧栏菜单：`仓储中心24小时发货时效` → `仓储中心发货时效` （不加括号：侧栏现有最长 label 12 字，加了会到 18 字溢出） - 页面标题：`仓储中心 24 小时发货时效` → `仓储中心发货时效（到点未发即超时）` 其余为注释同步（8 个文件），代码逻辑与判定口径零改动： `warehouseShipTimelinessRegistry/Service/NotifyJob/NotifySettings`、 `warehouseLogisticsExceptionRegistry`、`frontend/api/warehouseShipTimeliness`、`backend/index`。 ## 不变的部分 - 核验时点、窗口上界（07:00 / 16:00）、仓级例外（山东 15:00、洛宁 13:00） - 数据源与起算点（订单两表 + `created`） - 钉钉推送抬头本来就是「【仓储中心发货时效】」，不用改 ## 验证 - 前端 eslint 通过、`npm run build` 通过（31.86s） - 浏览器真渲染（本地 5173，等足 75 秒数据返回）： - 标题 = `仓储中心发货时效（到点未发即超时）` - 侧栏项 = `仓储中心发货时效`，全页 `body` 内已无「24小时」字样 - 数据正常渲染：超时未发 599 单 / 不计考核 849 / 涉及仓库 8 个 / 最久未发 13 天 - 明细「创建时间」列完整显示 `2026-10-27 19:xx` 这类日期，不存在时区错位 - 无 pageerror - 后端 `npm run check`：本次只动注释，不影响	2026-10-28 14:30:54 +08:00
yanhui	f766549b1a	feat(wst): 发货时效两轮核验完成后各推一次钉钉群业务原话（2026-10-27）：「发货时效也需要钉钉通知：13 点核验 7 点前的超时单，核验完成后通知；18:00 核验的订单，核验完成后也通知。」 ## 做了什么 - 新增 `warehouseShipTimelinessNotifySettings`：配置与状态存取，两个轮次各一个推送时刻（NOON 默认 13:05 / AFTERNOON 默认 18:05），加签密钥走 resilientSecretStore。 - 新增 `warehouseShipTimelinessNotifyJob`：正文组装 + 每分钟 tick + 启动后 30 分钟补推窗口。 - 路由：`GET/PUT /api/warehouse-ship-timeliness/notify/settings`、 `GET .../notify/state`、`POST .../notify/run`（dryRun / probe / force）。 - `index.js` 注册 `startShipTimelinessNotifyScheduler()`。 - 前端：页面右上「钉钉通知」→ 弹窗（开关、两个时刻、webhook、加签密钥、明细条数、 @所有人、页面链接、受控预览块、上次推送）。顺带把 held 明细弹窗的 `destroyOnClose` 改成 `destroyOnHidden`（antd 5.25 已弃用）。 ## 口径要点 - 一天两推，各绑一个轮次：13:00 轮核验「今天 07:00 前审核」、18:00 轮核验「截止 16:00 前审核」（都含历史未发）。两轮互不影响，两个时刻配成同一个 HH:mm 时两轮都推。 - 默认核验点 + 5 分钟，不是整点：状态镜像 `query_time` 要略晚于核验时刻，整点推容易 `coversDeadline=false`（数据没覆盖核验点、超时数偏大）。这种时候消息里会带一行提示，仍照发（业务要的是「核验完就通知」）。 - 去重键 `<北京日期>\|<轮次键>`，一天两轮各自独立；推送成功才写状态，失败不写。 - 0 单超时也推（群里看到「本轮 0 单」= 任务没挂）。 - 明细一行 = 仓｜内部单号｜线上单号｜审核时间｜已等 X 小时；历史单的审核时间带 MM-DD —— 13:00 轮含历史未发单，只写「审核 16:13」会被读成今天。 - 明细按仓聚集 + 每仓保底 1 条，钉钉 text 超长时从末尾砍。 ## 验证 - `backend/test/warehouseShipTimelinessNotify.test.js` 新增 17 条，全过。 - 后端 `check-syntax` 通过；`node --test test/.test.js` 491 条 / 489 过 / 2 失败，失败两条是既有环境问题（`cloudDatabaseConfigCache` 负缓存用例依赖数据库不可达、 `resilientSecretStore` 的 0600 权限断言在 Windows 恒为 0o666），与本改动无关。 - 前端 `eslint src/pages/WarehouseShipTimeliness src/api/warehouseShipTimeliness.js` 0 错； `vite build` 通过（含 `verify-router-lazy`）。 - 本地真渲染：页面右上出现「钉钉通知」，弹窗完整渲染、点「预览正文」出正文块，无 pageerror （验收时把 `/notify/*` 全部 mock —— 本地系统库与生产是同一个，避免写坏生产配置）。 - 本地实数据预览（13:00 轮，冷查 46s）：超时 15 单 / 4 个仓 / 不计考核 672 / 剔除 1；同一时刻请求 18:00 轮返回 `before_deadline`（未到 18:00 不推半成品）。 ## 风险与回退 - 默认关闭（`enabled=false`）且未配 webhook 时一切接口只返回 `not_configured`，不会发消息。 - 想彻底停掉：`DISABLE_WST_NOTIFY=true` 或把推送开关关掉；两者都不影响页面本身。 - 回退：删掉 `startShipTimelinessNotifyScheduler()` 一行即可停调度，新增文件无副作用。	2026-10-27 15:43:18 +08:00

Author

SHA1

Message

Date

yanhui

6a5f6e8ae0

refactor(wst): 页面名去掉「24 小时」，改为「发货时效（到点未发即超时）」

规则完全不动，只改名字，消除误导。

## 为什么改

页面原名「仓储中心 24 小时发货时效」，但判定规则是「到 13:00 / 18:00
核验时刻仍未发货即超时」，**没有满 24 小时的门槛**（业务 2026-10-20 已三次纠偏定版）。
名字和规则打架，导致看的人以为「不满 24 小时不该算超时」。

实测例子：10-27 16:00 创建的单，今天 13:00 核验时只等了 **21 小时**就被判超时；
13:00 轮 599 单里有 416 单属于 10-27 16 点后创建。业务看到就问「创建时间都在 7 点后，
为什么算超时」—— 其实是名字里的「24 小时」在误导（那些是**昨天**晚上的单，
不是今天的）。

## 改了什么

用户可见（2 处）：
- 侧栏菜单：`仓储中心24小时发货时效` → `仓储中心发货时效`
  （不加括号：侧栏现有最长 label 12 字，加了会到 18 字溢出）
- 页面标题：`仓储中心 24 小时发货时效` → `仓储中心发货时效（到点未发即超时）`

其余为注释同步（8 个文件），代码逻辑与判定口径**零改动**：
`warehouseShipTimelinessRegistry/Service/NotifyJob/NotifySettings`、
`warehouseLogisticsExceptionRegistry`、`frontend/api/warehouseShipTimeliness`、`backend/index`。

## 不变的部分

- 核验时点、窗口上界（07:00 / 16:00）、仓级例外（山东 15:00、洛宁 13:00）
- 数据源与起算点（订单两表 + `created`）
- 钉钉推送抬头本来就是「【仓储中心发货时效】」，不用改

## 验证

- 前端 eslint 通过、`npm run build` 通过（31.86s）
- 浏览器真渲染（本地 5173，等足 75 秒数据返回）：
  - 标题 = `仓储中心发货时效（到点未发即超时）`
  - 侧栏项 = `仓储中心发货时效`，全页 `body` 内已无「24小时」字样
  - 数据正常渲染：超时未发 599 单 / 不计考核 849 / 涉及仓库 8 个 / 最久未发 13 天
  - 明细「创建时间」列完整显示 `2026-10-27 19:xx` 这类日期，不存在时区错位
  - 无 pageerror
- 后端 `npm run check`：本次只动注释，不影响

2026-10-28 14:30:54 +08:00

yanhui

f766549b1a

feat(wst): 发货时效两轮核验完成后各推一次钉钉群

业务原话（2026-10-27）：「发货时效也需要钉钉通知：13 点核验 7 点前的超时单，
核验完成后通知；18:00 核验的订单，核验完成后也通知。」

## 做了什么

- 新增 `warehouseShipTimelinessNotifySettings`：配置与状态存取，两个轮次各一个推送时刻
  （NOON 默认 13:05 / AFTERNOON 默认 18:05），加签密钥走 resilientSecretStore。
- 新增 `warehouseShipTimelinessNotifyJob`：正文组装 + 每分钟 tick + 启动后 30 分钟补推窗口。
- 路由：`GET/PUT /api/warehouse-ship-timeliness/notify/settings`、
  `GET .../notify/state`、`POST .../notify/run`（dryRun / probe / force）。
- `index.js` 注册 `startShipTimelinessNotifyScheduler()`。
- 前端：页面右上「钉钉通知」→ 弹窗（开关、两个时刻、webhook、加签密钥、明细条数、
  @所有人、页面链接、受控预览块、上次推送）。顺带把 held 明细弹窗的 `destroyOnClose`
  改成 `destroyOnHidden`（antd 5.25 已弃用）。

## 口径要点

- **一天两推，各绑一个轮次**：13:00 轮核验「今天 07:00 前审核」、18:00 轮核验
  「截止 16:00 前审核」（都含历史未发）。两轮互不影响，两个时刻配成同一个 HH:mm 时两轮都推。
- **默认核验点 + 5 分钟**，不是整点：状态镜像 `query_time` 要略晚于核验时刻，
  整点推容易 `coversDeadline=false`（数据没覆盖核验点、超时数偏大）。
  这种时候消息里会带一行提示，仍照发（业务要的是「核验完就通知」）。
- **去重键 `<北京日期>|<轮次键>`**，一天两轮各自独立；推送成功才写状态，失败不写。
- **0 单超时也推**（群里看到「本轮 0 单」= 任务没挂）。
- **明细一行 = 仓｜内部单号｜线上单号｜审核 时间｜已等 X 小时**；
  历史单的审核时间带 MM-DD —— 13:00 轮含历史未发单，只写「审核 16:13」会被读成今天。
- 明细按仓聚集 + 每仓保底 1 条，钉钉 text 超长时从末尾砍。

## 验证

- `backend/test/warehouseShipTimelinessNotify.test.js` 新增 17 条，全过。
- 后端 `check-syntax` 通过；`node --test test/*.test.js` 491 条 / 489 过 / 2 失败，
  失败两条是既有环境问题（`cloudDatabaseConfigCache` 负缓存用例依赖数据库不可达、
  `resilientSecretStore` 的 0600 权限断言在 Windows 恒为 0o666），与本改动无关。
- 前端 `eslint src/pages/WarehouseShipTimeliness src/api/warehouseShipTimeliness.js` 0 错；
  `vite build` 通过（含 `verify-router-lazy`）。
- 本地真渲染：页面右上出现「钉钉通知」，弹窗完整渲染、点「预览正文」出正文块，无 pageerror
  （验收时把 `/notify/**` 全部 mock —— 本地系统库与生产是同一个，避免写坏生产配置）。
- 本地实数据预览（13:00 轮，冷查 46s）：超时 15 单 / 4 个仓 / 不计考核 672 / 剔除 1；
  同一时刻请求 18:00 轮返回 `before_deadline`（未到 18:00 不推半成品）。

## 风险与回退

- 默认关闭（`enabled=false`）且未配 webhook 时一切接口只返回 `not_configured`，不会发消息。
- 想彻底停掉：`DISABLE_WST_NOTIFY=true` 或把推送开关关掉；两者都不影响页面本身。
- 回退：删掉 `startShipTimelinessNotifyScheduler()` 一行即可停调度，新增文件无副作用。

2026-10-27 15:43:18 +08:00

2 Commits