FR-132 · 需求索引 · 本頁由 build 掃資料夾生成

FR-132 存取管理

狀態：設計定案（D1–D12，2026-10-06），母案待開卡文件 5 份

§1

🔴 先看哪一份

你想知道	看這份	這份的性質
決定了什麼、怎麼拆、每張卡驗收什麼	設計 design.md	設計決策，定稿後凍結
為什麼這樣決定、現況細節與流程圖	討論稿 discussion.md	討論稿，已定案
原始盤點證據（BE＋jedi-iam、專案角色與流程、前端）	inventory/	一次性證據，不再更新

§2

結論

公司層權限照 Azure「誰 × 角色 × 範圍 × 時效」補完：能力點改三段式名字（grc.project.read），角色可以寫萬用字元（grc.*.*、*.*.read），角色可匯出匯入 JSON。
部門範圍套在資料上：掛在部門 X 的指派，只對 X 子樹內的資料有效；使用者本人隸屬哪個部門不參與判定。部門資料隔離做成租戶開關、預設關，關著時一切與今天相同。
33 支只驗登入的 API 補上能力點守門，先只記錄一版、下一版才真擋；這是客戶可感的行為變更，兩版 release note 都要寫。
前端改成一個「存取管理」模組四頁：角色、指派、檢查存取、使用者，另加部門隔離設定頁。
專案內成員角色（manager／reviewer／auditor／viewer）的合併不在本案，另開 FR-B，時間由決策者與 PM 定。

§3

📊 總進度

子需求	做什麼	卡數	狀態
A.1	盤點與規則：每支 API 對到新能力點、定模組與能力點樹	6	⬜ 待開卡
A.2	資料地基：改名、萬用字元角色、部門路徑、開關欄、升級排練	6	⬜
A.3	判定層：展開＋快取、部門範圍、同源修資安漏洞、隔離機制、新 API	8	⬜
A.4	守門補齊：只記錄 → 真擋	5	⬜
A.5	存取管理前端	6	⬜

§4

需求討論紀錄

2026-10-06：決策者拍板模型、三段式命名、萬用字元、公司層／專案層兩層分工、拆兩個 FR；D1–D12 定案。
2026-10-06：部門範圍定為「套在資料上」，使用者所屬部門不參與判定；開關關著時部門指派等同全租戶有效，升級不改任何人的權限。
2026-10-06：is_admin 角色轉換規則定案——租戶內能力點等於全集者轉內建系統管理員 *.*.*（多個取最早建），其餘保留旗標、能力點原樣轉、不升級。

§5

文件

以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。

需求與討論

文件	類型	標題	最後更新
discussion ／ md	需求討論稿	存取管理：補完 RBAC	2026-10-06

設計

文件	類型	標題	最後更新
design ／ md	設計	存取管理：設計定案	2026-10-06

inventory/（3 份）

證據與盤點

文件	類型	標題	最後更新
01-authz-capabilities ／ md	文件	盤點 ①：授權守門與能力點現況（BE + jedi-iam）	2026-10-06
02-project-roles-and-flow ／ md	文件	盤點 ②：專案成員角色制與流程綁定現況	2026-10-06
03-frontend ／ md	文件	盤點 ③：FE 角色／使用者／專案成員頁現況	2026-10-06

其他檔案：notion-cards-spec.json、notion-cards.json

§6

關聯

相關需求：