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