本卡屬 FR-132（母卡 CM-2510），A.5 存取管理前端第 4 張，取代作廢的 CM-2539。依賴：T-5.1、T-3.8（檢查存取 API）；與 T-5.3 動同一頁，排在 T-5.3 之後。建議 model：opus。

這張卡做什麼（白話）

決策者定：檢查存取不另開一頁，是指派頁頂部的一個搜尋框。輸入一個人之後，下方表格不再列指派，而是切成「這個人每一項權限來自哪個角色、什麼時候到期」；旁邊一張卡顯示他登入後會看到的選單。清掉搜尋就回到原本的指派表。管理員用它回答「為什麼他看得到／看不到這個功能」。

首腦核對過的事實

• 端點：GET /api/1.0/users/<uid>/effective-access（~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/api/routing.py:127、api/routes/role_assignment_route.py:70-81）；查本人放行，查他人要 iam.user.read，擋下回 403（不是 401，FE 收 401 會登出）。
• 回應（api/serializers/role_assignment.py:62-95）：user_uid、login_name、nickname、tenant_id、bypass{super_admin, is_admin, platform_admin}、capabilities[]——每項 name、display_name、module、resource、verb、sources[]；每個來源 role_uid、role_name、pattern、scope、org_unit_*、starts_at、ends_at。同一項權限可能來自多個角色（多個 source）。
• 回應不含可見選單——要用 T-5.1 的端點，把 capabilities[].name 丟進 capability_names 算，與側欄同一條判定。

在哪裡

docs/features/FR-132-2610-access-management/mockup/roles-and-assignments-v3.html          定稿：指派頁頂部「檢查存取」框
T-5.3 做出的指派頁 view（路徑看 CM-2538 回寫）       在這頁加搜尋與結果視圖
~/Projects/Billows/Audit-Manager/compliance-manager-fe/src/config/api/api.js                          加 USER_EFFECTIVE_ACCESS 常數

怎麼做

• 搜尋框：AutoComplete（或 IconField＋Dropdown filter），資料走 /users/menu，選到人後呼叫 effective-access。說明句「列出這個人每一項權限來自哪個角色、何時到期，以及登入後的可見選單」。結果狀態用 query ?check=<uid> 保存，重新整理或分享網址能還原。
• 結果視圖（同一個位置換內容，建議拆成子元件 EffectiveAccessView.vue，不要塞進指派頁主檔）：左邊 DataTable，一項權限一行：權限名（顯示名走 i18n）、所屬畫面（用 T-5.1 的歸頁純函式）、來源角色（多個時逐一列出）、到期（取該來源的 ends_at，空＝永久；多來源時顯示最晚的那個並在 tooltip 列全部）；可依畫面分組（rowGroupMode="subheader"）。上方摘要：「共 N 項權限，來自 M 個角色」。右邊 T-5.1 VisibleMenuPreview（readonly，不出現「加入」）。
• 豁免標示：bypass.super_admin／platform_admin／is_admin 任一為真時，摘要上方顯示一條 Message（info）說明「此帳號為 <類型>，部分功能不受角色限制」，三種各一句白話文案。
• 不顯示 pattern、scope、部門欄（介面用語規範＋D12 不做）；規則字串只在 tooltip 的「來源規則」裡出現也不要——一律白話。
• 「清除」按鈕回到指派表；查無權限時用 EmptyState 元件（src/components/grc/）。

驗收條件

• 查一個同時有稽核員與唯讀兩個指派的帳號：重疊的權限（例 grc.project.read）來源列兩個角色；只在稽核員的列一個。
• 把其中一筆指派的到期改成昨天，再查一次：那個角色貢獻的權限消失（與判定同源）。
• 右邊可見選單與該帳號實際登入後側欄一致。

手測