權限管理(權限管理在哪里打開)

本篇文章中，作者介紹了面向后臺系統設計的用戶管理三大模塊。一個清晰的用戶管理系統，可以增強用戶在使用系統中的連貫性以及業務的穩定性，權限的清晰設定可以增強系統的安全性，減輕迭代的壓力，并減少權限的冗雜和浪費。一起來看看用戶管理模塊應該如何進行產品設計吧。

登陸模塊是用戶接觸系統的第一觸點，尤其是對于C端業務而言若注冊流程過程過于冗雜，很容易會造成用戶的流失；而對于B端業務來說，注冊流程可以是第一步也可以適當忽略，具體需要根據公司內部系統之間的連貫性進行判斷，忽略的情況下可以采取直接拉取已驗證的賬號進行登陸操作，以此基礎減少時間的浪費。

01 注冊、登陸模塊

登陸系統可以分為注冊登陸、拉取第三方驗證兩種登陸方式：

拉取第三方驗證登陸：登陸無需賬戶，但需要在第三方或賬戶管理處有識別賬戶的統一驗證標識比如微軟提供的郵箱后綴驗證服務，首次登陸時需要在系統后臺中找到該用戶，并給予用戶可訪問或其他權限，此時數據庫中應存儲用戶標識信息與權限便于新增權限和記錄用戶操作記錄。注冊登陸：用戶首次注冊登陸時需填寫必要信息，此時需要根據業務需求從而判斷需要郵箱、手機號等第三方綁定賬戶。一般情況下是可以通過手機號、微信號、QQ號等直接注冊的。

注冊流程圖：

登陸模塊：登錄與注冊是一個連貫的過程，所以在連接過程中需要做到邏輯流暢便于操作自動跳轉等。

登錄流程圖：

02 用戶管理（角色、賬戶和權限）模塊

后臺產品的用戶權限管理系統可以大致分為三個模塊：賬戶、角色和權限管理；

賬戶被賦予角色，角色被配置權限，一個賬戶可以被賦予多種角色，一個角色只能有其對應的權限限制；以此達到拒絕耦合信息冗雜的情況。

1、角色管理

角色是指擁有同一種身份性質的某一類人群的歸納，但角色需要具有繼承和約束關系，以此來表明角色有上下級的區別。

在這個模塊中，我們需要根據業務來定義出不同的角色名稱以及定義相應的角色信息。在業務允許的情況下，盡量不需要將角色設置過多，若存在著角色過多的情況也一定要與角色賦予的權限理清楚。比如：

繼承&約束關系

角色需要滿足繼承關系以此表明角色的上下級關系，此部分可以參考決策樹根葉子節點來區分角色的父子關系。角色需要滿足存在著約束關系，以此來表明角色之間的不同點對應角色下設的權限和業務的不同。先決條件角色：此情況考慮的是系統龐大時，用戶在新增一個較高影響范圍的角色和權限是否需要滿足該角色下的子角色；互斥角色：一個用戶只能分配互斥角色組的一種，例如市場專員 、運營人員 、系統管理可以設置為互斥組，一個用戶只能歸屬為其中一組；設置互斥組是處于對系統和業務安全性的考量，比如一個用戶的角色是系統管理員的角色若賦予運營角色的權限在誤點擊的情況下就有可能會影響線上業務。但具體的互斥角色和對應的權限設置需要根據業務的實際情況設定。運行時互斥：一個用戶可以擁有多個角色，但在實際業務操作運行中不可同時激活這兩個角色以此達成動態職責分離。

角色列表頁

角色列表頁更便于系統管理員進行角色和用戶的對應核驗，對角色能進行增刪改查基礎功能外，也可以根據業務實際情況考慮是否新增自定義角色功能等，以此考慮系統的拓展性。列表頁 = 展示頁 + 一些必要操作的入口；在列表頁中可以將主要的信息展示出來比如角色ID、角色名稱、權限、創建時間以及操作等；當基本權限和操作權限較多時可以僅展示一部分，剩余部分可以采用【光標移動到此字段時進行全部展示or在操作字段下多加一個查看操作進行詳情頁的形式】

