實例分析:后臺權限設計

LQM
14 評論 26903 瀏覽 299 收藏 12 分鐘

本文從權限設計的概念和基礎角色關系出發,結合案例為我們介紹了權限設計模型、流程和頁面配置,與大家分享。

一、基本概念

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

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協議。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 前面梳理權限模型時說一個用戶只能擁有一個組織架構,但下面員工配置的時候又寫一個用戶可以在多個部門??

    來自廣東 回復
    1. 有沒有可能是擁有是指部門管理者,而在多個部門是有些用戶有多種身份

      來自福建 回復
  2. 您好,請問可以再詳細解釋一些數據權限那塊的設計嗎?怎么樣去獲取對應的數據字段的權限呢,把對應的模板下載下來是做什么用的呢?這塊有點不太明白,而且數據權限的設計不止是數據字段的權限設計,還有相同字段不同權限范圍的設計,比如字段相同但是只能看自己錄入的數據不能看別人錄入的數據。請問這種要怎么處理呢?

    來自陜西 回復
    1. 1、權限獲取是和用戶賬戶關聯綁定的,在配置字段權限時候就關聯了部門,而部門里面是有內部具體賬號信息。
      2、模板下載功能的作用是為了本地存儲,方便文件傳輸和篩選查看。通過excel可以直接看出配置了哪幾個部門權限。
      3、對于自己只能查看自己錄入的數據,這種就是不屬于數據字段權限了,是查詢權限了,查詢時候只能查看自己的數據,例如銷售的商戶查詢,只能查看銷售自己拓展的商戶。這種可以和角色關聯。特殊的角色只能查看自己的數據。

      來自廣東 回復
  3. 請問字段權限要如何管理呢

    來自廣東 回復
    1. 字段權限可以分為通用字段權限和特殊的,通用就是公共不涉及敏感信息,大部分有頁面查詢權限都可以看到,特殊單獨配置對應人員(或部門)就可以,這些可以減少配置的次數。

      來自廣東 回復
    2. 謝謝

      來自廣東 回復
  4. 權限設計、用戶組設計是在設計產品最開始要考慮的,還是產品設計完成后再配置?

    來自內蒙古 回復
    1. 這個是要在搭建整個平臺時候需要考慮的,需要分析用戶的權限分組。在做具體功能設計時候是清晰知道提供哪個級別的權限使用。

      來自廣東 回復
  5. 是用戶組,還是角色組 ?

    來自廣東 回復
    1. 是用戶組,用戶組與角色可以關聯, 用戶還可以單獨額外的賦予權限

      來自廣東 回復
  6. 您好,好像是RBAC(Role-Based Access Control)。

    來自四川 回復
    1. 是的,這個寫錯了,感謝指出錯誤

      來自廣東 回復
  7. 學習了,感謝分享

    來自廣東 回復