# 权限与租户改造当前进度总览 > 适用范围:`leaudit-platform` 当前权限、地区隔离、租户化、多租户入口模块改造现状 > 更新日期:2026-05-21 > 文档定位:给当前研发/评审快速判断“已经做到哪里、哪些只是方案、哪些已经进代码/数据库、下一步该做什么”。 > 冻结验收入口: > - [冻结版进度盘点与最小冒烟验收-2026-05-21.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/冻结版进度盘点与最小冒烟验收-2026-05-21.md) > - [Pytest全链路验收说明.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/Pytest全链路验收说明.md) --- ## 1. 当前结论 目前这轮改造已经不是纯方案阶段,已经进入: 1. 文档体系基本齐全 2. 数据库租户底座已补齐 3. 登录/当前用户/租户解析/入口模块读取链路,已经有第一轮兼容代码 4. `RBAC` 用户租户设置与首页入口显示,已经完成真实联调修复 5. `RBAC` 管理域与交叉评查任务建单入口,已完成一轮 tenant-first 高风险边界收口 6. 统一权限执行器、统一数据范围收口、角色去硬编码全域治理,还没有完成 换句话说: - `租户主数据底座 + 兼容层`:已开始落地 - `入口模块租户化`:已部分落地,首页读链路已打通 - `RBAC 用户租户维护`:已完成首轮接口与前端联调 - `RBAC/CrossReview 高风险边界`:已完成首轮 tenant-first 收口 - `权限统一执行器`:仍主要停留在设计和骨架层 - `业务模块全量 scope 化`:仅零散改动,未形成统一闭环 - `前端去角色化`:未系统完成 补充一个必须纠偏的认知: - `评查点/评查组` 当前不能再被简单理解成老 `evaluation_points` 主表治理问题 - 新平台真实运行主链路,已经转为 `入口模块 -> 一级业务大类 -> 二级业务子类型 -> 规则集 -> YAML 规则版本 -> 文档评查结果` - 老 `/api/v3/evaluation-points` 与老评查点页面,只能视为兼容链路,不再是新平台主模型 对应专项文档: - [新平台评查点与评查组真实模型梳理.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/新平台评查点与评查组真实模型梳理.md) --- ## 2. 文档层进度 ## 2.1 已完成的核心文档 `docs/权限与地区隔离/` 下当前已具备以下主文档: 1. 架构总方案 - [权限架构全面优化改造方案.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限架构全面优化改造方案.md) 2. 现行权限模型 - [用户与地区权限完整设计方案.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/用户与地区权限完整设计方案.md) - [用户权限与权限点清单.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/用户权限与权限点清单.md) 3. 统一执行器设计 - [统一数据范围执行器设计.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/统一数据范围执行器设计.md) - [统一执行器落地代码骨架与接入示例.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/统一执行器落地代码骨架与接入示例.md) 4. 接口/SQL/测试/排期 - [权限接口矩阵与数据边界清单.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限接口矩阵与数据边界清单.md) - [权限字段映射与SQL改造规范.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限字段映射与SQL改造规范.md) - [权限测试验收与回归用例清单.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限测试验收与回归用例清单.md) - [权限改造实施任务拆解与排期.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限改造实施任务拆解与排期.md) 5. 角色去硬编码专题 - [角色硬编码与接口影响专项补充分析.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/角色硬编码与接口影响专项补充分析.md) - [角色去硬编码迁移清单.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/角色去硬编码迁移清单.md) 6. 地区租户化/多租户专题 - [地区租户化与自定义租户扩展改造方案.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/地区租户化与自定义租户扩展改造方案.md) - [租户主数据模型设计.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/租户主数据模型设计.md) - [权限、租户能力与数据范围职责边界说明.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限、租户能力与数据范围职责边界说明.md) - [地区到租户编码映射清洗清单.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/地区到租户编码映射清洗清单.md) - [入口模块租户配置表迁移方案.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/入口模块租户配置表迁移方案.md) - [自定义租户功能连带影响深度补充.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/自定义租户功能连带影响深度补充.md) 结论: - 文档覆盖面已经够全 - 现在缺的不是“再补大方向设计稿” - 现在更缺“按文档逐步落代码、落表、落验证” ## 2.2 文档导航状态 当前存在两套导航: 1. 新总导航 - [权限文档总导航与阅读顺序.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限文档总导航与阅读顺序.md) 2. 旧导航 - [权限与地区隔离文档导航.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限与地区隔离文档导航.md) 其中旧导航仍保留了这类旧口径: - 只做 `RBAC + 单地区数据隔离` - 用户地区只认 `sso_users.area` - 角色主线只保留 `provincial_admin/admin/common` 这和当前已经推进的“地区租户化、tenant_code、租户主数据、入口模块租户映射”方向已经不一致。 结论: - 旧导航不能再作为现行总入口 - 后续阅读应以 [权限文档总导航与阅读顺序.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限文档总导航与阅读顺序.md) 为准 补充一个当前必须单列的新专题: - [规则域多租户方案A实施计划.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/规则域多租户方案A实施计划.md) 这个文档的作用不是重复讲租户大方向,而是专门收口: 1. 新平台规则配置 2. 评查组与规则绑定 3. 规则集与规则版本 4. 评查运行结果链路 它已经明确把规则域定案为: 1. 共享业务树 2. 租户规则绑定 3. `TENANT -> PROVINCIAL -> PUBLIC` 生效顺序 4. 运行结果快照 tenant-first 当前规则域代码进度已推进到: 1. 读侧 tenant-first 已完成 2. 规则组绑定写侧 tenant 化已完成 3. 规则配置来源态字段已完成 4. 规则版本 lineage 快照已完成第一轮 5. 剩余主要是新库执行迁移 SQL 与前端来源态联调 --- ## 3. 数据库层进度 ## 3.1 已完成 数据库底座已经补齐并执行过: 1. [schema_tenant_foundation.sql](/home/wren-dev/Porject/leaudit-platform/scripts/创建sql/schema_tenant_foundation.sql) 2. [schema_entry_module_tenants.sql](/home/wren-dev/Porject/leaudit-platform/scripts/创建sql/schema_entry_module_tenants.sql) 已落地对象包括: 1. `sys_tenants` 2. `sys_tenant_aliases` 3. `sys_tenant_feature_flags` 4. `leaudit_entry_module_tenants` 5. `sso_users.tenant_code` 同时已做过: 1. 基础租户种子数据初始化 2. 历史 `area -> tenant_code` 回填 3. 入口模块旧 `areas` JSON 到租户关系表的初始化迁移 ## 3.2 当前意义 这一步很关键,因为它说明当前系统已经不再只是“设计租户化”,而是数据库已经具备: 1. 租户主数据查询基础 2. 历史地区别名兼容基础 3. 功能级租户启用开关基础 4. 入口模块按租户配置的关系化基础 ## 3.3 仍未完成 数据库层目前仍不是“全量租户化完毕”,主要还差: 1. 更多业务表是否需要补 `tenant_code` 2. 历史 `area/region/default/省级/空值` 残留数据的全量清洗 3. 其他模块是否仍只靠中文地区名落库/查询 4. 更完整的租户写接口与后台维护能力 --- ## 4. 代码层进度 ## 4.1 已明确落地的后端能力 当前已经落地了一批“租户兼容层”代码,不再只是文档: 1. 统一租户解析器 - [tenantResolver.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/impl/tenantResolver.py) 2. 旧 `sso_users` 结构兼容 - [ssoUserCompat.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/impl/ssoUserCompat.py) 3. 租户主数据服务 - [tenantServiceImpl.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/impl/tenantServiceImpl.py) 4. 租户接口控制器 - [tenantController.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/controllers/tenantController.py) 5. 登录/当前用户租户解析接入 - [authServiceImpl.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/impl/authServiceImpl.py) 6. 首页入口模块按租户过滤读取 - [homeServiceImpl.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/impl/homeServiceImpl.py) 7. 入口模块管理页租户化读写兼容 - [entryModuleAdminServiceImpl.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/impl/entryModuleAdminServiceImpl.py) 8. `RBAC` 用户租户设置能力与首轮 scope 收口 - [rbacAdminServiceImpl.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/impl/rbacAdminServiceImpl.py) - [rbacAdminController.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/controllers/rbacAdminController.py) 9. 交叉评查任务建单租户边界收口 - [crossReviewServiceImpl.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/impl/crossReviewServiceImpl.py) 10. 首页入口前端兼容修复 - [home.ts](/home/wren-dev/Porject/leaudit-platform/legal-platform-frontend/lib/api/legacy/home/home.ts) - [minimal-scope.ts](/home/wren-dev/Porject/leaudit-platform/legal-platform-frontend/lib/config/minimal-scope.ts) 11. 发布级 `pytest` 黑盒验收基座 - [tests/release/conftest.py](/home/wren-dev/Porject/leaudit-platform/tests/release/conftest.py) - [tests/release/test_g1_rbac_context.py](/home/wren-dev/Porject/leaudit-platform/tests/release/test_g1_rbac_context.py) - [tests/release/test_g2_g3_tenant_entry_chain.py](/home/wren-dev/Porject/leaudit-platform/tests/release/test_g2_g3_tenant_entry_chain.py) - [tests/release/test_role_tenant_matrix.py](/home/wren-dev/Porject/leaudit-platform/tests/release/test_role_tenant_matrix.py) - [tests/release/test_g4_documents.py](/home/wren-dev/Porject/leaudit-platform/tests/release/test_g4_documents.py) - [tests/release/test_g5_rag.py](/home/wren-dev/Porject/leaudit-platform/tests/release/test_g5_rag.py) - [tests/release/test_g5_rule_cross_review_matrix.py](/home/wren-dev/Porject/leaudit-platform/tests/release/test_g5_rule_cross_review_matrix.py) ## 4.2 当前已经解决了什么 这些代码至少已经开始处理下面几类真实问题: 1. 旧环境 `sso_users` 没有 `tenant_code` 时,避免直接 SQL 崩溃 2. 旧环境没有 `sys_tenants/sys_tenant_aliases/leaudit_entry_module_tenants` 时,服务层可降级 3. 登录返回和当前用户接口,开始统一产出 `tenant_code/tenant_name/tenant_type` 4. 首页入口模块和后台入口模块管理,开始从“按 areas JSON”过渡到“按租户关系表” 5. `RBAC` 用户已可通过标准接口设置 `tenant_code` 6. 首页入口前端已兼容识别 `route_path / routePath / target_path / targetPath / path` 7. 入口模块管理端列表/详情接口已收口为 `tenants` 主输出,不再对管理端返回 `areas` 8. 首页交叉评查入口判断已切到 `tenants` 优先,首页后端租户过滤已收紧过宽 fallback 9. `T8 首页入口 + 入口模块后台收口` 已可视为完成 10. 租户页与角色权限页的职责边界已补专项文档,后续实现统一按“权限管人、租户能力管挂载、数据范围管边界”收口 11. `RBAC` 组织树节点已改为 `tenant_code` 优先分组,目标用户角色查询/分配已补跨租户拦截 12. `CrossReview` 创建任务前的“成员用户 + 任务文档”校验已改为 `tenant_code` 优先,旧 `area/region` 仅作兼容回退 13. `T5 评查点` 首轮已切到 `tenant_code` 优先读取/写入,旧 `area` 仅在遗留表无字段时兼容回退 14. `CrossReview` 已补“单任务不得混挂多租户成员/文档”约束,补传文档开始按任务真实挂载内容反推租户边界 15. `CrossReview` 任务列表已开始同时返回标准化 `evaluationTenants`,前端仍保留 `evaluationRegion` 兼容消费 16. `T5-1 评查点读链路` 已完成:当前用户租户上下文与显式筛选租户条件已拆分,读范围判断不再互相污染 17. `T5-2 评查点写链路` 已完成第一轮:创建/更新不再把原始 `area` 文本直接作为归属主语义,统一从解析后的 `writable_scope` 写入 `area/tenant_code/tenant_name` 18. `T5-2 评查点写链路` 已完成第一轮:`PUBLIC/PROVINCIAL` 与 `公共/省级/default` 共享域写入已统一归一化到标准租户编码,未显式指定归属范围的全局写入会被直接拒绝 19. `T5-3 评查点读链路` 已完成第一轮:共享域筛选已优先按 `PUBLIC/PROVINCIAL` 匹配,旧 `公共/default/空值/省局/省级` 仅作为无 `tenant_code` 历史数据 fallback 20. `T5-4 评查点角色判定` 已完成第一轮:主链路的全局/管理能力已改为 `roles.data_scope + evaluation_point:*` 权限推断,不再直接硬编码 `super_admin/provincial_admin/admin` 21. `T5-5 评查点 fallback 收口` 已完成第一轮:查不到数据库用户上下文时,已移除 `payload.user_role` 角色名兜底;fallback 默认不再推断全局范围 22. 发布门禁 `G1-G3` 已不再只靠人工回放,已沉淀为可重复执行 `pytest` 黑盒验收 23. 多租户、多角色的基础矩阵验收已落地,可直接验证: - 全局管理员跨租户查询 - 租户管理员本租户范围限制 - 普通用户管理面 `403` 与业务入口可见性 24. `tenantServiceImpl` 的租户 alias 重复更新 `500` 已修复,租户更新写链路幂等性补齐了一处高频故障点 25. `Document` 主链路已通过发布级黑盒验收: - 上传、列表、详情、更新、附件追加、删除均已验证租户边界 - `mergeMode=new` 附件追加的当前真实行为已确认为“生成新版本” 26. `RAG` 第一轮黑盒验收已完成: - 本租户与公共应用可见性边界已验证 - 数据集详情读取边界已验证 - 当前权限种子下,数据集管理接口仍偏全局管理员模型,这一现实已被测试固化 27. `规则集 / 评查组 / 交叉评查` 第一轮黑盒验收已完成: - 规则集元数据全局可读 - 规则绑定与评查组树按入口模块租户映射过滤 - 交叉评查任务建单已验证“成员/文档不得混租户” ### 4.2.2 新平台主链路本轮新增进度 围绕新平台真实主链路 `入口模块 -> 一级业务大类 -> 二级业务子类型 -> 规则集 -> 规则版本 -> 文档评查结果`,本轮又补了 3 个高风险收口点: 1. `T4 规则控制器鉴权` 已落代码 - [ruleController.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/controllers/ruleController.py) - 已补 `verify_access_token` - 已补 `PermissionServiceImpl` - 权限键已严格对齐 `scripts/创建sql/user_rbac_seed.sql` 中现有 `rules:*` 种子 - `CreateRuleVersion / Publish / Rollback` 的操作人已改为只认当前 token 用户,不再信任前端 body 传入用户ID 2. `T1 上传显式 tenant_code` 已落代码 - [FilesUploadClient.tsx](/home/wren-dev/Porject/leaudit-platform/legal-platform-frontend/app/(audit)/files/upload/FilesUploadClient.tsx) - [files-upload.ts](/home/wren-dev/Porject/leaudit-platform/legal-platform-frontend/lib/api/legacy/files/files-upload.ts) - 上传前端已开始同时传 `tenant_code + region` - 其中 `tenant_code` 作为主边界,`region` 仅保留给旧链路兼容展示与后端兼容解析 3. `T2 文档 tenant/region 混用收口` 已完成第一轮 - [documentServiceImpl.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/impl/documentServiceImpl.py) - `_document_tenant_filter_sql` 已去掉“`tenant_code` 非空时仍放宽匹配空 `tenant_code + region`”逻辑 - `_find_latest_version_candidate` 已去掉“有正式 `tenant_code` 仍可把历史空租户同 region 文档并入版本链”的放宽分支 - 当前版本归并边界已经收紧为: - 有 `tenant_code`:只认同编码文档 - 无 `tenant_code`:才允许按 `region` 兼容命中历史空租户数据 4. `T3 评查组/规则绑定租户边界` 已完成第一轮 - [evaluationPointGroupController.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/controllers/evaluationPointGroupController.py) - [evaluationPointGroupService.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/evaluationPointGroupService.py) - [evaluationPointGroupServiceImpl.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/impl/evaluationPointGroupServiceImpl.py) - [ruleController.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/controllers/ruleController.py) - [ruleService.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/ruleService.py) - [ruleServiceImpl.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/services/impl/ruleServiceImpl.py) - `evaluation-point-groups` 全部 controller -> service 入口已显式传入 `CurrentUserId` - `evaluationPointGroupServiceImpl` 已补“当前用户租户上下文 -> 可访问 entry_module -> 可访问 group/binding”的第一轮统一收口 - `ListGroups / ListAllGroups / ListGroupsByDocumentTypes / GetGroup / GetChildren` 已按 `entry_module -> leaudit_entry_module_tenants` 过滤 - `Create/Update/Delete/Rebind/Batch*` 及 `CreateBinding/UpdateBinding/DeleteBinding/GetRuleTemplate/CreateRuleDraft` 已补当前租户可访问性校验 - `ruleServiceImpl` 当前只对 `ListBindings/CreateBinding/UpdateBinding/DeleteBinding` 四个绑定面接口补租户收口,仍未把 `ListSets/GetVersions/GetContent` 这种全局规则资产接口租户化 5. `T3-1 rule-groups SSR 缓存串租户风险` 已完成修补 - [page.tsx](/home/wren-dev/Porject/leaudit-platform/legal-platform-frontend/app/(audit)/rule-groups/page.tsx) - 进程级 `__ruleGroupsTreeCache__` 已从单桶改为按 token 分桶 - 后端开启按租户收口后,不再把 A 租户分组树缓存直接复用于 B 租户 SSR 请求 这一轮的定位不是“把整条新平台主链路全部租户化完成”,而是先收掉 3 个最危险问题: 1. 规则管理接口裸奔无鉴权 2. 上传链路不显式提交 `tenant_code` 3. 文档与历史版本归并仍可能因为 `region` fallback 错并到错误租户 4. 评查组/规则绑定仍可跨入口模块查看和写入 5. `rule-groups` SSR 缓存可能跨租户串数据 ### 4.2.3 新平台主链路当前仍未完成的点 截至本轮,以下问题仍然存在,且属于后续优先级较高的剩余项: 1. `ruleServiceImpl` / `ruleGroupSupport.py` 仍以全局规则集与分组关系为主,未形成真正的“规则集/版本资产级”租户边界 2. `evaluationPointGroupServiceImpl` 当前第一轮收口完全依赖 `entry_module -> leaudit_entry_module_tenants`;历史未绑定 `entry_module` 的脏数据,对非全局用户会直接不可见,仍需专项清洗 3. 文档列表/详情虽然已开始 tenant-first,但部分链路仍保留 `region` 兼容消费,需要继续审计调用点是否会把展示值误当边界键 4. 首页入口、上传页、文档列表页前端 scope 仍有 `sessionStorage + documentTypeIds + selectedModuleId` 主导的旧思路,尚未做到“显式 tenant scope 全链路透传” 5. 旧兼容评查点链路与新平台主链路之间的权限/租户语义还没有彻底拆开 6. 规则域多租户仍未整体完成,数据库脚本已准备但尚未在新库执行,当前只完成“方案 A 定案 + 第一轮运行链路 + 只读侧最小落地” 7. `T11-R1/R4` 已开始首轮落地: - 已新增规则域迁移 SQL: - [schema_rule_domain_tenant_phase1.sql](/home/wren-dev/Porject/leaudit-platform/scripts/创建sql/schema_rule_domain_tenant_phase1.sql) - [precheck_rule_domain_tenant_phase1.sql](/home/wren-dev/Porject/leaudit-platform/scripts/创建sql/precheck_rule_domain_tenant_phase1.sql) - [verify_rule_domain_tenant_phase1.sql](/home/wren-dev/Porject/leaudit-platform/scripts/创建sql/verify_rule_domain_tenant_phase1.sql) - `auditServiceImpl` 已接入 `TENANT -> PROVINCIAL -> PUBLIC` 的最小运行时选择逻辑 - `storage_adapter` 已支持结果/错误/指标写入租户快照字段的兼容模式 - `ruleServiceImpl / ruleConfigServiceImpl` 已完成第一轮只读侧租户作用域接入: - `ListSets / GetVersions / GetContent` 已支持按当前用户 `tenant_code` 解析有效规则集 - `ruleConfig` 的 `ListPacks / ListPackSummaries / GetPack` 已支持按当前用户命中有效绑定 - 规则配置摘要缓存已按用户维度隔离,避免串租户 - `ruleServiceImpl` 已完成第一轮写侧收口: - `CreateVersion` 已接入当前用户租户上下文,不再默认全局命中 `rule_type -> rule_set` - `Publish / Rollback` 已增加“当前租户可写规则集”校验,避免跨租户切换生效链 - 当前仍未进入规则派生复制完整闭环、业务组绑定写侧租户化、前端“来源态展示”的阶段 ### 4.2.1 评查点模块状态纠偏 这里需要单独说明,避免后续继续按错方向推进: 1. 当前仓库里确实还保留旧评查点链路 - `EvaluationPointController` - `EvaluationPointServiceImpl` - 前端 `rules/list`、`rules/new` - 后端仍连老库 `docauditai.evaluation_points` 2. 但新平台真实主链路已经不是这套 - 前端 `rule-groups` 页 - 后端 `evaluationPointGroupServiceImpl` - `leaudit_evaluation_point_groups` - `leaudit_rule_group_bindings` - `leaudit_rule_sets` - `leaudit_rule_versions` - `leaudit_documents.group_id` 3. 因此前面 `T5 评查点` 的第一轮改动,只能定义为: - “旧兼容评查点链路的 tenant-first 收口” - 不能定义为“新平台评查点主链路改造完成” 当前正确判断应该是: - `T5-legacy`:旧评查点兼容链路已做首轮 tenant-first 收口 - `T5-main`:新平台评查组/规则集主链路的租户边界、权限边界、数据范围边界,还需要重新单列分析和排期 当前这部分已经不再是“待分析”状态,而是: - 已完成单列方案定案 - 已形成专项实施计划 - 下一步应直接按 [规则域多租户方案A实施计划.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/规则域多租户方案A实施计划.md) 执行 ## 4.4 最近一次真实联调结论 本轮已用真实接口和真实前端链路验证通过: 1. `000 / admin06111` 可登录后端和前端 2. `PUT /api/v3/rbac/users/5/tenant` 可成功更新用户租户 3. `/api/auth/me` 已能返回正确 `tenant_code=MZ` 4. 后端 `/api/home/entry-modules` 对 `000` 实际返回 5 个入口模块 5. 前端此前“首页无入口”的根因不是后端过滤,而是首页兼容层只认 `route_path` 6. 修复前端兼容层后,`/api/auth/session-data` 已真实返回 `entryModules=5` 因此当前关于“000 用户首页没入口”这一问题,已经不是待分析状态,而是已修复并已验证状态。 ## 4.3 当前还不能说“已完成”的部分 虽然代码有落地,但整体仍不能算改造完成,原因是: 1. 统一权限决策模型还没成为全项目公共底座 2. `Document/Govdoc/UsageStats/RAG/RBAC` 还没全量切到统一执行器 3. 角色硬编码还存在于多个 controller/service/前端 guard 4. 现在很多地方是“兼容层 + fallback”,不是最终收口态 ## 4.4 高风险第一批最新进展 当前已正式开始按“高风险优先”执行,不再停留在方案阶段。 本轮已新增并推进: 1. [中高低风险修复优化计划.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/中高低风险修复优化计划.md) 2. [高风险数据库迁移清单与执行顺序.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/高风险数据库迁移清单与执行顺序.md) 3. [schema_tenant_code_high_risk_phase1.sql](/home/wren-dev/Porject/leaudit-platform/scripts/创建sql/schema_tenant_code_high_risk_phase1.sql) 其中已经实际落地的第一批代码变更包括: 1. 合同模板服务已从“接口表面支持 `tenant_code`、实际按 `region` 查”推进到“写入真实 `tenant_code/tenant_name`,查询优先 `tenant_code`,旧数据按 `region` 兼容回退” 2. 合同模板上传去重已从 `region + template_code` 收口为“优先 `tenant_code + template_code`,旧数据兼容 `region`” 3. 合同模板列表、详情返回已不再伪造空 `tenant_code` 4. 高风险 SQL 迁移脚本已从不安全的多匹配回填写法,修正为“按主键逐表稳定回填”的确定性写法 5. 评查点模块已补专用数据库草案: - [schema_evaluation_points_tenant_cleanup.sql](/home/wren-dev/Porject/leaudit-platform/scripts/创建sql/schema_evaluation_points_tenant_cleanup.sql) 6. 评查点模块已补专用收尾文档: - [评查点模块收尾清单.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/评查点模块收尾清单.md) 7. 评查点模块已补执行前预检与执行说明: - [precheck_evaluation_points_tenant_cleanup.sql](/home/wren-dev/Porject/leaudit-platform/scripts/创建sql/precheck_evaluation_points_tenant_cleanup.sql) - [评查点数据库执行说明与验证SQL.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/评查点数据库执行说明与验证SQL.md) 8. 评查点模块已补预检结果判读模板: - [评查点预检结果判读模板.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/评查点预检结果判读模板.md) 这意味着: - `T6 合同模板模块` 已完成第一轮高风险 tenant-first 收口 - `schema_tenant_code_high_risk_phase1.sql` 已具备进入数据库执行评审的基础 - `T5 旧评查点兼容链路` 已进入“代码首轮收口完成,待决定是否继续兼容 / 迁移 / 只读化”的阶段 - `T5 新平台评查组主链路` 不能再按“给 `evaluation_points` 补字段”推进,需改按新模型重新拆租户边界 - 下一步应继续推进 `RBAC 管理域 scope 化` 与剩余业务派生查询的统一执行器接入 --- ## 5. 按实施排期对照当前状态 以 [权限改造实施任务拆解与排期.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限改造实施任务拆解与排期.md) 为基线,当前大致进度如下。 ## 5.1 P1 能力层建设 状态:`未完成` 判断依据: 1. 文档里定义了 `ScopeContext / PermissionGrant / PermissionDecision / ScopeClause` 2. 但当前代码里还没有形成稳定、统一、被各模块复用的完整执行器主链 3. 现有改动以租户兼容和入口模块租户过滤为主,不是统一权限执行器成型 结论: - `P1` 仍处于“设计已完成,工程底座未完整落地” ## 5.2 P2 RAG 双轨治理 状态:`进行中` 判断依据: 1. 当前已实际落地 `rag_dataset / rag_chat_app` 的 `tenant_code` 字段兼容补齐与索引补齐 2. 数据集后台创建、更新、删除、列表、详情已经改为 `tenant_code` 优先,`area` 退为兼容展示/回退 3. 数据集可见性与聊天应用可见性已开始按 `tenant_code + PUBLIC/PROVINCIAL + public dataset` 收口 4. 前端 `/api/v3/dify/area-datasets*` 代理链路已改为 `tenant_code` 优先,知识库配置页已接入真实租户选项源,不再只靠已有知识库反推地区列表 5. service 内部大部分显式 `provincial_admin/admin/super_admin` 白名单已移除,但统一 `permission + decision + policy` 公共执行器仍未彻底接入 结论: - `P2` 已从“仅触达代码”进入“后端主链已收口一轮、前端管理链路已改 tenant_code 优先、首轮黑盒已完成”的阶段 - 但当前黑盒也明确暴露出一个现实:`RAG` 管理接口在现有权限种子下仍主要由全局管理员持有 - 剩余重点在于: 1. 更深层文档/分段/检索派生接口的统一策略收口 2. 会话写链路与消息链路补测 3. 前端页面彻底去 `area` 命名心智 4. 统一执行器正式接入 `RagPolicy` ## 5.3 P3 文档、公文、统计接入 状态:`部分完成` 判断依据: 1. 这些文件目前有修改痕迹: - `documentServiceImpl.py` - `govdocServiceImpl.py` - `usageStatsServiceImpl.py` 2. 其中 `usageStatsServiceImpl.py` 已完成一轮真实租户收口: - 登录审计补 `tenant_code_snapshot / tenant_name_snapshot` - 用户、文档、审计聚合查询改为 `tenant_code` 优先 - `GetUsers/GetAreas/GetDetails` 的跨租户统计串数问题已修正 3. `Document/Govdoc` 已完成第一轮高风险 tenant-first 收口,但尚未全部统一接入一套执行器 4. 当前更需要防范“半改状态”,因为最容易出现范围判断不一致 结论: - `P3` 不能整体宣称完成 - 但 `T7 使用统计` 可以视为本轮已完成 - `Document` 主链路已从“第一轮代码收口”进入“发布级黑盒已验证”的阶段 - `Govdoc/合同模板` 仍未进入同等强度的黑盒验收 - `Document/Govdoc` 后续重点转向统一执行器接入、剩余派生查询复核与验收 ## 5.4 P4 RBAC、合同模板、首页接入 状态:`部分进行中` 判断依据: 1. 首页相关租户读取逻辑已开始落地,且前端首页兼容层问题已修复 2. `rbacAdminServiceImpl.py`、`rbacAdminController.py` 已新增用户租户设置链路并完成联调 3. `RBAC` 组织树、目标用户角色分配/查询已完成一轮 tenant-first 收口 4. `contractTemplateServiceImpl.py` 第一轮高风险已完成,但还没接入统一策略闭环 5. 还没形成“统一策略 + 统一范围判定”的闭环 结论: - `P4` 中的“RBAC 首轮租户设置能力”“RBAC 首轮 scope 收口”和“首页入口可见性修复”已落地 - `P4` 中的“合同模板统一策略接入”和“RBAC policy 化”仍需继续推进 ## 5.5 P5 前端去角色化与验收收口 状态:`基本未完成` 判断依据: 1. 前端目录有租户 API 接入痕迹 2. 但没有证据表明菜单、按钮、guard 已系统改成按权限/能力快照 3. 验收矩阵文档虽已写完,自动化和完整联调未见闭环 --- ## 6. 当前最真实的完成度分层 如果按“真实可用进度”划分,当前可以这样看: ## 6.1 已完成 1. 权限与租户改造文档体系 2. 租户主数据基础表与入口模块租户关系表建表脚本 3. 目标库 schema 执行与基础数据初始化 4. `sso_users.tenant_code` 字段补齐与历史回填 5. `RBAC` 用户租户设置接口与前端弹窗联调 6. 首页入口前端标准化兼容修复 ## 6.2 已落地但属于第一轮兼容 1. 登录/当前用户租户解析 2. 租户解析器与旧字段兼容 3. 租户选项服务 fallback 4. 首页入口模块读链路租户过滤 5. 后台入口模块读写链路租户关系表兼容 6. 首页前端会话聚合链路兼容 `targetPath/routePath` 7. 入口模块管理端消费层已完成 tenants 化,首页链路保留 `areas` 仅作兼容展示 8. 首页入口主判断链路已改为 `tenants` 优先,`areas` 已退为兼容展示 ## 6.3 正在改但还不能验收 1. RAG 2. 文档的派生链路 3. 公文 4. RBAC 管理域全量 scope 化 5. 合同模板 6. 交叉评查任务与文档关系链统一策略接入 补充说明: 1. `统计` 已从“正在改”转为“本轮后端收口已完成,待后续统一执行器接入时再做第二轮整合” 2. `RAG` 当前属于“后端主链 + 前端管理链路第一轮完成,且首轮黑盒验收已完成;但还未做最终权限模型收口” 3. `文档/公文` 当前属于“文档主链路黑盒已通过;公文与更多派生链路尚未完成统一执行器接入与全链路回归” 4. `RBAC` 当前属于“用户租户设置 + 用户列表/组织树/角色分配第一轮 tenant-first 已完成;但 policy 化和统一执行器未完成” 5. `CrossReview` 当前属于“任务建单入口高风险边界已收口且首轮黑盒已验证;但任务详情、关系列表、后续动作链路尚未统一 policy” ## 6.4 仍未系统展开 1. 全局统一权限执行器正式接入 2. 全模块去角色硬编码 3. 前端去角色化 4. 多业务表租户字段标准化 5. 交叉评查/评查点等剩余 tenant-name 边界残留收口 6. 回归用例逐条落测 ## 6.5 当前黑盒验收基线 截至 2026-05-21,发布级黑盒验收基线已经扩展为 `16 passed`。 这 16 条通过目前表达的是: 1. `G1-G3` 门禁链路已经稳定 2. `G4` 文档跨租户读写边界已被可重复执行测试固定 3. `G5` RAG 当前真实权限模型已被固定 4. `G6` 规则集/评查组只读矩阵与交叉评查建单边界已被固定 同时也要明确: 1. 这不代表所有设计稿都已实现 2. 这不代表规则资产已经完全租户化 3. 这不代表 `RAG` 已经完全去角色化 4. 这不代表交叉评查后续深链路已经验收完成 --- ## 7. 当前主要风险 ## 7.1 文档口径和代码口径并存 风险点: 旧导航还在强调“只认 `area`、单地区隔离”,会误导后续开发继续写旧逻辑。 ## 7.2 代码处于半改状态 风险点: 有些链路已经开始认 `tenant_code`,有些链路仍认 `area/region/default`,很容易出现: 1. 查得到列表,查不到详情 2. 登录后有租户,实际查询仍按旧地区字段 3. 新入口模块配置了租户,但其他下游仍用旧 JSON 或旧地区名 ## 7.3 统一执行器未成型前,范围逻辑容易继续分叉 风险点: 如果继续一口气在各模块手写过滤,很可能又会堆出第二套、第三套范围判断。 ## 7.4 租户接口虽然有代码,但还要看联通性 当前已存在 [tenantController.py](/home/wren-dev/Porject/leaudit-platform/fastapi_modules/fastapi_leaudit/controllers/tenantController.py),控制器扫描注册机制也支持自动注册。 但仍需联调确认: 1. `/api/v3/tenants` 2. `/api/v3/tenants/options` 3. `/api/v3/tenants/{tenantCode}` 是否都已真实可用并满足前端需要。 --- ## 8. 下一步建议顺序 基于当前状态,后续不建议再先写大而全新方案,而应按下面顺序推进: 1. 进入 `T9` 租户主数据维护写能力 - 补租户新增、编辑、启停、别名、feature flag 管理接口 2. 再做“剩余高风险残留扫描” - 重点扫 `region/area/default/省级/省局` 是否仍会导致落错数据或查错范围 3. 然后按主数据风险顺序推进业务模块 - 交叉评查后续关系链 - 评查点配置 - RBAC policy 化 - 文档/公文剩余派生查询与统一执行器接入 - RAG 二轮收口 4. 最后再进入统一执行器全量收口和前端去角色化 --- ## 9. 建议你现在把它理解成什么阶段 最准确的描述是: “权限与租户改造已经完成方案设计和第一批数据库/兼容层落地,当前处于从兼容接入向统一执行器正式收口过渡的中间阶段。” 补充一句更贴近当前真实状态的话: “入口模块首页可见性和 RBAC 用户租户维护已经打通,但业务主数据域仍大量停留在 `area/region` 兼容阶段。” 不是: - 还停留在纸面方案 也不是: - 已经完成全量权限租户化改造 --- ## 10. 当前阅读建议 如果你现在只想判断“接下来该盯哪里”,建议直接看这几份: 1. [权限与租户改造当前进度总览.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限与租户改造当前进度总览.md) 2. [权限改造实施任务拆解与排期.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限改造实施任务拆解与排期.md) 3. [地区租户化与自定义租户扩展改造方案.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/地区租户化与自定义租户扩展改造方案.md) 4. [入口模块租户配置表迁移方案.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/入口模块租户配置表迁移方案.md) 5. [模块级开发任务单.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/模块级开发任务单.md) 如果你要判断“某个模块现在到底能不能继续开发”,再回头对照: 1. [权限接口矩阵与数据边界清单.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/权限接口矩阵与数据边界清单.md) 2. [角色去硬编码迁移清单.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/角色去硬编码迁移清单.md) 3. [模块级真实落地清单与下一步动作.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/模块级真实落地清单与下一步动作.md)