許可權

身份、崗位、許可權集、記錄訪問與欄位安全 —— 一頁講完整套訪問模型。

ObjectOS 借鑑企業軟體二十年來行之有效的分層訪問模型：身份 → 崗位 → 許可權集 → 記錄訪問 → 欄位安全。每一層回答一個不同的問題，你可以忽略用不到的層。（ObjectStack 13 將舊的角色與簡檔概念合併為崗位——參見崗位。）

一張圖說明模型

Authentication       Who is the caller?
        ↓
Identity             Which user/org/membership is active?
        ↓
Positions            Which job functions do they hold?
        ↓
Permission sets      What CAN they do — apps, objects, fields, system?
        ↓
Record access        WHICH records can they touch?
        ↓
Field security       For those records, which FIELDS are readable / writable?

每一層都由 security 外掛強制執行。簡單應用可以只使用許可權集（不用崗位、不用共享規則），等需求出現時再增補其餘層。

第 1 層 —— 身份

身份物件存在你的專案資料庫中。最重要的幾個：

物件	表示什麼
`sys_user`	一個能認證的人或服務賬號
`sys_org`	租戶/工作空間邊界（多租戶應用）
`sys_member`	使用者在某組織內的成員資格
`sys_business_unit`、`sys_team`	可選的組織結構，用於共享規則
`sys_invitation`	待接受的邀請
`sys_session`	已認證的活動會話
`sys_api_key`	繫結到使用者的長期程式設計憑據

在多租戶部署中：

使用者作用域限定到專案資料庫。
會話作用域限定到專案主機名。
行級檢查使用當前使用者所在組織和許可權。
控制面使用者不會自動成為業務使用者——必須通過平臺 SSO 或顯式預置進行對映。

你可以在執行時通過 Console（/_console/）建立/管理這些物件，也可以在 objectstack.config.ts 中為全新環境種入。

第 2 層 —— 崗位

崗位對職能建模（"銷售經理"、"支援坐席"）。崗位是扁平的——層級結構位於業務單元樹上，因此共享規則和報表表達的是"記錄所有者所在單元及下級單元"之類的關係。兩個預置的受眾錨點 everyone（所有已認證使用者）和 guest（匿名呼叫者）讓你無需自定義回退邏輯即可繫結基線許可權集。用崗位按職能分發許可權集；扁平團隊可以不建自定義崗位。

參見崗位。

第 3 層 —— 許可權集

許可權集是授予能力的主要方式。它們直接附加到使用者，或通過崗位附加。

它們授予什麼

型別	示例
應用訪問	開啟 CRM、開啟支援門戶
物件許可權	對某物件的記錄進行增/查/改/刪
欄位許可權	讀取或更新特定欄位
系統許可權	訪問 Console、執行報表、匯出資料、檢視審計日誌
整合許可權	使用 API Key、配置 Webhook、執行管理操作

物件許可權標誌

這些是 security 外掛實際檢查的標誌名稱：

標誌	含義
`allowRead`	讀取通過記錄訪問可見的記錄
`allowCreate`	建立新記錄
`allowEdit`	更新使用者可見的記錄
`allowDelete`	刪除使用者可見的記錄
`viewAllRecords`	讀取該物件每一條記錄，忽略記錄訪問規則
`modifyAllRecords`	更新/刪除每一條記錄；隱含 `viewAllRecords`

viewAllRecords 與 modifyAllRecords 是對該物件的租戶級超級使用者授權。僅在顯式的管理許可權集中使用，不要放進任何面向普通使用者的崗位。

參見 Permission Sets。

第 4 層 —— 記錄訪問

對於沒有 viewAllRecords 的使用者，他們能看到哪些行？

模型支援：

隱式所有權（使用者建立或擁有的行）
共享規則（宣告式 —— "團隊 A 能看到團隊 A 的記錄"）
顯式共享（sys_record_share 行——一次性共享，可授予使用者、崗位或"單元及下級單元"）
組織作用域（行的 org_id 與使用者所在組織匹配）

自 ObjectStack 13 起，帶有所有者欄位的自定義物件預設使用私有共享模型——需要開放時請顯式宣告 sharingModel。

參見 Record Access。

第 5 層 —— 欄位安全

即使使用者能看到記錄，單獨的欄位也可以是：

隱藏 —— 欄位被從 API 和 UI 響應中剝離。
只讀 —— 欄位返回，但寫入會被拒絕。

欄位安全是按物件 + 按許可權集設定的。典型用途：

把 sys_user 上的 salary 對 HR 之外的所有人隱藏。
把 external_account_id 對支援代表設為可讀但不可編輯。

它在與物件許可權相同的求值器中強制執行，因此在 REST、ObjectQL 和 Console 上統一生效。

從哪裡入手

如果你在構建 ……	使用
單團隊的內部工具	僅許可權集
多團隊、經理需要看報表的應用	業務單元 + 崗位 + 許可權集
多租戶 SaaS 形態的應用	組織作用域 + 許可權集
帶 PII 的合規應用	在上面疊加欄位安全
複雜的 CRM 類應用	完整棧

診斷與審計

解釋引擎（explain(principal, object, operation)）按順序報告每一層的判定結果——所需許可權、物件 CRUD、欄位安全、OWD 基線、共享、行級安全——並給出逐層歸因。Console 將其呈現為"該使用者為何能訪問？"面板。解釋其他使用者需要 manage_users 能力。
/_console/ 顯示任一使用者當前評估出的有效許可權。
審計日誌（sys_audit_log）記錄許可權敏感變更——授權、崗位分配、許可權集編輯。
被拒請求記錄失敗的具體規則（物件許可權 vs 記錄訪問 vs 欄位安全），便於支援人員快速回答"為什麼我看不到這個？"。

On this page