4.1 KiB
系统接口承接核对
核对基线：旧后端 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 冲突，因此没有批量改写真实账号。