mirror of
https://github.com/hpd840321/starRiverProperty.git
synced 2026-06-09 08:20:31 +08:00
反编译工作区
f7da04caea
Redesign addVisitor four-phase flow: - Phase1: ALWAYS query person detail (orgIds for policy lookup) - Phase2: candidate = caller floors or org floorList - Phase3: ALWAYS check policy; intersect candidate with allow - Phase4: empty set validation Fixes UC-02 bypass: policy was entirely skipped when caller provided floorIds. Now policy always constrains. Bump v2.0.19
76 lines
3.9 KiB
Markdown
76 lines
3.9 KiB
Markdown
# cw-elevator-application v2.0.6 SQL与代码一致性审核记录
|
||
|
||
**审核目标**：确认发布规范涉及 SQL 脚本与当前代码逻辑一致，满足实施交付依据留档要求。
|
||
**审核范围**：`tenant_visitor_floor_policy` 建表脚本、初始化脚本、访客派梯策略读取与求交流程。
|
||
**审核时间**：`2026-04-29`
|
||
**审核人**：`____________`
|
||
|
||
---
|
||
|
||
## 1. 审核过程
|
||
|
||
1. 审阅 SQL 脚本：
|
||
- `docs/sql/tenant_visitor_floor_policy.sql`
|
||
- `docs/sql/tenant_visitor_floor_policy_init_guangfa_fund.sql`
|
||
2. 审阅代码路径：
|
||
- `cw-elevator-application-service/.../PersonRuleServiceImpl#addVisitor`
|
||
- `cw-elevator-application-data/.../TenantVisitorFloorPolicyMapper.xml`
|
||
- `cw-elevator-application-data/.../TenantVisitorFloorPolicyDto`
|
||
3. 做场景对照：
|
||
- UC-01：调用方未传 `floorIds`
|
||
- UC-02：调用方已传 `floorIds`
|
||
- 策略缺失/无效 JSON/交集为空等异常分支
|
||
4. 形成一致性结论与风险提示，并纳入发布包。
|
||
|
||
---
|
||
|
||
## 2. 审核依据与结果
|
||
|
||
| 检查项 | SQL 依据 | 代码依据 | 结论 |
|
||
|------|----------|----------|------|
|
||
| 策略表字段是否齐全（business_id/policy_type/allow_zone_ids/building_id/enabled/policy_version） | `tenant_visitor_floor_policy.sql` DDL 定义上述字段 | Mapper 查询并映射到 DTO 同名语义字段 | 一致 |
|
||
| 代码是否只读取“启用+租户默认+INTERSECT_ALLOWLIST”策略 | 初始化脚本使用 `policy_type='INTERSECT_ALLOWLIST'`、`building_id=NULL`、`enabled=1` | Mapper `WHERE enabled=1 AND policy_type='INTERSECT_ALLOWLIST' AND (building_id IS NULL OR building_id='')` | 一致 |
|
||
| allow_zone_ids 的数据格式是否匹配代码解析方式 | SQL 注释与初始化脚本均为 JSON 数组字符串（如 `["605560545117995008"]`） | `parseAllowZoneIds` 使用 `JSON.parseArray(..., String.class)` 解析 | 一致 |
|
||
| 未传 floorIds 时是否执行“被访人楼层 ∩ 策略楼层” | 策略表提供 allowlist 数据来源 | `addVisitor` 在 `!callerProvidedFloors` 分支求交 | 一致 |
|
||
| 交集为空是否按规范失败 | 初始化脚本可构造交集为空场景 | `intersected.isEmpty()` 返回 `76260532` | 一致 |
|
||
| 已传 floorIds 是否跳过策略表 | SQL 与此分支无冲突 | `callerProvidedFloors=true` 时不进入策略读取分支 | 一致 |
|
||
|
||
---
|
||
|
||
## 3. 关键证据（摘录）
|
||
|
||
- 代码读取策略（启用、类型、租户默认）来自 `TenantVisitorFloorPolicyMapper.xml`。
|
||
- 代码在 `PersonRuleServiceImpl#addVisitor` 中：
|
||
- `!callerProvidedFloors` 才读取被访人楼层与租户策略；
|
||
- `allow_zone_ids` 解析成功且非空才参与求交；
|
||
- 求交为空返回 `76260532`；
|
||
- 调用方已传楼层时不走策略求交流程。
|
||
- 初始化脚本 `tenant_visitor_floor_policy_init_guangfa_fund.sql` 的字段取值与上述查询条件完全兼容。
|
||
|
||
---
|
||
|
||
## 4. 审核结论
|
||
|
||
**结论：通过。**
|
||
发布规范涉及的 SQL 脚本内容与当前代码逻辑一致，满足 v2.0.6 发布包“数据库脚本 + 功能升级说明 + 实施交付依据”要求。
|
||
|
||
---
|
||
|
||
## 5. 风险提示与建议
|
||
|
||
1. **唯一性治理风险（中）**
|
||
DDL 使用 `UNIQUE KEY (business_id, building_id)`，在 MySQL 下 `building_id=NULL` 可能存在多行；当前代码通过 `ORDER BY updated_at DESC, policy_version DESC LIMIT 1` 取最新一条，不阻断功能，但建议运维侧增加“每租户默认策略唯一”巡检。
|
||
2. **配置数据质量风险（中）**
|
||
`allow_zone_ids` 必须是电梯域 `zone_id` 字符串数组，若误填其它系统 UUID 会导致策略不生效或交集为空。
|
||
|
||
---
|
||
|
||
## 6. 签字确认
|
||
|
||
| 角色 | 姓名 | 日期 | 备注 |
|
||
|------|------|------|------|
|
||
| 审核人 | `____________` | `____` | `____` |
|
||
| 实施负责人 | `____________` | `____` | `____` |
|
||
| 甲方确认（可选） | `____________` | `____` | `____` |
|
||
|