從3個方面，手把手教你做B端的權限設計

權限設計是 B 端系統設計中一個至關重要的環節。有關權限設計的內容浩如煙海，筆者根據平時的項目實踐經驗，總結出 B 端系統權限設計的以下幾點心得，共分為三大部分：

1. 權限設計的定義；
2. B 端系統權限設計的分類；
3. B 端系統權限設計的方法。

其中第三部分為本文的重點，詳細介紹了功能權限和數據權限的設計方法。關于權限設計的用戶管理、用戶組管理、角色管理、權限管理等內容，主要是列表頁、編輯頁、詳情頁等頁面流程以及增刪改查等操作，本文不再贅述。

更多相關干貨：

一、權限設計的定義

權限設計是指系統為解決某一具體的權限分配問題而進行的設計。

為什么需要分配權限呢？一般是出于職位職責和數據安全兩個方面的考慮。

例如，一個客服平臺的質檢系統需要管理員、質檢員、坐席等不同職位，不同職位擔任的職責均不相同，這就需要通過功能權限劃分進行管理。

同時，考慮到系統的數據安全性，不同賬號被允許查看的數據范圍也不相同。管理員可以查看并操作全量數據，而坐席只能查看個人數據，因此，需要設計數據權限。

二、B 端系統權限設計的分類

B 端系統權限主要分為兩類：功能權限和數據權限。

功能權限是指用戶登錄系統后可以操作哪些菜單、哪些頁面以及哪些頁面元素。例如，質檢員登錄 W 客服平臺的 AI 質檢系統后，可以在質檢詳情頁對 AI 質檢結果進行增刪改查，而坐席人員只能查看不能操作。因此，就頁面的功能權限而言，二者是不一樣的。

數據權限是指用戶登錄系統后可以查看的數據范圍，即能查看多少數據，什么類型的數據。例如，W 客服平臺的 AI 質檢系統的質檢記錄列表，管理員能查看所有坐席人員的質檢記錄，而坐席人員只能查看自己的質檢記錄。因此，二者的數據范圍不同。

我們在做權限設計時，一定要區分系統的功能權限和數據權限，不要糅合在一起。

三、B 端系統權限的設計方法

1. 如何設計 B 端的功能權限

RBAC 模型

RBAC 模型（RBAC，Role-Based Access Control）是指基于角色的訪問控制，該理論于 1995 年由計算機科學家 Ravi Sandhu 提出來的。主要描述了一套用戶、角色、權限的設計理論，已被業界廣泛使用。

RBAC 模型理論的核心思想是：在用戶與權限之間增加一個媒介，即角色。通過給每個用戶賦予一個或多個角色，再給每個角色分配相應的權限，從而將角色關聯的權限賦予給用戶。

為什么要引入“角色”這個概念呢？為了更好地說清楚 RBAC 模型的核心思想，我們來看個 B 端設計案例。W 客服部門做了一個 AI 質檢系統，起初由于業務量少，質檢系統只安排了 1 個質檢員小明，讓他負責審核 AI 質檢結果并確認質檢。管理員給小明創建了系統賬號，并直接綁定了質檢權限。

后來，隨著業務量的不斷增加和坐席團隊的日益壯大，W 客服部門已增至幾十個質檢員，每次有新增的質檢員，管理員都需要給其綁定相應的權限，后續有修改也無法進行批量操作，需要對每一個賬號操作一遍。這樣，管理員的重復性工作太多，工作效率大打折扣。

試想，如果設置一個角色，并把相關權限賦予該角色，那么在添加新賬號的時候，只需將該賬號綁定該角色，就能擁有該角色所具有的權限。如果需要調整權限，也無需操作每個賬號，只需修改該角色綁定的權限即可，所有賬號的權限跟著改變，這將極大地提高管理員的工作效率。

關于 RBAC 模型的核心思想，圖示如下：

關于 RBAC 模型，還有很多延展性理論。例如：根據模型的復雜度，又可分為 RBAC0、RBAC1、RBAC2、RBAC3。其中，RBAC0 是上面介紹的基礎理論。后面幾個涉及到角色繼承、角色約束、用戶組等概念，我們可根據自己業務的實際情況選擇合適的理論模型，在此不再贅述。

根據 RBAC 模型理論，我們怎么設計 B 端系統的功能權限呢？

①設計合理的角色。合理的角色設計是權限設計的前提。在此基礎上，只需要配置每個角色能查看哪些菜單，訪問哪些頁面，操作哪些頁面元素就行。

例如，通過業務分析，W 客服平臺的 AI 質檢系統的角色有：管理員、質檢員、坐席、游客。管理員負責系統配置和管理。質檢員負責對 AI 質檢結果進行檢查和確認。坐席可查看自己的質檢結果，提出復議。游客可登錄系統查看質檢模塊介紹。

