ow

uniapp/youjiala/src/md/permission.md

@@ -301,19 +301,18 @@ Get-ChildItem 'dist\build\mp-weixin' -Recurse -File -Include *.js | Select-Strin
 
 ## 8. 已知缺口
 
-- **入口可见性这一层还没做（菜单/首页九宫格）**。权限的可见性分两层，本层只实现了第二层：
+- **入口可见性（菜单/首页九宫格）已实现**——这一层不再是缺口。权限可见性分两层，两层现在都落地了：
 
   | 层 | 管什么 | 数据源 | 现状 |
   | --- | --- | --- | --- |
-  | ① 入口可见性 | 首页列不列得出这个入口 | `POST /SecurityUser/FindMenuByUsername`（后端按用户权限过滤） | **未实现**：`dashboard.vue` 是空白占位页 |
-  | ② 页面可进入性 | 手输地址/深链跳过去能不能进 | `PAGE_PERMISSIONS` + `canVisitPage()` | 判定层就绪，登记表为空 |
+  | ① 入口可见性 | 首页列不列得出这个入口 | `POST /SecurityUser/FindMenuByUsername`（后端按用户权限过滤） | **已实现**：`dashboard.vue` + `useAdminMenu` + `admin/menu-map.ts` 白名单，详见 `src/md/admin-pages.md` §5 |
+  | ② 页面可进入性 | 手输地址/深链跳过去能不能进 | `PAGE_PERMISSIONS` + `canVisitPage()` | 判定层就绪，security 域三页已登记（见下条） |
 
-  旧 WebVue 主要靠 ①：看不见的入口自然不会点，②只是补"手敲 URL"的漏洞。①的后端链路（`SecurityUserService.cs:232-248`）是 `用户名 -> security_user_actor -> security_actor_group -> security_group_permission -> security_permission_function_map -> security_function`，只返回本人被授权的功能，`UserId` 为空直接返回 null。
-  两个接口都已随 service 层移植进来且**零调用者**：`securityUserService.FindMenuByUsername()`（返回 `SecurityFunctionResultData`，含 `SecurityFunctionDisplayData[]` 的 `FunctionLocalName/FunctionEngName/Icon/Orderby/PageUrl/PermissionName` 与 `SecurityFunctionMaps` 层级，正是旧 `layout/index.vue` 的 `initMenu()` 消费的形态）和 `securityFunctionService.FindMenus()`（`[AllowAnonymous]`、**不区分用户的全量表**，旧项目只用来全量注册路由，别拿它做过滤）。
-  所以这一条缺口的真实含义是：等做首页入口时调 `FindMenuByUsername` 渲染，并用返回的 `PermissionName` 顺手校对 `PAGE_PERMISSIONS` 的登记；`stores/tabbar.ts` 的默认列表目前也是空的，等同一个数据源。
+  ①的后端链路（`SecurityUserService.cs:232-248`）是 `用户名 -> security_user_actor -> security_actor_group -> security_group_permission -> security_permission_function_map -> security_function`，只返回本人被授权的功能，`UserId` 为空直接返回 null。`securityUserService.FindMenuByUsername()` 返回 `SecurityFunctionResultData`（含 `SecurityFunctionDisplayData[]` 的 `FunctionLocalName/FunctionEngName/Icon/Orderby/PermissionName`），正是旧 `layout/index.vue` 的 `initMenu()` 消费的形态；`useAdminMenu` 拿它渲染，再过 `menu-map` 白名单与 `canVisitPage` 两道本地过滤。`securityFunctionService.FindMenus()`（`[AllowAnonymous]`、**不区分用户的全量表**）仍只用来全量核对 `permission_name`，别拿它做菜单兜底。
+  遗留：`stores/tabbar.ts` 的默认列表仍是空的（tabbar 与本批九宫格是两套东西，暂未统一数据源）。
 - **数据级（dependent）判定尚无真实页面在用**：旧项目所有调用点都是单参形式，口子为 `Submit`/`Approval` 与将来的目录级授权保留。
-- **`PAGE_PERMISSIONS` 目前是空表**：现在只有 login / dashboard / 三个错误页，除 dashboard 有意不绑（§3.1）之外，其余页面还没迁进来。空表意味着路由级 403 实际上还没被任何页面触发，只能靠请求层的 HTTP 403。
-- **403 页的"返回首页"在首页本身被拦时会原地弹回一次**：`page403.vue` 的返回按钮走 `reLaunch(pageUrl("dashboard"))`，而 reLaunch 同样过 `nav-guard`；若 dashboard 恰好被绑了拿不到的权限，这次跳转会被再拦一次、弹回 403（实测是一次性弹回，不是死循环，因为 403 页自身在 `AUTH_FREE_PAGES` 里）。等真有页面登记权限时，这里应该改成"按 `PAGE_PERMISSIONS` 找第一个可达页"或直接隐藏该按钮。
+- **`PAGE_PERMISSIONS` 登记仍很稀疏**：security 域已登记 `userEnquiry=UserEnquiry`、`userOperation=UserOperation`、`actorEnquiry=SecurityActor` 三条（命名不统一、别"顺手归一"的坑见 `src/md/admin-pages.md` §4）；其余旧 WebVue 域（Group/Function/Dms/Publish…）尚未迁进来。已登记页面会真正触发路由级 403，未登记页面仍只靠请求层 HTTP 403 兜底。
+- **403 页的"返回首页"在首页本身被拦时会原地弹回一次**：`page403.vue` 的返回按钮走 `reLaunch(pageUrl("dashboard"))`，而 reLaunch 同样过 `nav-guard`；若 dashboard 恰好被绑了拿不到的权限，这次跳转会被再拦一次、弹回 403（实测是一次性弹回，不是死循环，因为 403 页自身在 `AUTH_FREE_PAGES` 里）。dashboard 目前有意不绑（§3.1），所以这条还触发不到；等哪天给 dashboard 也登记了权限，这里就该改成"按 `PAGE_PERMISSIONS` 找第一个可达页"或直接隐藏该按钮。
 - **前端判定滞后于后端**：后端每次请求实时查库，前端读登录时的快照。管理员改了授权后，用户重新登录前看到的仍是旧按钮状态（可能点了才 403）。这是"权限随令牌下发"这个既有模型的代价，不是本层引入的。
 - **`SecurityUserPermissionInfo.UserGroups` 未参与判定**：后端也不用它做短路（只用于 join 出授权行），前端同样只用 `Permissions` / `PermissionDependents`。
 - **孤儿授权数据**：种子库里 `security_group_permission` 有 `abc` 组以及 `acc`/`PhotoPublish`/`AudioPublish`/`VideoPublish` 等权限名，而 `security_group` / `security_permission` 里查不到它们。判定层对此的表现是"多几行永远匹配不上的索引项"，无害；但登记权限名时**不能以授权表的并集为准**，要以 `security_permission` 为准，否则会照抄到这些历史残留。