編輯導語：任何系統/産品搭建時，最先考慮的都應該是權限管理模塊，而且權限管理模塊的清晰、穩定是平台産品健康發展的基石，權限管理核心考慮的問題是用戶與權限的關系。本文作者對三種不同權限管理的版本展開了梳理分析，與大家分享。

01 超簡版本-用戶/權限模型

用戶直接與權限映射，這種設計的優勢在于簡潔直觀，适合用戶數量不多，功能較為簡單的系統，它的劣勢也是非常的明顯當用戶量增多時，維護成本較高，可擴展性差。

系統頁面Demo：

02 進階版本-用戶/角色/權限模型

若系統用戶和功能增多，為每一個用戶匹配單獨的權限，會變得非常的繁瑣，因此權限分門别類，形成“權限包”。從用戶的角度，将用戶分類，同一類用戶固定為相同的角色，賦予相同的權限，會讓操作變得簡單很多。

系統頁面Demo：

03 層級版本-組織/用戶/角色/權限模型

對于管理性後台，往往人員是職級區分的，比如用戶王五為銷售組長，其組員趙六和孫七，王五需要看到趙六和孫七的銷售額數據和可以進行趙六和孫七的所有操作，而趙六僅能看到自己的銷售額數據，進行和自己相關的操作。

這個事例中引入了兩個新的概念，一是用戶的權限可以細分為功能權限和數據範圍權限，二是數據範圍和功能權限都有了繼承的層級概念。

所謂功能權限大家比較好理解，比如能否看到某個頁面，能否點擊某個按鈕。而數據權限略抽象些，比如在業績報表模塊，從功能權限角度，可以決定用戶能否打開這個報表頁面，但是不同用戶進來看到不同的數據（王五需要看到趙六和孫七的銷售額數據，而趙六僅能看到自己的銷售額數據，看不到孫七的），則是由數據範圍來控制的。

1. 數據範圍的繼承

我們可以将用戶進行分級管理，比如建立多層級的組織架構樹，将不同用戶放置于組織架構的不同根節點上，來實現多層級用戶的建立和管理。

1）如果用戶的層級如果比較簡單（不多于三級），可以将層級關系融入到角色之中。比如用戶分為三級：管理員-組長-組員，管理員能看到全部的數據範圍和擁有全部的功能權限，而組長能查看組員的數據範圍和擁有部分功能權限（比如無法編輯用戶），而組員的數據範圍僅僅為自己負責的數據和擁有部分功能權限。

我們可以在組長這個角色下，允許其綁定組員，針對不同的角色設置不同的數據範圍讀取方式，管理員可以讀取全部數據範圍，組長需要讀取其組員的，組員隻能讀取自己的。大家有興趣可以去了解下RBAC0/1模型

2）而對于用戶層級較多的情況，建議采用多層級的組織架構的管理模式，先建立公司的組織部門，再将人置于組織架構樹的不同節點之下。以用戶在組織節點的位置，以及是否為某個節點組織的負責人，來确定其數據範圍。

2. 功能權限的繼承

一般是将角色進行分級，有了所謂的角色樹的概念

由此，我們就得到了自由度更高但是邏輯更複雜的權限管理

涉及到組織架構樹和角色樹，需要考慮到的場景更多，這些細節要根據實際的業務場景來制定方案。比如：

1. 組織有成立和解散的時間，員工也存在轉崗換組織部門的情況，因此要考慮引入時間軸的概念。增加很多的校驗邏輯，比如需要增加員工入職、離職時間，且員工在該部門任職的時間不能早于部門成立的時間等等
2. 同一員工能否兼崗，允許在多個組織下存在
3. 角色上是否會有互斥情況存在（RBAC-2模型），比如實際業務中，發鈔和驗鈔的工作不允許同一個人做，因此在功能設計時要考慮角色之間的互斥性，通過為用戶配置角色來實現用戶與權限的映射關系，不同權限間是存在優先級的，比如剛剛的例子，互斥關系為最高優先級

實體關系圖 ：

系統頁面Demo：

上述分析的三種權限管理其實并無優劣之分。權限管理作為系統的基石，應依據系統目标用戶特點、後續發展方向、維護成本等方面進行綜合評估，找到最适合系統的模式即可。

知識點總結

1. 用戶管理核心是解決用戶與權限的問題；
2. 角色可理解為一類用戶，或者一堆權限的集合，鍊接了用戶與權限的關系；
3. 權限可以分為功能權限和數據範圍；
4. 複雜的繼承關系，數據範圍依賴用戶組織架構樹，功能權限依賴角色樹，将用戶放置于組織架構樹的不同節點上，并賦予角色，即解決了功能權限和數據範圍的問題；

作者：yingying之語；公衆号“yingying之語”，持續分享B端産品設計經驗，期待與小夥伴們一起交流探讨

本文由 @yingying之語 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部