起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識權限管理平臺的產品設計思路
后臺的權限管理影響到業務的正常運轉，筆者初接觸權限管理，受實際工作情況啟發，對權限管理平臺進行了相應的設計。
權限管理模塊是管理整個公司各個業務系統中最重要的一環，筆者之前尚未接觸此模塊，隨著公司業務系統的繁多復雜，不可能在每個后臺系統做重復的權限模塊。
所以選擇做一個獨立的權限配置平臺，即系統上的系統（此平臺），此平臺完成兩個目標：管理公司組織架構；為整個公司的各業務系統來分配權限。
話不多說，直接上整體設計方案。
一、整體說明
統一權限配置平臺（Unified?Privilege?Configuration Platform，簡稱upcp，以下簡稱此平臺），權限配置是一個極其復雜的問題，也可簡單表述為這樣的邏輯表達式：判斷“who對what(which)進行how的操作”的邏輯。
針對不同的業務子系統，現將目前的“xxx后臺管理系統（后簡稱：后臺管理系統）”命名為“xxx管理系統（后簡稱：業務系統）”，后續在各個業務板塊管理的靈活性、完整性和易維護性之間，將銷管系統（待開發）、指數分析系統（待開發）等都獨立成單獨的子系統，在這些因素權衡后，選擇了此方案。
二、名詞解釋
為了對整個統一權限配置平臺里面涉及到的一些名詞術語有清晰的理解，現將一些關鍵元素做一些說明，如下：
- 用戶（員工）：成功認證并登錄系統的操作員（主體：who）；
- 權限：訪問資源的許可（how）；
- 角色：權限的集合體；
- 業務系統：每個業務板塊獨立的系統，如：業務系統；
- 資源：各個業務系統中的菜單、子菜單、按鈕、字段等（what）。
整個權限配置平臺要素：用戶、角色、權限、業務系統、資源。
用戶與角色是多對多關系，角色與權限是多對多關系。
如圖所示：
三、設計目標
此平臺是對各個業務系統的所有功能和數據進行統一權限配置。
四、賬號管理
此平臺默認一個平臺管理員角色，這個賬號不可刪除，但可以修改（由開發人員創建）。
復制一個平臺管理員的賬號（平臺管理員2），此賬號進行：
- 組織架構的管理與維護（增刪改查）；
- 員工信息的管理與維護（增刪改查）。
平臺管理員2在此平臺創建該部門員工賬號及分配權限。
普通員工不能登錄此平臺，只能登錄對應的業務系統，維護對應的業務板塊的權限。
五、整體規劃地圖
筆者將從以下四個模塊講起當時的設計思路：
1. 組織架構管理：
- 建立部門；
- 部門管理；
- 組織架構樹。
2. 員工管理
- 員工分配部門；
- 賬號管理。
3. 業務系統管理
1）新增業務系統
2）資源管理
3）角色管理
- 新增角色；
- 分配權限；
- 分配員工。
4. 操作日志管理
- 操作日志
- 登錄日志
- 異常日志
5. 大體思路
- 組織機構與員工關聯；
- 新建業務系統管理，維護內部使用業務系統；
- 系統角色與業務系統關聯；
- 角色權限與系統角色關聯；
- 資源權限與角色權限關聯，維護該角色對應的資源列表。
六、產品設計思路
1. 組織架構管理
組織架構管理是對整個集團公司的員工所屬組織進行維護、更新的管理。
組織架構默認“xxx集團”，可編輯，不可刪除，此版塊由平臺管理員2維護。
具體需求如下：
- 對集團總員工有一個數量的統計，數據統計列表包括：組織架構層級、負責人、手機號碼、人數、狀態（正常/停用）、備注及操作。
- 操作包括：新建下級部門、停用、查看、編輯和刪除（最頂層“xxx集團”不可刪除）。
- 新建下級部門：默認當前添加時的組織機構為此時的上級部門，彈窗錄入：上級部門、部門名稱、負責人、手機號碼、部門狀態（正?；蛲Ｓ茫?、備注。
- 停用部門：彈窗提示：“停用該部門如包含下級部門將一并停用，是否繼續？”，一旦停用該部門后，部門下的員工賬號不可登錄任何業務系統，如有賬號登錄業務系統時，toast提示：“該賬號被停用”。
- 刪除：當部門下有員工時，彈框提示：“部門或其下部門已有員工信息，請刪除相關員工在來操作。”；當部門下無員工，只有部門時，彈框提示：“刪除該部門且包含下級部門將一并刪除，是否繼續？”。
組織架構也可生成樹形圖形展示，便于實時對照架構的正確性。
2. 員工管理
員工管理中的員工是對各個業務系統的具體操作者，這些是一個一個的員工個體，員工按組織架構新建/導入在對應的組織上，一般是在機構對應的部門（一級部門–二級部門）下。
管理員工的前提是需要合理的組織架構，只有支持組織架構的靈活配置，才能進一步支持組織內人員的增刪調整，以及禁止登錄、重置密碼和停用控制。
員工可以自己擁有權限信息，可以歸屬于0～n個角色。他的權限集是自身具有的權限、所屬的各角色具有的權限，即：員工權限 = 所屬角色權限合集+員工自身權限，它與權限、角色之間的關系都是n對n的關系。
具體需求如下：員工管理包括組織機構的展示、查詢（員工姓名、狀態、手機號碼）、員工統計、新建員工、導入員工、分配部門、批量刪除。
- 員工統計列表：姓名、手機號碼、所屬部門、職位、狀態、操作（查看、編輯、禁止登錄/允許登錄、重置密碼、停用/恢復）；
- 新建員工：姓名、手機號碼、性別、初始密碼、所屬公司、所屬部門、職位、備注；
- 員工批量刪除：刪除后，某角色下的有此員工信息也自動移除該角色；
- 分配部門：彈窗顯示已有的組織架構，勾選分配該員工到達的部門。
這里需要注意禁止登錄和停用的區別：
- 禁止登錄：在登錄系統時多次輸入密碼錯誤，系統會因為帳號安全問題暫時把禁用掉，或涉及到帳號被盜等場景需立馬禁止，重置密碼等操作。
- 停用：員工離職，但是在職時所有的操作記錄信息還存在，所以設置為停用。（可以跟人事系統打通，人事那邊設置某員工離職后，所有系統賬號自動設為停用）。
在用戶狀態上加狀態控制，可用的用戶就可以登錄系統，禁止登錄、停用的就無法登錄。
3. 業務系統管理
針對不同業務板塊獨立出來的系統進行管理，是比較粗顆粒度的一種管理方式，這種模式下一旦獲得權限，即可對這個業務系統進行操作和全部數據的查看，這種權限開放給部門主管。
具體需求如下：由平臺管理員2對各個業務系統進行統一管理，包括新增業務系統、批量刪除，據列表統計業務系統的名稱、排序、登錄鏈接、編輯、資源管理和角色管理一系列的維護。
- 數據統計列表：業務系統名稱、鏈接、操作（編輯、資源管理、角色管理）。
- 其中批量刪除：如該業務系統下有關聯的資源，toast提示：“該業務系統下關聯資源，請刪除相關資源后來操作。”；如該業務系統下無關聯資源，彈框提示：“是否確定刪除該業務系統？”。
- 員工賬號在登錄業務系統時，判斷員工是否屬于該業務系統的某一角色，如果是，才能登錄操作對應角色下的資源，否則toast提示“您未授權，無法登錄”。
3.1 資源管理
此方案的資源指的各個業務系統下的菜單、子菜單、按鈕、字段等。
具體需求如下：
- 新增資源：平臺管理員2可以對業務系統下的資源進行管理，新增資源時，彈窗錄入：資源名稱（可同時添加同類資源）、資源類型、備注；
- 數據列表統計有：資源名稱、資源類型、排序、編輯、添加下級資源；
- 添加下級資源：彈窗錄入：上級資源（默認當前資源為上級資源，可以修改）、資源名稱、資源類型（菜單/子菜單/按鈕/字段）、備注；
- 批量刪除：對話彈窗提示：“刪除該該且包含下級資源將一并刪除，是否繼續？” 。
3.2 角色管理
角色往往是基于業務需求而預先在此平臺中設定好的標簽（目前默認設置已有的5個角色，詳見《吃豆車生活管理系統角色權限表》），每個角色對應明確的業務系統權限，是一個集合的概念，是眾多最小權限顆粒的組成。通過把權限給這個角色，再把角色給賬號，從而實現賬號的權限，因此它承擔了一個橋梁的作用。
引入角色這個概念，可以幫助我們靈活的擴展，使一個賬號可以具備多種角色。
具體需求如下：
- 新建角色：角色名稱，角色描述、復制角色（選擇當前系統已有角色）、創建人、創建時間；
- 數據統計列表包括：角色名稱、角色描述、創建人、創建時間、修改時間、操作（編輯、刪除、分配權限、重置權限、分配員工）
- 角色的權限設置：對應跳轉到權限分配界面，即資源（菜單/子菜單/按鈕/字段），目前默認已知的5個角色權限；
- 角色分配用戶：添加員工，跳轉到員工管理，勾選選擇員工；移除員工，當前角色下的員工進行移除；
- 刪除：彈窗提示：“刪除該角色后，員工會自動移除，是否繼續？”。
4. 操作日志管理
操作日志管理用于管理此平臺的操作日志，包括有登錄日志、異常日志和操作日志。其中：
- 登錄日志是對用戶登錄操作的記錄，記錄有操作人員、登錄終端型號、操作系統、IP、登錄狀態、操作內容和登錄時間等。
- 異常日志：幫助平臺管理員檢測企業內帳號異常登錄記錄，方便針對有安全隱患的帳號進行安全提升措施。例如：通知員工進行密碼強度提升，跟蹤檢測異常次數較多的設備等，目前異常現象有：密碼錯誤，通過手機號碼密碼方式登錄時，超過3次嘗試登錄失敗，則系統判定為異常登錄，即帳號存在安全隱患。記錄有操作人員、登錄終端型號、操作系統、IP、登錄時間和異?，F象。
- 操作日志是對此平臺相應模塊及其功能操作的記錄，包括操作模塊、操作結果、操作人員、IP、操作時間和操作內容等，其中操作內容記錄的方式為“xx菜單-xx按鈕”，如：員工管理-新增員工。
5. 個人資料
個人資料包括：姓名、手機號碼、修改密碼、所屬公司、所屬部門、職位、所屬角色、備注、賬號狀態、創建人、創建時間、修改時間、上次登錄時間、退出登錄。
以上就是一只產品汪對“權限配置平臺”的設計思路和對應的實現方法，歡迎和同行一起交流產品設計。
作者：蕃茄醬w，公眾號：番茄醬w
本文由 @番茄 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
角色控制功能，架構控制數據查詢范圍。我是這么定位的。不過它的劣勢是，如果要低層級架構人員配置高查詢范圍，只能調整人員的架構。
第四章賬戶管理中提到的平臺管理員，如果存在多個管理員，他們之間的關系是怎樣的，可以互相增刪改查嗎？
唯一一篇理清了人、組織、角色、權限幾方面之間關系的文章。這才是做權限的基石。
思路清晰
文中說是統一權限管理中心，不知道對多個平臺的角色權限是如何規劃的？
通過添加獨立的業務系統，在針對每個業務系統進行資源管理（菜單、子菜單、按鈕、字段）和角色管理，最后分配權限
權限系統的整體思路和框架沒有什么問題，但是涉及數據權限的不知道作者是如何考慮的，不同的角色看到的數據權限范圍是不同的，每個業務系統有自己的數據權限控制要求；如何進行統一管理？
數據我們實現的思路:把每個字段都作為資源來管理和控制，類似于按鈕，做完后感覺還有其他實現辦法，但目前沒找到～～
不知道我說的對不對，我談談我對權限的看法，您上面說將每一個字段都作為資源管理和控制，會不會增加開發人員的開發量，因為真正的企業業務平臺字段太多了，隨隨便便就有上千個字段，如果每個字段都要區分出來工作量太大了；我覺得是不是可以考慮將這些數據權限分配到角色中去，將角色與權限關聯；舉個列子，比如財務這個角色，那我用超級管理員設置出一個財務崗（此設置是一個權限），并且讓這個財務崗僅能在后臺系統里看到付款成功的訂單、審核通過退款的訂單等與財務相關的數據、和財務管理模塊，（這個配置自然是可以隨意配置的，不是前期配置死的）這樣再創建財務角色的時候與其關聯上，這樣同一個訂單管理模塊不同的角色登錄系統就區分了數據權限；其他角色登錄自然也看不到財務管理模塊的數據，不知道我這么說是不是解決了您上面說的數據權限的問題。總之我覺得將數據權限放到權限上是比較合理的，開發的工作量也比放到字段上要小，而且以后系統進行迭代，如果再增加字段怎么辦？還要區分和控制，就比較麻煩了，直接上升到權限去控制數據，應該也會給后續節省資源吧。。。不知道我說的對不對，希望一起交流。
其實我們也沒有全部字段加權限的，只是一些涉及公司商業數據字段這么做的，你提的這個方法，之前我還有考慮，但根據開發實際評估后，沒那么實現
角色是功能權限的集合，組織是數據權限的集合。同一個角色，在總公司和在分公司是不一樣的，總公司可以看所有分公司的數據，但分公司只能看自己公司的數據。同一份數據，不同的角色所能做的操作是不同的，這個通過功能權限進行控制。具體到字段就是功能權限的細分，比如看ABC還是看AC。同時功能權限又有依賴關系，先有查看才能有增刪改。
你說的不錯，數據權限指的不是對哪部分字段的操作權限，而是同一個字段下，不同的賬號看到的數據是不同的
具體到數據權限，可以通過客戶維護劃分數據權限，可以通過狀態維護進行劃分，或者通過組織樹的結構維護進行劃分。再細化下去，建立某一個模塊下的數字權限，然后將這個權限配給某個角色。然后這個角色就被限制只能看所配的數字權限的數據
說得對。數據權限的劃分，實質上也算是功能權限的再細分，把同一功能權限從數據范圍的角度進行細分，分為能查看不同范圍數據權限。這個細分的方式可以通過狀態維護，不同角色權限狀態給予不同的數據權限范圍；或者通過結構，劃分子角色低級角色進行劃分。
最后請教下，你說的通過“客戶維護”劃分數據權限是指什么呢，我沒有理解明白~
你好，前輩，可不可以請你把通過狀態維護再講解一下，我沒有理解，非常感謝~