本卡屬 FR-132（母卡 CM-2510），A.3 判定層第 6 張。依賴：T-2.3、T-3.5。建議 model：fable。

這張卡做什麼（白話）

資料庫今天用 RLS（Row-Level Security，資料庫列層級隔離）只擋別租戶的資料。這張卡讓「開了部門隔離的租戶」裡，挑選的業務表只回指派範圍內部門的資料。開關預設關，關著時所有查詢結果必須與今天完全相同。RLS 擋掉的資料不會報錯、只是少幾筆，所以背景流程的系統放行旗標一定要尊重，否則排程工作會靜默讀不到資料。

在哪裡

~/Projects/Jedicogy/module/jedi-python-package/jedi-common/jedi_common/session/database/db.py:205-209      session 變數注入（app.allowed_tenant_paths 的做法）
~/Projects/Jedicogy/module/jedi-python-package/jedi-iam/jedi_iam/middleware/context.py:119-129      app.allowed_org_paths（所屬部門）注入
~/Projects/Billows/Audit-Manager/compliance-manager-be/app/flow_engine/service/workflow_execution_service.py:581,706      app.can_read_all_orgs 背景流程放行旗標（此檔 1,363 行已超標，不要往裡加）
~/Projects/Billows/Audit-Manager/compliance-manager-be/scripts/sql/<日期>-fr132-org-unit-isolation-policies.sql      policy migration
docs/features/FR-132-2610-access-management/inventory/a1-d12-tables.md      挑選表清單（T-1.6）

怎麼做

• 新 session 變數：app.allowed_org_unit_paths＝有效部門指派的部門 path 清單；有有效租戶指派、super_admin 或系統管理員時設為全部門可見標記（定一個明確值，例 *）。app.org_unit_isolation＝本租戶開關值，開 session 時讀出（不在每列查設定表）。
• 🔴 app.allowed_org_unit_paths（指派部門）與既有 app.allowed_org_paths（所屬部門，只給 INSERT 檢查用）名字相近意思不同——兩個注入處各寫一行註解寫明差別。既有 INSERT policy 不動。
• policy 形狀（挑選表的 SELECT／UPDATE／DELETE）：既有租戶條件 AND（app.org_unit_isolation 非 true OR app.can_read_all_orgs 為真 OR 該列 org_unit_id IS NULL OR 該列部門 path 落在 app.allowed_org_unit_paths 任一前綴之下 OR 標記為全部門可見）。部門 path 用 join org_units 或子查詢取，注意效能（(tenant_id, path) 已有索引）。先 \d+ 每張表看既有 policy 名與寫法，在其上擴充。
• 變數未設定時的預設：current_setting(..., true) 為空時視同開關關——舊程式路徑、背景工作不能因此看不到資料。
• jedi-common 與 jedi-iam 都會改（path dependency 兩支）。
• migration 只套 DEV。

要寫測試

• 開關關：選幾張挑選表在 cm_app 身分下查，結果與套用前相同（比對筆數）。
• 開關開：只有部門指派的帳號只看得到子樹內＋org_unit_id 為空的列。
• 開關開＋can_read_all_orgs：看得到全部。
• 突變：拿掉 can_read_all_orgs 條件，背景流程測試紅。

驗收條件

• 開關關時所有查詢結果與改前相同；開時只看得到指派範圍內部門資料；背景流程在開隔離租戶仍讀得到。

手測