4個步驟教你:如何建立后臺通用權限管理系統?
由于本人的工作方向偏向于后臺,同時也是技術出身轉崗產品經理,在設計后臺時常會查閱后臺的相關資料,但是網上關于這方面的分享也比較少,于是利用空閑時間,把所經歷的三家公司所設計過的后臺系統進行整理、總結,輸出一套通用的完整解決方案。系統的跟大家一起來探討、分享,希望對大家有所裨益。
由于不同的后臺管理系統需求多樣化,此處所分享的是通用型,對于大多數的后臺管理系統邏輯都已足夠使用,主要應用于WEB應用程序,如:網站管理后臺、CMS、CRM、OA等等。
當然,您也可以對他進一步深度設計,以做出更強的系統。
涉及到權限的問題往往是都是復雜的問題,在系統權限控制方面,我們經常會參照現成的案例來設計自己的權限控制,以下就是我所總結最常見的四種權限控制的方法。(附上高保真原型鏈接+整體結構圖:見最底部)
一、控制系統的帳號及登錄
1. 登錄首先要有帳號,帳號的定義
基本上所有的互聯網產品,無論是移動端、PC端、C端或B端產品,登陸都需要一個賬號。只是對于C端的產品,都是用戶自己注冊即可。
而對于后臺產品而言,是需要公司內部人員去創建賬號的。而這個賬號就是一把鑰匙,我們通過控制賬號所具備的權限,進而控制這個員工的所操作范圍。
2. 帳號的兩個層級:企業(管理員)帳號、普通帳號
公司的實際運營人,他應該掌握最核心、權限最大的企業帳號,所以也可以稱為“管理員帳號”,其他都為普通帳號。
在實際系統中的核心業務步驟如下:
- 企業購買系統時,創建一個企業帳號,這個企業帳號綁定的手機號碼為公司實際運營人的手機號碼。該手機號碼必要時可以解綁修改(例公司運營人變更),但是企業帳號不可刪除、離職。
- 在部署培訓階段,可指導企業賬號持有人創建一個或多個普通賬號(可是給其帳號授權管理員角色),該賬號一般授權給行政總監或人力資源總監,后續配置即由管理員賬號進行。
這里需要注意的是2者區別:
- 帳號禁用:在登錄系統時多次輸入密碼錯誤,系統會因為帳號安全問題暫時把禁用掉。或涉及到帳號被盜等場景需立馬禁用,修改密碼等操作。
- 帳號停用:員工離職,但是在職時所有的操作記錄信息還存在,所以設置為停用。(ps:可以跟人事系統打通,人事那邊設置某員工離職后,所有系統賬號自動設為停用。)
在用戶狀態上加狀態控制,可用的用戶就可以登錄系統,禁用、停用的就無法登錄。
二、角色管理
角色往往是基于業務管理需求而預先在系統中設定好的固定標簽,每個角色對應明確的系統權限,他是一個集合的概念,是眾多最小權限顆粒的組成。我們通過把權限給這個角色,再把角色給賬號,從而實現賬號的權限,因此它承擔了一個橋梁的作用。引入角色這個概念,可以幫助我們靈活的擴展,使一個賬號可以具備多種角色。
其所擁有的系統權限一般不會隨意更改,并且角色也不會隨著用戶的被添加和被移除而進行改變,相較于用戶管理而言更加穩定。
由于隨著公司擴大角色的增多,而不好進行管理,比如:hr這個角色,如果集團有分公司可以給與分類,比如:上海分公司:人力總監;北京分公司:人力總監。
這個角色所賦予的數據權限會不一樣,對于中小型公司,可以對角色進行一個精細的分類管理起來比較方便。
三、控制功能權限
功能權限定義:為可見、可以操作的功能范圍。例如:某一部分菜單,或者某個頁面里的各種操作。
1. 菜單管理模塊
類型分為3種:目錄、菜單、按鈕。
- 在目錄、菜單上加權限控制,有權限的就可以訪問對應模塊,沒有的連菜單名都看不到。
- 在業務模塊的功能按鈕上加權限控制,最小粒度的控制用戶行為,譬如:老板娘有錄入商品的權限,就能看到商品錄入的按鈕,點擊錄入就可以進行商品的錄入操作;反之沒有該權限的店員就無法進行商品錄入的操作。
2. 控制功能權限管理
底層菜單管理配置一般為開發人員一早就配置好,現在由用戶進行分配使用這些功能權限。
功能權限:以角色為基礎,通過劃分不同角色的不同功能權限,并將員工添加到對應的角色中,實現員工功能權限的區分和隔離,包括:
- 對象級功能:比如功能的入口是否可見,如角色為“藍鯨觀察者”,對象“人員管理”的“查看列表”權限點取消,則此角色下員工不可見人員管理的功能入口。
- 操作點權限:比如新建、編輯等業務操作;
- 字段權限:在展示信息時加權限控制,保證敏感信息的安全性??蔀榻巧渲脤ο笞侄蔚淖x寫、只讀或不可見。比如:為角色“服務人員”配置銷售訂單的【銷售訂單金額】字段不可見。
控制了員工對字段的可見性,可編輯性,比如:不想要電銷人員看到客戶的電話號碼,不需要服務人員看到客戶銷售訂單中銷售訂單金額,則可以把相應字段隱藏。
- 【讀寫】權限:員工將具備該字段的最大權限,【新建】【編輯】時可編輯,列表和詳情頁可見該字段。
- 【只讀】權限:員工在【新建】【編輯】時不可編輯,列表和詳情頁可見該字段。
- 【不可見】權限:員工在【新建】【編輯】【列表】【詳情】界面對該字段(或該字段值)不可見。
功能權限對于前端界面的影響點:
- 如果員工沒有某對象“查看列表”的權限,則該對象的功能入口會被隱藏。
- 如果員工沒有某對象的操作點權限,則在對象頁面上隱藏相應操作按鈕。
- 如果員工沒有某對象的指定字段的可見權限,則在對象頁面上隱藏相應字段。
3. 控制字段權限用戶操作界面
控制字段權限需要有一個頁面配置頁面來做支撐,此界面由開發人員進行控制操作。
點擊某一個頁面進行配置,可以進行添加,或從數據庫快速生成屬于這個頁面的字段。在從這個頁面的字段中選擇哪些字段是提供給用戶進行設置字段權限,因此有了上上圖。以及字段的顯示名稱,是否必填字段都是控制提供給用戶進行設置字段權限界面。
4. 控制數據權限
數據權限定義:數據權限管理主要控制某條數據記錄對用戶是否可見,結合功能權限可以更靈活的配置業務過程中每一位員工的功能操作權限及數據可見范圍,全面保障企業數據的安全性。
類似矩陣列表中,功能權限決定用戶可見哪些列,比如客戶對象中可見姓名、電話、郵箱等字段。數據權限決定用戶可見哪幾條數據,比如:“王先生”、“李先生”等。
數據權限分兩個層次來控制數據:
- 基礎數據權限:即根據數據的負責人來決定。
- 數據共享:根據基礎數據權限中的數據記錄所屬將其共享給其它用戶查看或編輯。
基礎數據權限:
- 私有:對象中所有數據遵循相關團隊成員(包括負責人)及其上級對數據可見,且對這條數據具備同樣的權限【只讀、可編輯】,上級部門的部門負責人可以看到下級部門的所有數據。
- 公開只讀:對象中所有數據對全公司公開,單條數據的負責人及其上級、以及相關團隊具備編輯權限的成員可以編輯該數據。
- 公開讀寫:對象中所有數據對全公司公開,全員可編輯。
備注:此處的“上級”是指用戶的匯報對象,在用戶管理界面可進行編輯匯報對象。
系統初始化一開始默認設置好(默認設置的應該是根據客戶公司實際運營情況),用戶再根據公司的發展而進行改變默認設置,也可進行恢復默認設置,因為默認設置是涵蓋了客戶公司90%的場景。
數據權限共享:
數據共享規則是將某個部門/員工(數據來源)的某個對象(比如客戶)的全部負責的數據共享給某個部門、人員或者用戶組(共享范圍)。配置數據共享規則后,被共享方對共享方所負責的所有數據可見,并具備共享權限對應的操作權限。
業務配置說明:
- 數據來源于:即需要共享的數據,選擇員工即指該員工負責的記錄數據,選擇部門即指該部門下員工負責的記錄數據。
- 共享的數據:選擇需共享的對象,比如:將員工A負責的客戶數據共享給員工B。
- 數據共享到:被共享方,可選擇員工、部門或用戶組,被選擇的員工、部門或用戶組成員將可以看到共享的數據。
- 共享后的權限:配置被共享方可對數據查看或是可編輯的權限,如果配置為“讀寫”權限后,被共享方對共享數據的權限可類比于負責人的權限。
業務場景舉例:銷售一部想讓財務部張三看到該部門的所有銷售訂單數據,并且讓張三可編輯。
(1)共享規則配置
- 【數據來源】是“銷售一部”;
- 【共享數據】是“銷售訂單”
- 【共享范圍】是“張三”;
- 【共享權限】是“讀寫”。
(2) 配置完成后
配置完成后,張三在【銷售訂單】對象,【共享給我的】場景下,可以看到銷售一部的所有員工負責的銷售訂。
附上高保真原型鏈接+整體結構圖:
《藍鯨后臺權限管理系統》高保真原型鏈接:http://www.wulihub.com.cn/go/4Jrn8J/start.html#g=1&p=登錄頁面&c=1
總結
后臺權限管理系統并不是越復雜越好,只有貼合客戶實際需求并具備最大彈性的權限系統,并有效控制開發成本的設計就是合理的設計。
以上根據自己的設計經驗總結給出的一套方案,小小產品一枚,有不足之處,歡迎各路大神拍磚指教~
本文由 @?董小姐 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
原型鏈接可以再發一下嗎?看不了了呢
請問一下,如果我可能所屬多個部門的情況下,如何將確定自己發布的數據是屬于哪個部門呢
請問您這邊所屬多個部門的業務場景是?
所屬多個部門的情況,從人事的角度一般為借調 或 兼職。
1、借調:例如,張三從A部門借調到B部門,那么在借調期間,該員工屬于B部門,所產生的業務數據,如薪資、績效等都歸屬B部門。有B部門權限的管理員才能看到這些業務數據,A部門的管理員的權限只能在員工檔案看到此張三檔案數據,無法看到張三產生的B部門的業務數據。
借調期結束后,張三所屬部門變回A部門后,這時再產生的業務數據歸屬A部門。
2、兼職:例如,張三本部門為產品部老大,兼職測試部老大。實際所屬部門不變,那么產生的相關業務數據一般歸屬產品部,只不過在審批流、考評上,系統按照關系找產品部、測試部的領導時均可找到張三。
還有一種情況,由于該員工所屬多個部門,所以在創建業務數據時,應該下拉選擇所屬部門,讓數據有個歸屬部門。
ps:所屬部門數據來源為員工所屬部門和兼職部門的數據,不過主要結合實際系統業務設計。
希望對您有幫助!
你好,理解下來角色授權那邊的字段權限資源是通過頁面管理這個模塊功能來實現的,但是頁面和菜單的關聯是如何實現的呢,是通過頁面管理中的那個主鍵嗎?
請問菜單管理中的連接目標是干什么的,在設計中是必須的嗎
請問可以分享一下框架圖的原型文件嗎
挺不錯哦(這不是機器回復)
分享內容很詳實,謝謝樓主。
你好,查看原型鏈接需要登錄?
不需要,直接點擊登錄即可進入
請問下組織架構管理采用樹狀結構的形式展現好實現嗎?會不會被前端砍啊
數量比較龐大的組織確實不適合用這個組件,確實會被前端砍
反手就是一個訂閱加個贊
謝謝支持哦!
你好,有框架圖的原型文件可以分享么?
具體可以直接在文章中預覽哦
有問題想討論下:1)共享功能中,如果被共享人沒有被共享模塊的菜單和功能權限,這種情況是怎么處理的?2)當前登錄人可以查看的數據范圍是按什么維度來控制的呀?3)因為有主部門和附屬部門,新建數據的時候,怎么來判斷該數據是屬于主部門還附屬部門?
1、跟共享人有沒有權限沒關系,例如員工沒有請假單模塊權限,但是hr有啊,可以幫他錄入。
數據共享規則是將某個部門/員工(數據來源)的某個對象(比如請假單)的全部單據的數據共享給某個部門、人員或者用戶組(共享范圍)。
2、當前登陸人可以查看的數據范圍在數據共享那邊去決定
3、新建數據,怎么判斷該數據屬于主部門還是復數部門什么意思
樓主的第一個問題的意思我明白:
還是這個業務場景舉例:銷售一部想讓財務部張三看到該部門的所有銷售訂單數據,并且讓張三可編輯。
被共享人張三被共享了銷售訂單的數據權限,但是按照業務理解,財務人員張三理應是沒有訂單模塊的權限啊,比如訂單的列表查看,訂單詳情等等。但這個時候共享了訂單數據給張三卻沒有該訂單模塊的菜單及功能權限。出現矛盾….
你好,需要有菜單權限,分配的數據權限才會發生作用哦,如果沒分配菜單權限為啥要共享數據呢,數據權限在功能權限的基礎上成立,目前前端頁面是沒有這個判斷的,但是程序邏輯里邊要有這層的判斷。如果沒有菜單權限,數據權限有沒有分配都是一樣的。
這是我的想法,歡迎交流!
3)是否可默認為主部門,可以修改;或者在上層已經存在部門間數據隔離,數據歸屬可以繼承
功能是挺全的,就是感覺操作太復雜了 ?
涉及到底層的權限分配是會比較復雜,只要理清邏輯業務,大家可把這個作為參考自行根據實際情況優化哦~
這種設置方法的話,如果一個字段權限設置了讀寫,但對應操作權限沒有選,或者反過來的時候,系統邏輯如何判斷呢?
只有進行勾選了查看列表,才顯示設置字段權限按鈕
你好高保真原型圖鏈接打開怎么是登錄頁面的?。?/p>
不好意思看懂了
你好,加我一下,1903841331微信
你好有框架圖的原圖嗎?
有的,可加我微信:13544773417
你也太好了吧 ??