AiDOPWarehouse/server/Admin.NET.Web.Entry/UpdateScripts/1.0.436.sql

-- ============================================================================
-- 1.0.436：回收 UAT 租户 838257186181189 的 UAT_FUNCTION_USER 对平台机构管理的权限。
--
-- 背景（P1-2 已完成）：
--   S0 前端的组织下拉数据源已由平台 /api/sysOrg/list 改为 S0 自有只读端点
--   /api/s0/common/orgs（AdoS0OrgsController，内部复用 SysOrgService.GetList，
--   租户与数据权限口径完全一致，路由未登记为按钮权限故无需授权）。
--   静态扫描确认：Web/src/views/aidop/s0 下已 0 处引用 apiSysOrgListGet / /api/sysOrg/list；
--   runtime 实测 nbr-control / contract-review-cycle / sampling-scheme / sop-document
--   四类页面均只发 /api/s0/common/orgs，无 /api/sysOrg/list。
--   → 该角色不再需要平台按钮权限 sysOrg:list。
--
-- 为什么同时撤「机构管理」菜单（1300200030101）：
--   1.0.431 补 sysOrg:list 后，菜单祖先补全使「系统管理 / 机构管理」出现在该角色侧边栏；
--   其后管理员通过「角色管理 → 授权菜单」重存该角色时把它**直接勾选**了
--   （实测：该角色 SysRoleMenu 由 290 条变为 285 条且 Id 为一整段新雪花块，
--     1.0.431 写入的 Id=101853272909807688 已被 GrantRoleMenu 全量替换覆盖；
--     对照租户 B 的同名角色并未持有该菜单，可见是本租户的连带结果）。
--   若只撤按钮不撤菜单，入口仍在侧边栏，点开 /system/org/index 会调用
--   /api/sysOrg/list 而拿到 403 —— 等于把最初的缺陷换一种形式留回去。
--   故两条绑定一并回收（经 owner 确认）。
--
-- 精确范围（只动这一个角色的这两条绑定）：
--   RoleId = 838258976469061（租户 838257186181189 的 UAT_FUNCTION_USER）
--   MenuId ∈ (1300200030201 sysOrg:list 按钮, 1300200030101 机构管理 菜单)
--
-- 明确不做：
--   - 不动 1.0.431 / 1.0.386 等历史脚本（历史不可改写，撤销以新脚本表达）
--   - 不动租户 797403760988229 / 797403760988230 及其它任何角色
--   - 不动 SysMenu、SysTenantMenu（菜单与租户可见性本身保持不变，
--     仅解除**这一个角色**的绑定；其它角色/租户仍可正常授权使用机构管理）
--   - 不放开也不回收 sysOrg:add / sysOrg:update / sysOrg:delete（该角色本就未持有）
--
-- 幂等：存在则删除，不存在则 0 行；重复执行无副作用。
--
-- ⚠️ 缓存：GetOwnBtnPermList 按 sys_user_button:<userId> 缓存 7 天，CacheType=Memory
--   为进程内缓存，SQL 不会使其失效。AutoVersionUpdate 在应用启动时执行本脚本，
--   该进程缓存本就为空 → 随发布重启天然生效；若在已运行实例上手工执行，
--   需用 POST /api/sysCache/deleteByPreKey (prefix=sys_user_button:) 清理。
-- ============================================================================

DELETE FROM `SysRoleMenu`
WHERE `RoleId` = 838258976469061
  AND `MenuId` IN (1300200030201, 1300200030101);