62 lines
3.6 KiB
Markdown
62 lines
3.6 KiB
Markdown
# Design: 后台资产信息设备信号摘要与审计日志可读化
|
||
|
||
## Context
|
||
|
||
当前后台资产信息相关页面已经具备设备实时信息区块和共享的操作审计日志组件，但和最新要求相比存在两个核心问题：
|
||
|
||
- 设备实时信息依赖前端根据 `RSRP/RSRQ/SINR` 计算“信号强度”，并直接展示 `RSSI/RSRP/RSRQ/SINR` 原始指标；而最新要求希望后台直接消费后端总结好的 `signal_quality` 与 `signal_bad_reason`。
|
||
- 操作审计日志虽然已经开始消费 `operation_content_*`，但规则仍不够稳定，容易继续暴露 `xxxid/xxxID` 这类内部字段，也没有围绕新增可读字段形成明确展示约束。
|
||
|
||
同时，操作审计日志组件是共享组件，既出现在资产详情页，也出现在卡/设备列表页的审计日志弹窗中，因此展示规则需要一次性收敛。
|
||
|
||
## Goals / Non-Goals
|
||
|
||
- Goals:
|
||
- 后台设备实时信息直接展示后端返回的信号摘要字段
|
||
- 后台页面不再把原始信号指标作为核心展示项
|
||
- 操作审计日志优先展示业务可读字段，并系统性隐藏内部 ID 字段
|
||
- 让资产详情页与日志弹窗共用同一套展示规则
|
||
- Non-Goals:
|
||
- 不改造 C 端接口与 C 端页面
|
||
- 不修改后端信号判断规则或日志生成逻辑
|
||
- 不把本次提案扩展成设备列表、卡列表其他非日志字段的全面重构
|
||
|
||
## Decisions
|
||
|
||
- Decision: 后台设备实时信息以 `signal_quality` 和 `signal_bad_reason` 作为信号展示真值来源
|
||
|
||
- Rationale: 最新接口已经把信号综合判断和可能原因抽象成稳定文案，继续沿用前端启发式计算会造成“双重口径”。
|
||
|
||
- Decision: `RSSI/RSRP/RSRQ/SINR` 原始字段仍保留在类型层，但从后台页面展示中移除
|
||
|
||
- Rationale: 文档明确说明原始字段仍保留，只是不再作为当前页面的展示主体；保留类型兼容性更稳妥。
|
||
|
||
- Decision: 操作审计日志统一优先展示可读业务字段，内部 `id` / `*_id` / `*Id` / `*ID` 一律隐藏
|
||
|
||
- Rationale: 新增日志字段的目的就是减少运营对内部标识的理解成本，因此展示层应明确偏向业务字段。
|
||
|
||
- Decision: 共享 `OperationLogsCard` 作为唯一日志展示实现，不在资产详情页和弹窗中分叉规则
|
||
|
||
- Rationale: 当前弹窗与资产详情页共用同一组件，保持单一规则可以避免不同入口出现展示漂移。
|
||
|
||
- Decision: `signal_bad_reason` 按“有值就展示，无值则显示占位”的方式处理
|
||
- Rationale: 文档把它定义为信号较弱时的怀疑原因提示，但接口仍可能返回空值或缺失值，前端需要稳定兜底。
|
||
|
||
## Risks / Trade-offs
|
||
|
||
- 活跃变更 `update-order-upload-and-device-switch-mode` 同样修改 `BasicInfoCard.vue`，落地时需要避免覆盖其尚未归档的页面调整。
|
||
- 共享日志组件的规则收紧后，会同时影响资产详情页和列表页弹窗；这是预期收益，但也要求验证面更广。
|
||
- 统一隐藏 `xxxid/xxxID` 字段后，若后端暂未补齐某些操作类型的可读字段，个别日志行的展示信息可能变少。
|
||
|
||
## Migration Plan
|
||
|
||
1. 扩展 admin 资产实时状态类型，接收新增信号摘要字段。
|
||
2. 调整后台设备实时信息 UI，用摘要字段替代旧信号展示。
|
||
3. 收敛旧信号计算逻辑的页面使用点。
|
||
4. 调整共享操作审计日志组件的字段优先级与 ID 过滤规则。
|
||
5. 在资产详情页和列表页日志弹窗中完成联调验证。
|
||
|
||
## Open Questions
|
||
|
||
- 暂无。本提案默认“C 端不纳入本次范围”已经确定。
|