由于本人的工作方向偏向于後台，同時也是技術出身轉崗産品經理，在設計後台時常會查閱後台的相關資料，但是網上關于這方面的分享也比較少，于是利用空閑時間，把所經曆的三家公司所設計過的後台系統進行整理、總結，輸出一套通用的完整解決方案。系統的跟大家一起來探讨、分享，希望對大家有所裨益。

由于不同的後台管理系統需求多樣化，此處所分享的是通用型，對于大多數的後台管理系統邏輯都已足夠使用，主要應用于WEB應用程序，如：網站管理後台、CMS、CRM、OA等等。

當然，您也可以對他進一步深度設計，以做出更強的系統。

涉及到權限的問題往往是都是複雜的問題，在系統權限控制方面，我們經常會參照現成的案例來設計自己的權限控制，以下就是我所總結最常見的四種權限控制的方法。（附上高保真原型鍊接 整體結構圖：見最底部）

一、控制系統的帳号及登錄

1. 登錄首先要有帳号，帳号的定義

基本上所有的互聯網産品，無論是移動端、PC端、C端或B端産品，登陸都需要一個賬号。隻是對于C端的産品，都是用戶自己注冊即可。

而對于後台産品而言，是需要公司内部人員去創建賬号的。而這個賬号就是一把鑰匙，我們通過控制賬号所具備的權限，進而控制這個員工的所操作範圍。

2. 帳号的兩個層級：企業（管理員）帳号、普通帳号

公司的實際運營人，他應該掌握最核心、權限最大的企業帳号，所以也可以稱為“管理員帳号”，其他都為普通帳号。

在實際系統中的核心業務步驟如下：

1. 企業購買系統時，創建一個企業帳号，這個企業帳号綁定的手機号碼為公司實際運營人的手機号碼。該手機号碼必要時可以解綁修改（例公司運營人變更），但是企業帳号不可删除、離職。
2. 在部署培訓階段，可指導企業賬号持有人創建一個或多個普通賬号（可是給其帳号授權管理員角色），該賬号一般授權給行政總監或人力資源總監，後續配置即由管理員賬号進行。

這裡需要注意的是2者區别：

1. 帳号禁用：在登錄系統時多次輸入密碼錯誤，系統會因為帳号安全問題暫時把禁用掉。或涉及到帳号被盜等場景需立馬禁用，修改密碼等操作。
2. 帳号停用：員工離職，但是在職時所有的操作記錄信息還存在，所以設置為停用。（ps：可以跟人事系統打通，人事那邊設置某員工離職後，所有系統賬号自動設為停用。）

在用戶狀态上加狀态控制，可用的用戶就可以登錄系統，禁用、停用的就無法登錄。

二、角色管理

角色往往是基于業務管理需求而預先在系統中設定好的固定标簽，每個角色對應明确的系統權限，他是一個集合的概念，是衆多最小權限顆粒的組成。我們通過把權限給這個角色，再把角色給賬号，從而實現賬号的權限，因此它承擔了一個橋梁的作用。引入角色這個概念，可以幫助我們靈活的擴展，使一個賬号可以具備多種角色。

其所擁有的系統權限一般不會随意更改，并且角色也不會随着用戶的被添加和被移除而進行改變，相較于用戶管理而言更加穩定。

由于随着公司擴大角色的增多，而不好進行管理，比如：hr這個角色，如果集團有分公司可以給與分類，比如：上海分公司：人力總監；北京分公司：人力總監。

這個角色所賦予的數據權限會不一樣，對于中小型公司，可以對角色進行一個精細的分類管理起來比較方便。

三、控制功能權限

功能權限定義：為可見、可以操作的功能範圍。例如：某一部分菜單，或者某個頁面裡的各種操作。

1. 菜單管理模塊

類型分為3種：目錄、菜單、按鈕。

• 在目錄、菜單上加權限控制，有權限的就可以訪問對應模塊，沒有的連菜單名都看不到。
• 在業務模塊的功能按鈕上加權限控制，最小粒度的控制用戶行為，譬如：老闆娘有錄入商品的權限，就能看到商品錄入的按鈕，點擊錄入就可以進行商品的錄入操作；反之沒有該權限的店員就無法進行商品錄入的操作。

2. 控制功能權限管理

底層菜單管理配置一般為開發人員一早就配置好，現在由用戶進行分配使用這些功能權限。

功能權限：以角色為基礎，通過劃分不同角色的不同功能權限，并将員工添加到對應的角色中，實現員工功能權限的區分和隔離，包括：

• 對象級功能：比如功能的入口是否可見，如角色為“藍鲸觀察者”，對象“人員管理”的“查看列表”權限點取消，則此角色下員工不可見人員管理的功能入口。
• 操作點權限：比如新建、編輯等業務操作；
• 字段權限：在展示信息時加權限控制，保證敏感信息的安全性。可為角色配置對象字段的讀寫、隻讀或不可見。比如：為角色“服務人員”配置銷售訂單的【銷售訂單金額】字段不可見。

