fix: clarify client amounts and log date filters

This commit is contained in:
hectorzhao
2026-08-27 19:50:12 +08:00
parent ec721bf95a
commit 33fa3709d9
18 changed files with 136 additions and 82 deletions
@@ -1702,6 +1702,7 @@
8. 长短信任一分片返回非成功终态时,系统必须通过该分片审计关联的提交记录识别当前发送尝试,不得仅以主记录保存的首片上游消息号判断;确认属于当前尝试后,整条短信立即进入失败/补发或退款终态,无需等待其余分片回执。
9. 回执和上行投递方式不得由运营人员选择。企业应用开通CMPP接口即按CMPP投递,开通HTTP接口且对应Webhook地址非空即按HTTP投递,两者同时满足时双投;任一地址为空时只跳过该类HTTP事件。运营端企业应用HTTP参数页必须始终可编辑回执和上行Webhook地址,不因HTTP接口开关关闭而隐藏。
10. Gateway向企业应用发送真实 `CMPP_DELIVER` 以及收到企业应用真实 `CMPP_DELIVER_RESP` 时,都必须各写一条通讯交互日志,分别使用“平台→企业应用”和“企业应用→平台”方向;下游投递记录继续承担排队、重试和ACK业务状态,不得以通讯日志替代。
11. 运营端“系统与操作日志”和“通讯交互日志”以及客户端“系统日志”必须提供可选起止日期的区间控件,首次进入和重置后默认北京时间近7天;查询、分页和导出必须使用同一真实后端日期边界,结束日期包含当日23:59:59.999,不得只在前端裁剪列表。
## 2026-07-26 依赖安全治理补充
+14
View File
@@ -2811,6 +2811,20 @@
- 到期日志按 `archiveMonth=YYYY-MM` 进入归档表,在线表只删除已成功归档的记录,原始 id 和详情不丢失。
- 归档使用有界小批量和 `SKIP LOCKED`;归档失败时源日志仍保留,不阻塞正常日志写入。
### TC-LOG-012 系统日志日期区间默认值与后端过滤
- 优先级:P1
- 前置条件:运营端和客户端均存在跨越7天以上的系统日志,通讯交互日志也存在跨日数据。
- 步骤:
1. 分别进入运营端“系统与操作日志”“通讯交互日志”和客户端“系统日志”。
2. 核对日期区间默认值,查询并翻页。
3. 改为自定义起止日期后再次查询;运营端同时导出系统与操作日志。
4. 点击重置。
- 预期结果:
- 三处日期区间初始和重置后均为北京时间近7天,允许通过日期控件选择任意合法区间。
- 请求真实携带`createdAtFrom/createdAtTo`,后端按北京时间当日00:00:00.000至结束日23:59:59.999过滤。
- 列表总数、分页和导出使用同一日期条件,不返回区间外数据。
### TC-CUSTOMER-001 运营端创建客户并初始化租户
- 优先级:P0
+7
View File
@@ -4057,3 +4057,10 @@ git diff --check
- 测试环境真实服务核验定位到客户端接口对接页原500的根因:测试机使用HTTP源地址,而后端强制要求HTTPS。追加提交`070a951e7cffb467734a4486ac46a83605a7f218`,默认仍拒绝不安全源地址,仅允许隔离测试环境通过`HTTP_API_ALLOW_INSECURE_ORIGIN=true`显式放行HTTP;新增OpenAPI单测11/11和API正式构建通过。
- 第二次发布前重新建立并校验恢复点`/opt/cmpp-platform-backups/ui-http-origin-20260827T104430Z`。最终部署标记为`070a951e7cffb467734a4486ac46a83605a7f218`;以`screenshot_client`所属企业的真实应用直接调用配置、凭据、Webhook、请求日志、投递日志五个服务方法全部成功,配置接口不再抛出Internal server error。8项核心服务active、API/Gateway健康、结果Stream`pending=0/lag=0`、发布后error级日志为空,运营端/客户端登录页及API健康地址从工作站访问均HTTP 200。
- 两次发布均仅操作测试环境`100.93.204.60`;未访问、回退、覆盖或部署预生产`8.160.169.106`,未发送短信或执行压力测试。第二阶段孤立审核任务事务/补偿仍未实施。
## 2026-08-27 客户端金额样式复核与系统日志日期区间(本地门禁)
- 用户在另一台电脑复核后指出首页金额视觉没有变化。重新比对最终CSS确认首次改动仅把原有约30px深色粗体重复声明为30px深色粗体,视觉差异不足;同时`MoneyText`组件不生成`.money-text`类,首次样式中的后代选择器不会命中。现改为明确的Arial/微软雅黑普通系统字体、38px、500字重、纯黑`#111111`,并显式清除背景、文字填充、阴影及特殊裁剪效果;最近充值使用28px紧凑规格。
- 运营端系统与操作日志、运营端通讯交互日志、客户端系统日志均改为可选起止日期的真实日期区间,初始及重置默认北京时间近7天。查询、分页和导出统一向后端传递`createdAtFrom/createdAtTo`,后端按开始日00:00:00.000至结束日23:59:59.999Asia/Shanghai)过滤。
- Chrome视觉夹具计算样式确认三个关键金额均为`rgb(17,17,17)`、38px、500字重、Arial/微软雅黑且控制台无error/warn;前端TypeScript与Vite生产构建通过。API正式TypeScript构建、操作日志/通讯日志专项34项、API全量45套532项通过。
- 本节当前仅记录本地修复和门禁;测试环境发布与登录后真实页面复核需在提交并重新建立恢复资产后完成。预生产未访问。