fix: 同步原生账号启停与商务审核状态

2026-11-03 22:02:51 +08:00
parent 075d94a51e
commit fc17b384ee
10 changed files with 423 additions and 7 deletions
@@ -78,4 +78,6 @@
 - 游戏分布只列当前渠道已通过的推广游戏，读取 `tab_sw_report_day` / `tab_sw_report_day_key`，人数按当前去重模式去重，金额固定模式 0。累计起点保留旧实现从当前人数口径的最早日汇总取得、缺省当天的规则，截止上海当天；不能与列表原始注册/充值口径混用。金额先保留两位再排序，同金额按游戏 ID。
 - 新增渠道由 biz 决定一级、待审核 `-3`、默认注册类型和七天结算周期；data 在对应源平台库同事务写渠道、结算记录、商务渠道关系。密码复用旧 cmf 格式和 `SW_SDK_AUTH_CODE`。MySQL 创建使用固定连接持有账号命名锁直到事务提交，商务关系在行锁内追加；命名锁的真实并发验证留待最终隔离平台库联调。没有创建真实平台测试渠道，也没有伪造主库同步副本。
 - 渠道批次通过全量 Go 检查、前端 ESLint/生产构建、独立主库和源平台 SQLite 的 TCP HTTP 验证。`channel-http-2026-11-03.json` 记录实际 sw7 会话请求，当前主库渠道数据未接入，lx/hw/yq 正常绑定选项分别为 17/20/20 条。`channel-page-2026-11-03.json` 核对一级商务新增入口、平台切换清空绑定、跨平台同号、零游戏数入口、缺失指标提示及新增提交参数。画像入口继续随画像用例迁移，当前不将整个渠道菜单标为完成。
+- 核对剩余用户接口的基线差异及 Kra 原生能力，记录于 `system-api-audit.md`；保留历史别名未注册、Excel 协议未兼容等差异，不把能力对应表当成接口兼容完成证明。商务页面仍不增加原页面没有的编辑/删除/导入/导出入口。
+- 修复原生用户启停只更新 enable、商务状态不同步的问题：由 biz 决定状态联动，在 data 行锁事务中一起写入；未启用时保留待审/驳回，个人资料请求不能自行解除管理员限制。当前 45 个真实用户只读检查未发现已有冲突，没有批量更新真实账号；正常启停、审核状态保留、失败回滚和越权通过隔离 HTTP/仓储/领域测试。全量 Go 测试通过，实际服务检查记录为 `user-status-http-2026-11-03.json`。
 - 当前没有执行最终旧数据库复制与迁移验收。