如下圖：

新增角色頁

“新增角色”和“編輯角色”都是給角色賦予相應的定義，但編輯角色需要考慮目前角色的使用情況，在已有的系統使用中是否已經存在并運行，當修改時是否會影響線上系統。賦予新增角色的權限是站在長期價值上考慮系統的可拓展性，在不斷迭代的業務中新增業務模塊和權限時無需接入新的開發，但同時更需要在一開始就做好相關的定義與新增的規則，所以在最初搭建時期不建議提供新增角色的功能。當角色的權限較少時可以采用【下拉框】的形式來選擇，當權限較多時可以采用【權限羅列】的形式。2、權限管理

權限管理部分是邏輯性最強且對于系統全貌影響來說最為廣大的，需要提前將角色和對應的權限進行匹配，將權限的名稱、描述、性質（基本/操作）等信息梳理清楚，此處需要注意自身是無法給與自身權限的，雖然在一定情況下會造成操作的麻煩但極大的程度上減少了不安全性。

相關權限模型可以參考RBAC：基于角色的訪問控制

RBAC定義：當一個操作，同時滿足a與b時，允許操作：a.規定角色可以對哪些資源進行哪些操作 ；b.規定主體擁有哪些角色RBAC的思想，來源于現實世界的企業結構。

權限列表頁

一個好的權限系統需要能夠滿足可拓展、高效易維護、層次分層并且可追溯。

在做權限梳理之前與業務和開發同學達成一致，確定哪些權限是同類型的、可同組聚合，而哪些業務或功能的權限是必須分開設定的。【權限性質】部分是根據業務情況實際設置的需要規定好角色與【查看】、【操作】等權限的設置，在邏輯整體上需滿足角色于權限的對應，從而實現不同角色對應的業務頁面查看、編輯、刪除等功能的不同操作，甚至同個頁面的某些元素的查看、編輯、刪除等功能根據角色與權限的對應關系可單獨設定。權限設定也可以考慮父子關系3、賬戶管理

此功能模塊與注冊賬戶的功能模塊息息相關。賬號管理，是將用戶與角色對應起來的模塊，一個用戶對應一個賬戶，一個賬戶可以對應不同的角色，不同的角色被賦予不同的權限就可以達到了【一個賬戶對應多種權限】賬戶管理。這一模塊，需要設置相應字段，對內部人員的信息進行管理，也是管理員最常用到的功能。

賬戶列表頁

列表頁 = 展示頁+一些必要操作的入口，列表頁的主要作用是可以讓用戶清晰的查詢到必要信息，比如用戶ID、用戶名、部門、角色、賬號狀態、注冊時間以及操作（操作中首先應該具備“編輯”、“刪除”基礎的操作功能）；另一方面，某些賬戶可能存在凍結的情況（此情景狀態在用戶管理賬戶層級較少但某些業務場景中較為常見），基于此種情況需要新增增加“凍結”和“啟用”的功能。除此之外，便于后續的數據分析和操作記錄可以前端做一些簡單的數據埋點，比如最近登錄時間、登錄次數等。

新增賬戶頁面

當點擊“新增賬戶”按鈕時，當前頁面可以跳轉到填寫賬號信息的頁面，【新增賬號】頁面的字段要盡可能的羅列出賬戶所需的信息并且要確定此賬戶的所對應的角色。由于角色本身是帶有權限性質的，所以不需要匹配權限。如下圖：總結

以上介紹的用戶管理三大模塊是主要面向后臺系統設計的，用戶也是企業內部人員。一個清晰的用戶管理系統可以增強用戶在使用系統中的連貫性以及業務的穩定性，權限的清晰設定可以增強系統的安全性，過于繁多的角色和權限不僅會增加迭代的壓力也會存在權限的冗雜和浪費。所以在產品設計的開始一定要遵循MVP原則，小步快走。

本文由 @一個七月 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。