②明確需要做權限控制的功能點，以權限表的形式羅列出來。

功能權限包括菜單權限、頁面權限和頁面元素權限。將需要做權限控制的功能點以菜單、頁面、頁面元素的層級羅列出來。如果菜單、頁面有多個層級，則將每個層級都羅列出來。以下表格是 W 客服平臺的 AI 質檢系統的智能質檢模塊需要做權限控制的功能點：

③列出角色，找到權限與角色之間的對應關系，完善權限表。我們再把 W 客服平臺的 AI 質檢系統的角色列在權限表后面，并勾選每個角色擁有的權限，完善角色與權限的對應關系，具體圖示如下：

從以上權限表，我們可以看出：

1. 在質檢記錄列表頁中，管理員和質檢員這兩個角色可以操作所有篩選條件，而坐席只能操作“時間段”、“客戶名稱”、“客戶手機號”、“狀態”4 個篩選條件。
2. 在質檢詳情頁中，質檢員可以操作“添加質檢類目”、“添加質檢項”、“刪除質檢類目”、“刪除質檢項”、“確認質檢”、“提交質檢評論”、“編輯質檢評論”、“刪除質檢評論”、“查看質檢評論”、“查看復議”11 個按鈕；管理員能操作“查看質檢評論”、“查看復議”2 個按鈕；坐席能操作“查看質檢評論”、“提出復議”、“編輯復議”、“刪除復議”、“查看復議”5 個按鈕。

以權限表的形式將各角色與功能權限一一對應呈現出來，清晰明了，不容易遺漏。

2. 如何設計 B 端系統的數據權限？

數據權限是建立在功能權限基礎之上的。沒有功能權限，就不會有數據權限。

例如，某個角色在 W 客服平臺的 AI 質檢系統中如果不能查看質檢記錄列表，自然也談不上能看到多少數據量的問題。

關于數據權限，一般包含兩種情況。

一種是無組織架構的數據權限。這類數據權限設計相對簡單。根據不同的業務情況，可以選擇直接在創建角色時選定相應的數據權限范圍，也可以將規則以文字描述的形式羅列在權限表后面。

例如，W 客服平臺的 AI 質檢系統各角色間不涉及上下級的層級架構，因此，只需在功能權限表后新加一欄數據權限，將各角色的數據權限規則描述出來即可，具體圖示如下：

第二種是有組織架構的數據權限。

組織架構是指，一個組織整體的結構。企業的組織架構是企業的流程運轉、部門設置及職能規劃等最基本的結構依據。

例如，A 公司營銷部門的組織架構為：營銷總監下設營銷部經理和業務部經理，經理分別下設兩個主管，主管下設專員，上級領導下級，下級對上級負責。具體圖示如下：

A 公司營銷部的業務訴求是：營銷總監能查看營銷部的所有數據，部門經理能查看本部門的所有數據，部門主管能查看所有下屬的數據，專員只能查看自己的數據。

那我們如何通過組織機構樹進行數據權限設計呢？

①根據業務訴求，我們創建管理員、部門管理員、部門主管、普通用戶 4 個角色，并定義這 4 個角色在組織機構樹中的權限范圍，具體如下表所示：

②給相應人員創建賬號，并將對應的角色賦予賬號，具體圖示如下：

③系統通過讀取這棵組織機構樹上的節點來實現數據權限的控制。

1. 賬號 0 被賦予管理員角色，該賬號處于整棵組織機構樹根節點的位置，且數據權限是“當前節點及其所有子節點”，因此，賬號 0 可以查看整個營銷組織的數據，并能對其進行增刪改查等操作。
2. 賬號 1 被賦予部門管理員角色，該賬號處于營銷部經理的根節點，且數據權限是“當前節點及其所有子節點”，因此，賬號 1 可以查看營銷部的所有數據，并能對其進行增刪改查等操作。
3. 賬號 2 被賦予部門主管角色，數據權限是“當前節點及其所有子節點”，因此，賬號 2 可以查看本人及其下屬的所有數據，并能對其進行增刪改查等操作。
4. 賬號 3 被賦予普通用戶角色，數據權限是“當前節點”，因此，賬號 3 只能查看并操作本人的數據。

至此，根據組織機構樹已實現對整個營銷部門的數據權限管理。

四、結語

本文探討了權限設計的定義、類型，著重介紹了功能權限和數據權限的設計方法。然而，這些只是權限設計的冰山一角。在接下來的 B 端系統的設計生涯中，期待我們更多的理論探索和實踐驗證！