@@ -0,0 +1,42 @@
+# 系统接口承接核对
+
+核对基线：旧后端 `d31082f4a7816d4c83544b8f54e6f42a3b2132b1` 至 `main`。原 SQL 的接口表按控制器收集接口，因此包含基线前已有的 RuoYi 用户管理接口；不能把所有记录都当成新商务新增功能，也不能只凭新路由存在就宣布功能完成。
+
+## 商务新增与改动
+
+`SysUserController` 的 Git 差异主要是商务列表语义、添加子商务，以及直属渠道、平台绑定和两种商务画像。用户列表查询新增商务树、姓名/等级过滤、直属渠道与正常绑定数量；添加子商务新增层级、归属与偏好初始化。当前列表、子商务、偏好和平台绑定已迁移；商务/平台商务画像仍未完成。
+
+原用户控制器中的以下方法在基线前已经存在，旧 `BusMgmt/BusinessList.vue` 没有为它们增加实际操作入口。新商务页面不据此增加编辑、删除、导入、导出、角色分配等按钮。
+
+| 旧目标别名 | 当前 Kra 能力 / 核对结果 |
+| --- | --- |
+| `GET /sw/business`（新增表单初始化） | 原生用户表单通过用户、角色、部门接口加载；商务新增表单由后端决定商务层级，不开放角色选择 |
+| `DELETE /sw/business/:userIds` | 原生 `DELETE /user/deleteUser`；旧商务列表没有删除入口 |
+| `GET /sw/business/optionselect` | 原生用户列表/部门用户查询；商务与报表实际使用各自的可见范围接口 |
+| `PUT /sw/business/resetPwd` | 原生 `POST /user/resetPassword`；商务自助找回密码使用已迁移的独立流程 |
+| `PUT /sw/business/changeStatus` | 原生 `PUT /user/setUserInfo`；本批补齐 enable 与 business_status 联动 |
+| `GET /sw/business/authRole/:userId` | 原生用户角色资料及角色列表 |
+| `PUT /sw/business/authRole` | 原生 `POST /user/setUserAuthorities` |
+| `GET /sw/business/deptTree` | 原生 `POST /department/getDepartmentList` |
+| `GET /sw/business/list/dept/:deptId` | 原生 `GET /department/getDepartmentUsers` |
+| `POST /sw/business/export` | RuoYi Excel 导出协议尚未增加别名；旧导出调用共享查询构造器，会继承商务过滤，不能把原生通用导出直接算成相同协议已实现 |
+| `POST /sw/business/importData` | RuoYi Excel 导入协议尚未实现；当前商务模板没有导入入口 |
+| `GET /sw/business/unlock/:userId` | 原先删除 RuoYi Redis 密码错误键；新系统使用 Kra 鉴权/限制机制，不读取旧 Redis 键。旧协议别名尚未注册 |
+
+以上记录说明框架能力的对应关系，并非宣称旧别名已可调用。别名与原生接口的请求/响应并不相同；最终接口核对仍须保留这项差异，尤其不能把导入/导出列为已经通过兼容验收。当前不删除用户 SQL 中的这些历史接口元数据。
+
+## 账号启停与商务状态
+
+原 RuoYi 用 `status` 同时表示正常、停用、驳回和待审核。迁移后有 Kra 的 `enable` 和保留语义的 `business_status`。原生用户启停此前只改前者，可能导致商务列表仍显示正常，或启用后仍因旧状态无法登录。
+
+本批处理：
+
+- 新建原生账号时，默认启用与禁用状态同步到商务状态。
+- 管理员明确启用时恢复正常；关闭启用时，普通状态变为停用，待审核/驳回继续保留，避免普通资料编辑丢失审核状态。
+- 读取当前业务状态与写入两个字段在同一行锁事务内完成，规则由 biz 回调决定，data 只做持久化。
+- 个人资料不传 enable 时仍按原有字段更新规则处理；传 enable 时不能越过管理员已经写入的停用、待审或驳回状态。
+- 角色范围检查继续执行，不增加商务列表的编辑入口。
+
+隔离 TCP HTTP 测试覆盖原生启停后商务接口返回状态、待审/驳回资料编辑、自行启用被拒绝和不存在用户；仓储测试覆盖失败回滚与越权。现有鉴权测试继续检查停用/待审/驳回会拒绝密码登录和已有会话。
+
+当前 sw7 的 45 个用户已做只读一致性检查，未发现 enable 与 business_status 冲突，因此没有批量改写真实账号。
@@ -0,0 +1,35 @@
+{
+  "scope": "真实 sw7 登录会话，只读检查；未启停任何真实账号。正向启停和审核状态保留由隔离 TCP HTTP 测试覆盖。",
+  "checks": [
+    {
+      "method": "POST",
+      "path": "/user/getUserList",
+      "http": 200,
+      "code": 0,
+      "msg": "获取成功",
+      "passed": true
+    },
+    {
+      "method": "GET",
+      "path": "/sw/business/list?pageNum=1&pageSize=500",
+      "http": 200,
+      "code": 0,
+      "msg": "成功",
+      "passed": true
+    },
+    {
+      "method": "PUT",
+      "path": "/user/setUserInfo",
+      "http": 200,
+      "code": 7,
+      "msg": "ID值不能为空",
+      "passed": true
+    }
+  ],
+  "native_total": 45,
+  "business_total": 45,
+  "checked_users": 45,
+  "inconsistent_states": 0,
+  "response_mismatches": 0,
+  "passed": true
+}