4個步驟教你:如何建立后臺通用權限管理系統?

73 評論 142882 瀏覽 652 收藏 15 分鐘

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

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

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

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

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

1. 登錄首先要有帳號,帳號的定義

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

而對于后臺產品而言,是需要公司內部人員去創建賬號的。而這個賬號就是一把鑰匙,我們通過控制賬號所具備的權限,進而控制這個員工的所操作范圍。

2. 帳號的兩個層級:企業(管理員)帳號、普通帳號

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

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

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

這里需要注意的是2者區別:

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

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

二、角色管理

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

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

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

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

三、控制功能權限

功能權限定義:為可見、可以操作的功能范圍。例如:某一部分菜單,或者某個頁面里的各種操作。

1. 菜單管理模塊

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

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

2. 控制功能權限管理

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

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

  • 對象級功能:比如功能的入口是否可見,如角色為“藍鯨觀察者”,對象“人員管理”的“查看列表”權限點取消,則此角色下員工不可見人員管理的功能入口。
  • 操作點權限:比如新建、編輯等業務操作;
  • 字段權限:在展示信息時加權限控制,保證敏感信息的安全性??蔀榻巧渲脤ο笞侄蔚淖x寫、只讀或不可見。比如:為角色“服務人員”配置銷售訂單的【銷售訂單金額】字段不可見。

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

  • 【讀寫】權限:員工將具備該字段的最大權限,【新建】【編輯】時可編輯,列表和詳情頁可見該字段。
  • 【只讀】權限:員工在【新建】【編輯】時不可編輯,列表和詳情頁可見該字段。
  • 【不可見】權限:員工在【新建】【編輯】【列表】【詳情】界面對該字段(或該字段值)不可見。

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

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

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

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

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

4. 控制數據權限

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

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

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

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

基礎數據權限:

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

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

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

數據權限共享:

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

業務配置說明:

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

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

(1)共享規則配置

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

(2) 配置完成后

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

附上高保真原型鏈接+整體結構圖:

《藍鯨后臺權限管理系統》高保真原型鏈接:http://www.wulihub.com.cn/go/4Jrn8J/start.html#g=1&p=登錄頁面&c=1

總結

后臺權限管理系統并不是越復雜越好,只有貼合客戶實際需求并具備最大彈性的權限系統,并有效控制開發成本的設計就是合理的設計。

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

 

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

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 董小姐,你好,希望得到你的好友位。以后多交流。謝謝。我的微信BBao-shuang

    來自上海 回復
  2. 非常有用 ?? 感謝

    來自浙江 回復
  3. 很不錯,我能看下原型嗎

    來自北京 回復
    1. 文章中有附上鏈接可以直接預覽的:http://www.wulihub.com.cn/go/4Jrn8J/start.html#g=1&p=登錄頁面&c=1

      來自廣東 回復
    2. 請問這是用工具畫的 ??

      來自浙江 回復
  4. 好文,感謝~

    來自北京 回復
  5. 新建部門這里會有沖突吧,我選擇了建立區域的平級,分類卻選擇部門或者其他非區域分類的分類,會有沖突

    來自廣東 回復
  6. 超級干貨

    來自廣東 回復
  7. 超贊,和我們的需求很類似。你這個原型是用Axure做的嗎?

    來自湖北 回復
  8. 厲害,現在在開發權限這塊,寫的思路比較清晰,尤其是數據權限這塊幫助很大

    來自浙江 回復
  9. 麻煩您加我一下qq1165889793。比較急 公司要0到1做一個oa 什么才是1.0最重要的啊 想問一下董小姐~我也姓董 本家 哈哈

    回復
  10. 學習了 學習了 感謝分享 最近也正好在思考權限系統的東西

    來自上海 回復
  11. 學習了,但還是關于數據權限那些,還是有點不太了解,求指導,18515381173微信,謝謝了!

    來自北京 回復
  12. 我最近也在做通用的權限系統,組織架構那里有些問題,煩請指教,18211426147微信

    回復
  13. 看了之后想應用到實際項目中,但發現會有一些疑問,求指點15210879205微信

    回復
  14. 值得學習 感謝董小姐的分享

    來自廣東 回復
  15. 角色 和部門之前有些疑問,求解答 13735898529

    來自浙江 回復
    1. 已加你

      來自廣東 回復
  16. 13735898529 微信

    來自浙江 回復
  17. 很詳細,很具體,果斷支持

    來自上海 回復
  18. 學習學習,不過不太理解部門和部門負責人在整個權限系統里面起到的作用?

    來自浙江 回復
  19. 嗨,你好,覺得你寫的很詳細,請問有這方面的參考書推薦嗎?

    來自四川 回復
    1. 同求~

      來自浙江 回復
  20. 非常好~謝謝~

    來自浙江 回復
  21. 親,能提供下鏈接地址的登錄名密碼嗎?謝謝!

    來自北京 回復
  22. 學習了,能說說數據庫是怎么設計的嗎

    來自福建 回復
    1. 牛逼了,產品一般不涉及數據庫設計的

      來自廣東 回復
  23. 嗯 最近在學一些權限的東西,感覺很不錯,雖然我還是個菜鳥開發,嘻嘻

    來自湖北 回復
    1. 慢慢來,梳理清楚就好了,加油 ??

      來自廣東 回復
    2. 目前我也在做權限管理,方便加下微信不? 1152481807

      回復
  24. 很棒的設計

    回復
  25. 親,能提供下鏈接地址的登錄名密碼嗎

    回復
    1. 不需要登錄名密碼哦,直接點擊登錄就可以進去

      來自廣東 回復
  26. 正在做B2B平臺的后臺系統,剛好看到這篇文章,讀完感覺真的很棒(尤其是“共享數據”這個功能,給我提供了一個很好的思路以及模塊拓展思路)

    來自北京 回復
    1. 本身這個分享也是給大家提供一個邏輯、思路進行參考,能夠對你有所幫助我也很開心

      來自廣東 回復
    2. 加了QQ沒通過啊

      來自廣東 回復
    3. 都同意了的哦

      來自廣東 回復
  27. 額,為什么我看不到你的回復。。平臺出bug了么,有提示消息但是點進來沒有內容

    來自北京 回復
  28. 917532427 微信

    來自北京 回復
  29. 加個好友唄,同技術轉產品,聊聊

    來自北京 回復
    1. 已加好友

      來自廣東 回復
  30. 到底是什么樣的奇女子才能寫出這樣的設計,很棒,學習了!

    來自廣東 回復