酷播亮新聞
文章對賬號權限系統設計展開分析，希望能夠給你帶來些啟發。
一、系統概述
一個賬號權限管理系統，主要包括三個元素：賬號、角色、權限。 我們所要管理的，也就是賬號、角色和權限之間的關係。
賬號：基本上所有的應用，無論是移動端，PC端，C端或B端產品，登陸都需要一個賬號。 只是對於C端的產品，都是用戶自己註冊即可。 而對於後台產品而言，是需要公司內部人員去創建賬號的。
角色：所謂角色，就是用來控制各個賬號的操作範圍的，可以理解為權限組。 因為一個系統中權限太多，我們不可能每創建一個賬號，就去挨個設置一遍權限，因此可以根據不同的部門、職級、工作內容等來對權限進行分組，制定成不同的角色，這樣，在 創建賬號時，就可以直接賦予賬號不同的角色，從而把角色擁有的權限給到這個賬號。
權限：包括數據權限、操作權限和頁面權限。
一、數據權限 ：即賬號可以看到的數據范圍，比如一個旅遊行業的公司管理者能看到公司的所有數據，而亞太部的人只能看到亞太部門產生的數據。 在設計過程中，數據權限控制的難易程度與業務和公司部門設置的複雜程度有關。
二、頁面權限&操作權限 ：頁面權限即賬號可以看到的頁面內容，操作權限即用戶可以進行操作的內容，如增刪改等。 在產品設計的過程中，可以將操作權限和頁面權限結合起來做到一個集合中，創建角色時將權限賦予給角色即可。
系統的主要流程為：將權限設置成不同的集合，即角色，再將角色綁定到賬號上，那麼這個賬號就擁有了這些角色的權限集合。 一個賬號可以綁定多個角色，一個角色又擁有多個權限。
如上圖所示：用戶A擁有了角色1和角色2兩個角色，從而擁有了“增加、刪除、審核”的權限。
二、實例設計
1、賬號管理
添加/編輯賬號：
在創建賬號時，一般都需要填寫基本信息和設置角色。 基本信息主要包括姓名，部門，賬號備註等等，不同企業需求不同。
此外，為了控制數據權限，還可能會有賬號等級的選擇、賬號關聯、上下級關係綁定等操作。 具體流程視設計情況而定。
2、角色管理
添加/編輯角色：
需要說明的是，角色不能隨意刪除或禁用，需要判定該角色有沒有被哪個賬號綁定，若該角色正在被使用，則不允許刪除並給出相應的提示。
三、經驗之談
1、事先可以對賬號進行一個等級劃分（根據實際業務制定劃分規則），然後可以根據等級來判定數據權限。 如等級為公司高級管理者，則可以看到所有的數據，而等級為分公司管理員，則根據分公司的ID或者名稱去獲取對應的數據等。 不過這個只能做一個比較粗略的控制，僅一個等級來控制數據權限是遠遠不夠的；
2、考慮是否需要提供賬號與賬號之間做數據關聯的入口。 當然，這是屬於比較特殊的情況，當設計的控制數據權限的規則都不能滿足的時候，是否需要為特例提供操作入口；
3、考慮是否需要提供一個賬號和數據之間直接做綁定的入口？ 如：等級為分公司管理員，由於業務需求，需要看到另外一個分公司的某條數據，該如何實現。 當然，這裡只是舉了一個很簡單的例子，實際實現時會有很多更細節和深入的問題；
4、若大部分賬號在權限上都存在差異，那是否每個賬號都需要有一個設置詳細權限的地方，而僅把角色當做一個快捷選擇的方式。 （若不是必需，最好不要採取該種方式，這樣會破壞權限的規範性，不利於維護和管理）；
5、創建角色（權限組）之前，需要明確各個部門之間的業務範圍及權限（包括頁面權限和操作權限），並將這些人就行劃分；當然，隨著公司的業務和後台系統功能的改變 ，各個角色的權限是需要不斷完善和調整的；
6、在一些系統流程中，還需要為權限設置互斥關係，這樣的話，擁有互斥權限的兩個角色就不能同時綁定給同一個賬號了。 是否需要這一步操作，需要根據業務情況而定；
7、對於一些基礎的賬號，在創建賬號時，是否需要直接根據賬號等級綁定默認角色（即給以默認權限）。
暫時想到的就是這些，後面想到了會再繼續補充。
小小產品一枚，文章純屬工作中個人經驗總結，歡迎大神拍磚指教。
本文由 @姜蕁 原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自unsplash，基於CC0協議