從產品經理視角談用戶權限
只要在系統中存在多個用戶,必然會涉及到用戶權限的處理問題。這篇文章,作者總結了用戶權限的相關問題,包括定義、搭建和自己的思考,供各位參考。
前幾天與一位產品朋友閑聊的時候有聊到某項目的用戶權限應該如何設計的話題,當時在我腦海中閃過了許多解決方案,但是我卻不知道如何有邏輯性的進行表達,于是我意識到是該總結輸出的時候了……
一、什么是用戶權限
用戶權限是所有應用系統最底層的邏輯,只要系統中存在多用戶,那么就必然會涉及到用戶權限的概念。用戶權限是集模塊權限、功能權限、數據權限為一體的統稱。
下面以一個ERP系統的部分場景為例來解釋說明什么是用戶權限,例如在一個ERP應用系統中包含了銷售、采購、財務等功能。
模塊權限
模塊權限也叫菜單權限或應用權限,即決定一個用戶在應用系統中可以使用哪些模塊菜單。
在示例中,公司的銷售人員就只能查看與銷售相關的業務模塊,而不應該能看到財務相關的功能模塊。因此我們可以通過配置模塊權限來實現不同用戶的模塊隔離。
功能權限
功能權限也叫按鈕權限,即決定一個用戶在一個業務模塊中可以使用哪些功能按鈕。
在示例中,普通銷售人員在銷售訂單管理模塊中只能有新增訂單、編輯訂單、刪除訂單、申請優惠等功能,而銷售總監除了有這些功能外,還會多一些審批優惠、查看銷售報表等功能。因此我們可以通過配置功能權限來實現不同用戶在同一個業務模塊中的功能按鈕不同。
數據權限
數據權限可以細拆為查看數據權限和管理數據權限。
查看數據權限,即決定一個用戶在模塊中可以查看哪些數據記錄。在示例中,普通銷售人員在銷售訂單管理模塊中只能查看自己創建的銷售訂單,而銷售總監則可以查看整個銷售部門的銷售訂單記錄。因此我們可以通過配置查看數據權限來實現不同用戶在同一個業務模塊中的數據隔離。
管理數據權限,即決定一個用戶在可以查看的數據基礎之上允許對哪些數據進行操作。在示例中,所有采購人員在采購訂單管理模塊中都可以查看所有的采購訂單,但是采購人員A只能對自己創建的采購訂單進行編輯、刪除等操作,不能對其他采購人員的訂單進行操作。因此我們可以通過配置管理數據權限來實現不同用戶在同一個業務模塊中查看同樣數據的情況下,可操作的數據不同。
用戶權限的核心就是在一個應用系統中控制哪些用戶能查看哪些模塊的哪些數據以及可以對哪些數據做哪些操作。
這句話看上去可能比較繞,但帶入實際業務流程就會很好理解了。
二、為什么要設置用戶權限
在實際業務場景中,每個用戶都是有自己的部門和崗位,所以設置用戶權限的第一個目的就是職責分明。不同部門不同崗位的用戶在應用系統中都需要有各自對應匹配的功能流程,這不僅可以簡化用戶操作和提升用戶體驗,還避免因功能模塊繁雜造成用戶的困擾與混淆。
其次是為了數據安全保障。各類數據都有著不同的敏感性,例如公司的所有客戶信息、供應商信息、財務信息等一旦被泄露均可能產生嚴重后果。通過設置用戶權限就能將不同的數據信息分別授權給部分指定人員,這樣就有效防止了數據被泄露的風險。
另外還可以用于做個性化體驗等操作,例如在SaaS版系統中可以利用后臺運營系統的用戶權限給部分用戶開放灰度測試功能或給指定用戶開放指定功能,以便于滿足不同用戶的多樣化業務需求。
三、如何搭建用戶權限
搭建一個好的用戶權限體系就像修房子搭建一個穩定的地基一樣。因此在設計用戶權限體系時需要盡可能設置的通用一些,這樣才有利于后續的系統建設以及響應需求變更。
我把之前負責和參與過的所有產品和項目綜合整理出了一個通用的用戶權限配置模型,如下圖所示。
模塊權限常用的搭建規則為
?通常情況下,一個功能頁面就是一個菜單配置項,然后可以根據實際的業務場景來決定是否配置二級或三級菜單等。
查看數據權限常用的搭建規則有以下幾點(可根據實際業務情況選擇)
?我創建的:僅能查看自己創建的數據。
?我參與的:僅能查看與自己有關聯的數據,如自己創建的、業務數據審批人或抄送人是自己的。
?本級部門創建的:僅能查看自己所在部門本級所有人員創建的數據。
?本級及上級部門創建的:僅能查看自己所在部門本級及上級所有人員創建的數據。
?本級及下級部門創建的:僅能查看自己所在部門本級及下級所有人員創建的數據。
?全部:可以查看該模塊的所有數據。
管理數據權限常用的搭建規則有以下幾點(可根據實際業務情況選擇)
?我創建的:僅可以操作自己創建的數據。
?我可見的:僅可以操作與自己有關聯的數據,如自己創建的、業務數據審批人或抄送人是自己的。
?我可見的:所有能查看的數據都可以操作。
功能權限常用的搭建規則為
?按照模塊中的功能操作按鈕列舉,越詳細越好。
有些多應用型的系統則可以在模塊菜單的前面再套一層應用權限配置,如下圖。
在實際項目開發過程中,用戶權限也不一定全部都需要做成可配置項,可根據項目的實際情況將上述搭建規則的部分權限直接在代碼里寫死控制,只不過這么干的后果就是當后期有關于權限的需求變動時,需要由程序員修改代碼并發版之后才能生效。
四、補充說明與總結
在實際業務中,用戶角色與用戶通常是多對多的情況,即一個角色下存在多個用戶,而一個用戶也可能擁有多個角色。所以為了方便在系統中管理,我們可以設置“角色組”的概念。即將多個用戶角色打包為一個角色分組,并將這個分組賦予用戶,這樣一個用戶就同時擁有了這個角色組下的多個角色的權限。但是當一個用戶同時擁有多個角色權限時,又會出現另外一個問題是這位用戶在系統中最終的權限是什么呢?這個問題通常的解決方案有2種,一種是多個角色的權限取并集;另一種是讓用戶手動選擇自己的當前角色。具體采用哪種解決方案可根據實際業務場景來決定。
關于數據權限還有一個常見的問題是當一位用戶從A部門轉移到B部門之后,那這位用戶之前在A部門產生的數據是保留在A部門還是跟隨用戶轉移到B部門呢?這個問題需要在做權限設計時提前考慮到,但具體如何處理也是需要根據實際業務場景來決定。
用戶權限是應用系統的基礎,沒有絕對完美的建設方案,每個應用系統都需要結合實際業務場景和實際項目情況來搭建出最合適的用戶權限體系。
本文由 @易小勇 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
小勇開始價值輸出了 以前在慧貿天下待過?
權限是為了安全開展業務,而業務是靈活多變的,權限最核心的問題是安全與便捷的有機結合
軟件可獲得的用戶數據特別完全,但保密性十分重要。