上一篇給大家介紹了“功能權限”設計，本篇主要介紹“數據權限”設計，做B端用戶中心近半年，從一頭霧水到產品上線，總結出來一些經驗，希望能夠給到大家一些幫助。
“功能權限”控制的是用戶登錄系統後能看到哪些模塊，操作哪些按鈕；而“數據權限”控制的是用戶能夠看到的數據範圍。所謂數據範圍，不是指能看到的數據字段，而是指能查出來的數據集合。
例如，針對訂單管理列表頁，數據範圍可能是某個城市的全部訂單，也可能是某個門店的全部訂單，“某個城市”和“某個門店”決定了2種不同的數據範圍。
針對數據權限，常見的實現方案有兩種：通過組織機構樹實現，或者是通過數據共享配置實現。下面，我們通過具體案例來講解這兩種方案。
方案一：通過組織機構樹實現
這種方案是根據用戶所在組織機構樹中的節點位置，來判斷用戶能夠操作的數據範圍，利用組織機構樹默認的上下級關係，支撐數據權限的配置。
該方案配置簡單，是常見的數據權限解決方案，通過下面的2個案例來為大家作具體闡述。
案例一：如何配置系統中各角色的數據權限
門店管理系統是用來幫助老闆管理門店日常庫存、銷售、會員、促銷、營銷數據報表的一類軟件。
在一個門店管理系統中，我們設定組織機構為：總公司-省級分部-縣市級分部-門店4級架構；並創建好“默認管理員”“默認普通用戶”“默認經理用戶”三個角色；數據權限範圍分為：本人、本人及下屬、本部門、本部門及下級部門、全部。
圖1
如圖1所示，不同角色，可以根據實際需要，設置所需的數據權限範圍。
如“默認管理員”可配置“全部”數據權限，監管整個公司的數據；“默認普通用戶”可配置“本人”數據權限，僅操作自己創建的數據；“默認經理用戶”可配置“本部門及下級部門”數據權限，操作本部門及下級部門員工創建的數據……
建議：
- 數據權限的配置，可以根據操作系統用戶量的多少來決定，給賬號還是給角色配置數據權限。如果操作系統的用戶少的話，可以直接給賬號配置數據權限，更靈活。
- 數據權限的範圍也不完全為“本人、本人及下屬、本部門、本部門及下級部門、全部”這5種範圍，可以根據實際業務需求調整。
案例二：通過組織機構圖來詳細闡述某個賬號的數據權限
圖2
如圖2所示，在一個門店管理系統中，自上而下設立了5級組織機構，各機構下分別開設賬號登錄系統。
“賬號1”是公司管理員角色，處於根節點的位置，且數據權限範圍是“全部”部門（即所有節點）。因此，在訂單管理等功能中，“賬號1”可以查看總公司及其所有子部門的訂單信息。
“賬號 2”是山東分公司管理員角色，是“山東分公司”的根賬號，且數據權限是“本部門及下級部門”(當前節點及其子節點，即山東分公司及其下屬全部部門)。因此，在訂單管理等功能中，“賬號 2”可以操作山東分公司及其下屬部門的全部訂單信息。
“賬號5”是營業部負責人角色，是末級節點“營業部1”的根賬號，且數據權限是“本部門”（當前節點，即營業部1）。因此，在訂單管理等功能中，“賬號5”可以操作營業部1的所有訂單信息，對於上級部門“市南分部”的數據卻沒有權限查看。
根據不同賬號的不同數據權限配置，賬號的數據可見範圍也不同。依託組織結構的上下級關係，可以迅速配置賬號數據權限，滿足業務需求。
方案二：通過數據共享配置實現
以賬號間的數據共享為例，通過配置某個賬號的什麼數據共享給某個賬號，來解決賬號的數據可見範圍，默認每個賬號僅可操作自己創建的數據。
該方案比較靈活，可以單獨設置某個賬號每一項功能的數據共享給他人，但是配置起來很麻煩，後期維護也不易，通過案例三，我們來詳細闡述。
案例三：
圖3
如圖3所示，通過數據共享規則，將“賬號5”下“銷售信息管理”模塊的全部銷售信息的“只讀”權限，賦予“賬號6”，這樣“賬號6”登錄系統後，就能查詢到“賬號5”創建的銷售信息，擴大了數據範圍。
通過數據共享配置實現的數據權限，數據源可以來自某個賬號、某個角色、甚至某個部門等，數據權限也可以共享至某個賬號、某個角色或者某個部門，可以根據自身業務情況靈活設置。由於配置起來較麻煩，適合對數據權限有嚴格把控的業務場景，對於絕大部分公司，通過組織機構樹的方式實現數據權限的配置，就足夠了。
結語
數據權限一上線，B端功能模塊在設計的過程中，就必須要考慮到數據權限的應用場景，如該模塊的數據是否需要劃分數據權限？數據是默認歸屬於個人還是部門？如果有人員離職，是否涉及數據轉移給他人等。
總之，在權限設計過程中，多思考多嘗試，總會總結出一些規則，讓我們在後期少走彎路。
本文由 @菡子同學 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。
閱讀更多 人人都是產品經理 的文章
