實例分析：後台權限設計

一、基本概念

權限設計大概可以分為查詢權限、操作權限、數據權限。

1. 查詢權限

查詢權限是指針對系統中具體的頁面有訪問的權限。例：整個系統中有三十個頁面，A員工權限只能查看其中的十個頁面。

2. 操作權限

操作權限是指系統中的功能按鈕有具體的操作權限。例:A員工在查看到十個頁面裏，其中一個頁面是商户查詢頁面，但是A不是運營人員，所以只能查詢商户信息，而不能對商户進行新增、修改、刪除等操作權限

3. 數據權限

數據權限是指能夠查看或下載的數據範圍的權限，例：訂單頁面中包含訂單號、時間、狀態成本、毛線、分潤、銷售提成等。不同角色在同一個頁面看到的信息是不同的。財務部門可以查看到全字段的，因為需要進行核算。普通技術人員只能看到訂單號、時間、狀態等基礎信息。

二、角色關係梳理

首先梳理一下新零售系統的層級關係，主要根據業務模式區分為自營商户和入駐商户（即商户A、B和C）。

1. 入駐商户組織架構

根據商户的實際的業務情況，瞭解到在設備鋪設的城市會設置該城市分支機構，城市下區縣會有對應的庫存統一管理，可以統一的調配各自下屬的區域的商品銷量、庫存情況進行統計分析。每個月區域會有對應的區域經理角色，單獨的管理一個區域。每個區域下會有多台設備，每個設備會有對應的維護人員、商品補充人員，每個人員會同時的維護多台設備。所以商户的整體的組織架構的層級下： 商户的總部->城市管理->區縣管理->區域管理->設備管理。

2. 自營商户組織架構

自營商户的組架構與入駐商户的差不多，只是自營商户的層級比較少，少了一個城市的區分，直接下放到地區，比較扁平一些。自營的組織架構如下：自營商户->自營地區->自營區域->自營設備。

3. 整理新零售組織架構圖三、權限模型設計1. 權限模型梳理

根據新零售系統的組織架構，可以得出的結論是每一個層級會有對應的管理人員、運營人員、庫存管理、財務等角色。所以在設計權限管理時，需要考慮每個層級之間屬於單獨的一個組織。高級別的組織可以查看到低級別組織的數據內容，但是低級別組織不允許跨級查看。同時低級別組織可以繼承高級別組織的權限，即高級別組織可以自由分配低級別權限內容。

2. 權限模型3. 權限模型具體內容解釋

（1）上圖中1和N代表的是數量關係，1是代表只能有一個，N是可以無限個。例如一個組織架構下有很多用户，但是一個用户只能擁有一個組織機構，所以組織:用户=1:N，其他也是以此類推即可。

（2）根據RABC權限模型設計，為了更加方便權限的添加與管理，引入了用户組、角色的概念，一個用户可以是單獨某一類角色，也可以加入一個羣組。如果兩者共同存在時，那麼此時該用户的權限則是一個角色 羣組的並集。如下圖所示，一個用户可以同時擁有用户組和角色。

（3）權限集合包含了頁面查詢權限、功能按鈕、數據權限。其中數據權限、功能按鈕是依託於頁面查詢權限，如果單獨配置數據權限或功能按鈕權限，不配置相應的頁面查詢權限，那麼數據權限和功能按鈕權限則無法展示，也就沒有實際用。有些特殊情況可以利用這個方式也處理權限。例如當多個頁面的都有相同功能，這些功能又是放置在同一個權限上，可以通過控制頁面權限而達到控制這部分按鈕的目的。

四、權限獲取流程設計

（1）用户登錄成功後，首先判斷賬號的組織歸屬，獲取改賬號的組織層級，因為在添加組織時管理員賬號是必填選項，並且權限也是必填選項，所以不存在有賬號會沒有組織情況。（PS：公司運營人員也屬於最高級別組織）

（2）獲取用户層級後，判斷該用户在這個層級歸屬的用户組、角色權限，如果沒有對應的用户組與角色，那麼就使用該層級的默認權限。默認權限可配置。

（3）獲得用户的權限後，在進入對應的頁面時獲得對應的操作和數據權限。

五、頁面配置設計1. 組織管理

根據業務模式每個層級相當於是一個新的組織，所以便有組織管理存在。每個層級可以任意的建立下級組織，原則上是沒有層級的上限限制。在總部賬號上，可以查看到每一個賬號的歸屬和所有的交易數據、商户信息等數據，而每個組織只能查看自身數據以及下級分支數據，並不能跨組織進行查詢和操作數據。

2. 功能菜單配置

功能菜單配置包括頁面權限配置、頁面中按鈕權限配置。由於一級菜單不能隨意進行添加，所以這個配置只有二級菜單的配置權限。而一級菜單隻能有通過開發執行sql才能添加進去。

3. 部門配置

（1）根據RABC原則，每個用户可直接關聯角色或權限組。小編根據實際業務場景，將權限組與角色進行關聯。用户直接與權限組關聯，而權限組與角色是具有綁定關係。並且只有特殊的角色查詢時才有限制，例如某個產品線運營，只能查詢下載自身所在產品線的商户交易數據（PS：產品線是通過商户屬性劃分，看各公司規定）。

（2）權限配置

4. 員工配置

（1）員工配置需要關聯到相關的部門才能獲取對應的權限，一個員工可以擁有多個部門，相當於是可以擁有多個部門的權限集合。

（2）每個員工都配置對應的員工級別，分為普通員工和部門經理。這樣分配的原因是，類似於銷售類這種角色，普通銷售只能查看自己的訂單和商户。但是銷售總監級別是查看下屬銷售的權限的。所以如果在同一個部門，屬於部門經理的。在查看數據時，可以查看該部門員工的所有的數據。

5. 數據權限配置

（1）上述所有的配置都是頁面和按鈕的配置，針對數據字段的查看和下載需要單獨的頁面進行配置，在點擊頁面時自動獲取對應的查詢權限的模板，點擊下載時讀取對應的模板進行下載。

（2）默認權限可配置在某個部門下，這樣可避免無特殊要求的部門不需要重複的進行配置，統一讀取默認配置即可。

六、總結

以上講述了系統整體的權限設計的思路，對整體的流程、權限模型、頁面設計做了詳細的梳理，總結歸納如下：

1. 梳理業務中組織架構與相關人員的角色關係，輸出相應的組織架構圖。
2. 根據組織架構圖設計相關的權限模型，模型中將涉及的參數的數量關係梳理清楚，並且在後續的頁面設計中使用。
3. 瞭解RABC權限設計體系，理解用户、用户組、角色與權限的關係。根據業務的實際場景，將RABC權限體系適用於自身業務。

最後感謝大家閲讀完本文，如有寫的不對的地方，請批評指正錯誤，歡迎大家一起來探討。

本文由 @TOM 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。