本文主要介紹B端產品中權限體系的設計模式，並賦予實際案例展示。
一、權限體系簡介
權限管理是一個幾乎所有大中型B端系統的都會涉及的一個重要組成部分，主要目的是對整個後臺管理系統進行權限的控制，而針對的對象是員工，避免因權限控制缺失或操作不當引發的風險問題，如操作錯誤，數據洩露等問題。
抽象來看權限體系可以分為如下兩類：功能權限與數據權限兩部分：
- 功能權限：指的是在系統中的一系列操作。常見的如：刪除，編輯，提交等
- 數據權限：指數據中存在的數據是否能查看，如：釘釘中個人的出勤數據每人能看到，但是全公司的考勤數據卻只有管理員能看到。
在這裡權限的實現一共有兩種模式：
“所見即所得”模式
用最通俗的話來說也就是，能看見相關操作就能執行對應的操作，所有的權限限制就在隱藏對應的操作頁或按鈕上，不進行區分查看與操作。
例如一個項目管理軟件，當用戶擁有了訪問項目操作頁的權限，在本模式裡該項目的增刪改查都對應擁有了，這裡的核心就是隻要能看到就能操作。
這個模式的好處是適合中小型B端客戶，其本身沒有複雜的崗位劃分且要求系統簡單易上手，畢竟一款B端的產品要是權限讓用戶配置半個小時，這對用戶來說是個無比巨大的負擔。
根據我的經驗來看“所見即所得”這種模式基本滿足80%的SaaS系統對權限管理的需求。
“讀寫分離”模式
所謂的讀寫分離，就是在第一種模式上進行了升級（這裡的寫泛指一切關於某模塊的操作）。
怎麼理解呢？當我們擁有了進入該頁面的權限時，如果沒有分配寫的權限，就算看到了這些操作也不能使用。這種模式多用在數據權限上，而功能權限上是多用於預告給用戶，只有當用戶完成指定條件時才可以去操作。如未完成指定信息填寫時，不能點擊提交，但是提交按鈕必須要在頁面出現。
如果讓我們用一張圖來闡明這兩種權限的設計體系的話，應該是這個樣子的：
圖：權限顆粒度
二、功能權限設計
具體來說我們可以劃分為如下三步：
圖：設計步驟
讓我們一步步來看：
步驟1：功能點封裝
這裡就是將我們系統中的功能進行梳理，得出一顆完整的功能樹。你的權限系統想要控制到哪一層級，就將功能拆分到對應的層級即可。
例如：
圖：功能拆分示例
步驟2：權限授予
在拆分完功能點後，我們就相當於有了一個完整的系統權限表（也稱之為權限池），可以清楚的告訴用戶什麼環節可以進行配置，接下來我們需要設計的就是如何讓用戶去分配權限，即：權限授予。
在權限授予上我們要滿足如下兩個基本方向的設計：
- 角色概念：角色的理解，我們可以簡單的理解為是一個個權限的集合。它通過提前將一部分權限進行配置成通用模板，隨後只需將需要的人員授予這個角色就能擁有對應的權限。
- 權限池內自定義授予：在SaaS軟件裡經常我們會遇到這樣的情況，之前我們配置的某某部門經理或助理的角色由於臨時性工作借調可能會涉及多個崗位的工作，從而導致之前的角色權限不能滿足，而此時這種個例現象又不好再單獨創建角色給他，因此需要能在角色外再單獨指派權限的功能。這裡我們就稱之為權限池內自定義授予。當然這裡也適用於不在角色表中的任意權限分配。
值得提一句的是：一般的權限系統中要支持一人授予多個角色的功能。
步驟3：權限累加器
想必在步驟2大家肯定有疑問了，一人可以承接多個角色，又可以自定義額外權限，這樣到最後個人權限要怎麼定呢？
這裡的權限累加器其實就是在解決這個問題，這裡相當於是一個單獨權限計算器，通過將前後授予的權限進行累加得到用戶的最終權限。
這裡的計算規則如下：
- 計算1：將變動前的權限集合在被授予新權限集合後兩者取並集，去重相同的權限；
- 計算2：最終權限 = 角色權限 + 權限池內自定義授予權限
在一般權限授予中，我們給予權限一般都是越給越多。但是也有可能會是將某一角色的權限進行統一減少，此時我們就需要交由累加器幫我們去批量將多個擁有該角色的權限進行計算。
舉個例來看：
在上面的例子中，我們的權限體系在上面進行了三次變動：
第一次：U298，278兩位用戶獲得了初始員工權限並給予了發佈新聞權限，此時由權限累加器幫我們計算出共擁有了7個權限；
第二次：新增了兩位用戶，並將四位用戶在員工角色上又增加了部門助理角色，並額外增加了數據查看權限，此時權限累加器計算出這四位用戶權限數為：
員工角色與部門助理的權限相同權限6項 + 部門助理獨有的4項權限 + 發佈新聞權限 + 數據權限 = 12項；
第三次：四位用戶的共有角色部門助理被減去了一個權限，此時權限累加器計算出這四位用戶權限數為11；
三. 兩種實現示例
“所見即所得”模式
讓我們直接進入權限模塊來看。
首先進入系統管理面板：
在進入內部人員管理界面進行權限配置：
這裡由於原來系統的業務顆粒度本身不高，因此我只將功能劃分到頁面級，也降低了企業管理員的學習配置成本。在這部分裡，用戶只需給每位人員配置擁有什麼頁面的訪問權限，就有了對應的功能權限。
舉例來說如果在上頁我勾選擁有了審批配置權限，也就是可以進入審批模板列表頁，因此這裡所有的功能都可以使用。
“讀寫分離”模式
這種模式其核心在上文已經介紹過了，就是將每個頁面內還要進行只能查看與能編輯兩種狀態。
具體來看看配置頁的實現：
大家可以看到在這裡配置的顆粒度更細，在每個頁面中都進行了進一步劃分，分為查看名稱，進入詳情，刪除三大權限。
而功能頁是這個樣子的：
綜上
對於權限模塊來說，在上面介紹的兩個思路中沒有所謂絕對正確的解決方案。我們應該做的是去選擇最適合自己業務體量的設計模式，避免出現“小馬拉大車”的現象。
PS. 如果喜歡，自願訂閱，投食，良心不痛！
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