控制了員工對字段的可見性，可編輯性，比如：不想要電銷人員看到客戶的電話号碼，不需要服務人員看到客戶銷售訂單中銷售訂單金額，則可以把相應字段隐藏。

• 【讀寫】權限：員工将具備該字段的最大權限，【新建】【編輯】時可編輯，列表和詳情頁可見該字段。
• 【隻讀】權限：員工在【新建】【編輯】時不可編輯，列表和詳情頁可見該字段。
• 【不可見】權限：員工在【新建】【編輯】【列表】【詳情】界面對該字段（或該字段值）不可見。

功能權限對于前端界面的影響點：

• 如果員工沒有某對象“查看列表”的權限，則該對象的功能入口會被隐藏。
• 如果員工沒有某對象的操作點權限，則在對象頁面上隐藏相應操作按鈕。
• 如果員工沒有某對象的指定字段的可見權限，則在對象頁面上隐藏相應字段。

3. 控制字段權限用戶操作界面

控制字段權限需要有一個頁面配置頁面來做支撐，此界面由開發人員進行控制操作。

點擊某一個頁面進行配置，可以進行添加，或從數據庫快速生成屬于這個頁面的字段。在從這個頁面的字段中選擇哪些字段是提供給用戶進行設置字段權限，因此有了上上圖。以及字段的顯示名稱，是否必填字段都是控制提供給用戶進行設置字段權限界面。

4. 控制數據權限

數據權限定義：數據權限管理主要控制某條數據記錄對用戶是否可見，結合功能權限可以更靈活的配置業務過程中每一位員工的功能操作權限及數據可見範圍，全面保障企業數據的安全性。

類似矩陣列表中，功能權限決定用戶可見哪些列，比如客戶對象中可見姓名、電話、郵箱等字段。數據權限決定用戶可見哪幾條數據，比如：“王先生”、“李先生”等。

數據權限分兩個層次來控制數據：

1. 基礎數據權限：即根據數據的負責人來決定。
2. 數據共享：根據基礎數據權限中的數據記錄所屬将其共享給其它用戶查看或編輯。

基礎數據權限：

1. 私有：對象中所有數據遵循相關團隊成員（包括負責人）及其上級對數據可見，且對這條數據具備同樣的權限【隻讀、可編輯】，上級部門的部門負責人可以看到下級部門的所有數據。
2. 公開隻讀：對象中所有數據對全公司公開，單條數據的負責人及其上級、以及相關團隊具備編輯權限的成員可以編輯該數據。
3. 公開讀寫：對象中所有數據對全公司公開，全員可編輯。

備注：此處的“上級”是指用戶的彙報對象，在用戶管理界面可進行編輯彙報對象。

系統初始化一開始默認設置好（默認設置的應該是根據客戶公司實際運營情況），用戶再根據公司的發展而進行改變默認設置，也可進行恢複默認設置，因為默認設置是涵蓋了客戶公司90%的場景。

數據權限共享：

數據共享規則是将某個部門/員工（數據來源）的某個對象（比如客戶）的全部負責的數據共享給某個部門、人員或者用戶組（共享範圍）。配置數據共享規則後，被共享方對共享方所負責的所有數據可見，并具備共享權限對應的操作權限。

業務配置說明：

• 數據來源于：即需要共享的數據，選擇員工即指該員工負責的記錄數據，選擇部門即指該部門下員工負責的記錄數據。
• 共享的數據：選擇需共享的對象，比如：将員工A負責的客戶數據共享給員工B。
• 數據共享到：被共享方，可選擇員工、部門或用戶組，被選擇的員工、部門或用戶組成員将可以看到共享的數據。
• 共享後的權限：配置被共享方可對數據查看或是可編輯的權限，如果配置為“讀寫”權限後，被共享方對共享數據的權限可類比于負責人的權限。

業務場景舉例：銷售一部想讓财務部張三看到該部門的所有銷售訂單數據，并且讓張三可編輯。

（1）共享規則配置

• 【數據來源】是“銷售一部”;
• 【共享數據】是“銷售訂單”
• 【共享範圍】是“張三”;
• 【共享權限】是“讀寫”。

（2） 配置完成後

配置完成後，張三在【銷售訂單】對象，【共享給我的】場景下，可以看到銷售一部的所有員工負責的銷售訂。

附上高保真原型鍊接 整體結構圖：

總結

後台權限管理系統并不是越複雜越好，隻有貼合客戶實際需求并具備最大彈性的權限系統，并有效控制開發成本的設計就是合理的設計。

以上根據自己的設計經驗總結給出的一套方案，小小産品一枚，有不足之處，歡迎各路大神拍磚指教~

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

題圖來自Unsplash，基于CC0協議

,

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

查看全部