在做b端產品，不可避免的遇到權限管理，權限設計，根據什么樣的角色，授予什么樣的權限，然而權限還涉及到數據權限和功能權限，在說什么是權限，先引入角色的概念
什么是角色
角色，通俗的說，你是什么樣的角色，例如你是管理員和普通用戶，是兩個角色，管理員擁有所有的權限，而普通用戶只有部分權限。
管理員可以對普通用戶設置權限，例如，普通用戶A之前是可以查看和刪除評論功能，管理員修改了普通用戶A的權限，不能進行刪除評論功能，此時普通用戶A只有查看的權限。沒有刪除的權限，至于刪除按鈕是否顯示，這是前端設計：
方案一：可以保留刪除按鈕，置灰操作或者點擊提示你沒有刪除權限；
方案二：隱藏刪除按鈕，普通用戶沒有刪除按鈕。
在說到管理員和普通用戶兩種角色，他們分別對應不同的權限，同事在一個系統里，會出現很多種角色，所有需要對角色進行管理，增、刪、改、查、設置權限、最基本的五項，其中刪除功能在設計過程中要引起注意，刪除角色，該角色中人員，人員在系統中有操作行為產生了數據，直接刪除角色，會導致系統報錯。
舉個簡單的例子，在商城系統中，人員A在在系統中創建了商品，而創建商品的是只有“店長”這個角色可以創建商品，所以人員A就擁有店長這個角色。這里說明下，人員A不是屬于店長這個角色，而是擁有，是一個人員對應對個角色的關系。此時把店長角色刪除了，而人員A只設置了一個店長這個角色的時候，該人員自然就報錯了，他不屬于任何角色。
回到角色管理，一個角色對應哪些權限，而管理員擁有所有權限，所以在設計權限管理的過程中要注意管理員和普通角色這兩種角色
功能權限設計
權限設計，可以把一個系統所有的功能設計相應的權限，例如商城管理中，商品管理這個模塊，在設計權限過程中，就設計到如下權限：
a、新增商品
b、修改編輯商品
c、商品的上架下架
d、刪除商品
e、查看商品
......
以上是功能權限，設計過程中，可以將每個功能設計復選框，管理員擁有所有權限，流程上實現方式如下：
創建用戶--->選擇角色--->設置權限。例如創建的用戶B可以新增商品，編輯商品，上下架商品，查看商品，但是出于安全考慮，不允許用戶B刪除商品，設置用戶B對應的角色中不設置有刪除商品的功能。
設計功能權限應該注意什么
一、管理員權限
由于一個系統，一個平臺使用的人員較多，涉及到的角色也較多，會出現一個系統多個管理員，分級管理員的情況。另外由于系統處于開發中，會一直新增功能，如果管理員也是同普通角色一樣，勾選權限列表功能（全選），雖然是全選，但是后續新開發的模塊，需要一一的去權限，一來麻煩，二來設計的也不合理，所有管理員的權限，不應該是同普通角色一樣去全選所有的角色，而是默認所有的權限。
二、功能權限的顆粒度
功能權限的顆粒度需要多細，根據實際的場景去考慮，1）如果是對權限管控要求很嚴格的，需要細化功能權限，例如政府部門系統的設計。2）BtoC產品，為了方便使用者理解和使用系統，功能權限的設計就不需要很細，例如商城系統中商品的搜索功能，搜索商品功能有下拉根據什么屬性篩選，根據時間篩選，查看列表等等，而作為用戶，是可以搜索和查看商品，在設置搜索商品的權限。也就擁有是搜索功能權限，可以按時間搜索，也可以按時間搜索。
三、更多需要注意的坑，待補充......
什么是數據權限
對于數據權限，接觸了很多次，一直不明白，或者處于半明白狀態，這里要感謝程序猿的指導。
百度找了下數據權限的定義，并沒有，我去。
開發系統，各種功能，由功能產生了數據，但是數據并不是對所有人開放和顯示，所以就引入數據權限的概念。而數據權限在交互上是不會體現出來，在中小型系統上也不會顯示數據權限的設置頁。
引入一個例子方便理解：電商商城，由于后臺商城可以創建或維護不同的店鋪，有店鋪列表的概念，A店鋪產生的數據，商品，訂單等不會在B店鋪中顯示出來，這就是數據權限對之進行了限制。那有人會問，在功能設計過程中，查詢功能不是進行了限制，這是是個誤導，用戶C可以查看商品，不沒有說明可以查哪些店鋪的商品：1）如果用戶C是個管理員，那他就擁有查看所有店鋪的商品，2）如果用戶C只是一個店鋪的子管理員，那他的權限只能查看該店鋪的商品，3）如果用戶只是一個店鋪中的一個普通員工C，該店鋪有衣服商品，辦公用品等各種各樣的商品，而該普通員工C只管衣服商品，這時處于衣服這個商品可以查看，其他商品均不能查看。
以上就是數據權限的概念，僅通過功能權限是不夠的。
數據權限如何設計
我在做后臺系統過程中，遇到過技術要求產品要涉及數據權限，也有技術不要求設計數據權限，那么產品要不要設計數據權限，以及如何設計數據權限?
根據四個方面的因數考慮：
1? 根據系統的大小，該系統只有一個系統，還是該系統下有很多子系統，或者系統下各個模塊數據的獨立性，不能共享，例如商品平臺多個店鋪，功能間就不能共用；
2 系統對權限劃分的顆粒度，根據權限細節角度，權限層級也多，則越需要有數據權限；
3 根據使用場景，需要后期人為去設置數據權限，還是在程序中可以默認設置權限。
4、根據創建賬號所在的層級，例如創建賬號是最上層管理平臺上，此時需要設置數據權限，如果創建賬號是屬于分支平臺上創建，則不需要數據權限
5、....
只要理解了數據權限和功能權限區別，至于要不要設計數據權限，在實踐的過程中，就心里有數了。權限管理其實沒有那么難，只要理解了就好，他是系統不可缺少的部分。當然也存在系統較小，所有人在同一個平臺的操作權限都一樣，這種比較少。
有一本書，《通用權限管理系統》，寫的有點多，而且會比較過時，不過還是蠻有用的，對權限這塊的了解和熟悉。
全文沒設計圖，也沒有流程，懶的畫懶的找了。如果邏輯上有錯，歡迎提出來...
各位看官，看完喜歡點個贊唄~
2019年7月27更新
補充菜單管理，字典管理和系統日志
權限管理一直都是B端產品很重要的部分，小編在工作中，設計過程中需要有菜單管理，字典管理，系統日志，這些其實是架構師給我的指導和梳理，再次感謝程序員大大
那菜單管理，字典管理，系統日志又是什么，他和權限又有什么依賴關系？
菜單管理
菜單管理，他是系統最高級管理員需要用到的功能
這里需要做個說明，最高級管理員開發者管理員的區別，如果系統是做平臺層，或者比較大的系統，菜單是需要做到動態的，而我們常見的最高級管理員，是使用者的最高級管理員，并不是開發者的管理員，開發者的管理員所具有的功能才是最全的，那么有人問，使用者的最高級管理員和開發者最高級管理員合并為一個，不就可以了，其實不然，由于使用者他不一定會懂得編程，對于一些開發的一些概念不懂，也看不懂對應的菜單，比如環境探針，開發者監控日志等，這些如果給到最高級使用者管理員，他們看不懂，也會覺得做的系統奇葩。不需要展示的開放出來干什么。實際上是開發者用的
回到菜單管理，由于系統龐大，或者系統是平臺層的，而當平臺層需要創建一個新的產品，新的產品菜單的創建，這時候就要菜單管理去增刪改查。而這個權限一般是不會下設給其他人，不管系統管理上就亂了
字典管理
所謂字典管理，字段名稱創建的根源，一般來說字典管理中的管理表，包含的屬性有：名稱，名稱編碼。具體的數據，舉個例子：比如性別：區分男/女.而男對應的名稱編碼比如是0，女對應的名稱編碼是1.這就是字典管理中的兩條數據。不外乎關聯其他功能，他是有系統層直接管轄，不受其他數據的牽連，而業務層需要用到，可以調用字典管理中的數據，比如個人中心中需要用到性別字段，可以調用字典管理中的數據。
字典管理，頁面上的呈現一般是直接設計一個表，新增的數據，可以是，性別，身高，體重，可選項中的選項值。
這是和架構師學的，其實字典管理，和我們日常使用中的字典有著同樣的作用，比如我們去查康熙字典，具體到某個字，這個字可以在不同的地方，不同的語境下產生作用，但是他字的根源在康熙字典中。（杠精會說 字的根源不在字典中，這是比喻，比喻我們設計系統字典管理是什么，他產生的作用是什么，起到什么作用。）
系統日志
我們常見的有登錄日志，操作日志，監控日志，等等，他和系統日志又有什么管理，其實是"父子”關系，即系統日志包含所有的日志，系統日志底下有登錄日志，操作日志，監控日志，他們各自起到不同的作用，比如我們常見的禪道，有登錄日志和操作日志，即登錄記錄和操作記錄，作為管理者可以查看，統計，跟蹤問題，跟蹤責任，記錄事實等。而監控日志，一般是給開發人員用的，系統大數據的并發，產生的卡頓，bug，系統崩潰等，為了方便定位問題，優化系統。
