實例分析:後臺權限設計

2020-12-14 人人都是產品經理

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

一、基本概念

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

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

相關焦點

  • 後臺系統:基於RBAC模型的權限設計
    對於業務複雜或數據龐大的系統,為了方便管理,一定要做權限設計。權限設計是後臺系統要考慮的一個授權策略問題。
  • 如何實現後臺管理系統的權限路由和權限菜單
    本文轉載自【微信公眾號:趣談前端,ID:beautifulFront】經微信公眾號授權轉載,如需轉載與原文作者聯繫前言本文是繼 前端如何一鍵生成多維度數據可視化分析報表 實戰的最後一篇文章, 主要介紹如何實現後臺管理系統的權限路由和權限菜單.
  • 後臺設計小結
    管人的,有對內和對外的兩種類型,對外的CRM(客服管理系統)、對內的考勤系統;管事的,簡而言之,就是人可以做什麼事、可以怎樣去做事,這種最經典的就是數據統計後臺、業務流管理後臺;管物的,主要是指電商類型的商城管理後臺,用於管理商品的交易但是,從本質上看,後臺主要有權限管理、工作流、記錄流三大方面。
  • RBAC模型:權限管理系統設計
    我們不僅有CRM、ERP、OMS、WMS、TMS、OA等系統的Demo研習;    還有各種B端產品垂直的彈藥庫,包含產品說明書、操作手冊、白皮書、業務需求說明書、系統說明書;對於後臺系統來說,權限管理是一個重要的模塊。本文將從理論知識和實際項目經驗相結合,介紹權限管理系統設計邏輯及過程,希望能給大家帶來幫助。
  • 通用權限管理設計【資料庫結構設計】
    分配權限》這兩種應用層面分析,暫時不考慮《授權權限》這種。二,初步分析用戶和角色說到權限管理,首先應該想到,當然要設計一個用戶表這樣就決定了一個人有什麼樣的權限。做著做著就會發現這樣設計太過繁瑣,如果公司裡面所有員工都有這樣的權限呢,每一個人都要配置?那是一件很痛苦的事情。因此再添加一個角色表,把某些人歸為一類,然後再把權限分配給角色。角色屬下的用戶也就擁有了權限。
  • 新人入門:To B 的權限體系設計
    文章從權限模型和概念出發,對權限系統的核心進行剖析,抽象出權限系統中的核心要素,並結合案例對權限系統進行介紹。一個最簡單表達了權限模型的實例小明和小李,分別用自己的帳號和密碼登錄了同一個平臺頁面。小明登陸上去後,可以看到小說和視頻頁面。小李登陸上去之後,只能看到小說頁面。
  • 產品心得|用講故事的方式設計管理後臺
    人:權限管理(包括:角色設置、操作權限、數據權限)人的管理和設計,主要解決這一問題:事件對誰觸發?業務流程圖是整個項目的核心,最後將成為整個項目的標杆文件,物流是產品設計或技術框架都會以此為主要參考,所以梳理清晰業務流程對設計後臺管理系統非常重要。當用戶在前端觸發某一操作到期望看到的結果之間,會存在很多工作在後臺完成,這裡所指的後臺通常來講就是管理系統。以貨運行業為例:
  • MySQL數據克隆的用戶權限設計
    到了交付的時機了,我們想到還有一個關鍵的地方需要補充,那就是資料庫和用戶的權限關聯,也就意味著每個人可以看到和使用的資料庫應該是不大一樣的,因為做一些權限隔離,所以接下來我會說說數據克隆方向的用戶權限設計。
  • 面試題:如何設計一個權限系統?
    頁面權限:即用戶登錄系統可以看到的頁面,由菜單來控制,菜單包括一級菜單和二級菜單,只要用戶有一級和二級菜單的權限,那麼用戶就可以訪問頁面操作權限: 即頁面的功能按鈕,包括查看、新增、修改、刪除、審核等,用戶點擊刪除按鈕時,後臺會校驗用戶角色下的所有權限是否包含該刪除權限,如果是,就可以進行下一步操作,反之提示無權限。
  • 後臺系統設計:工作流設計剖析
    一般在稍微複雜一些的後臺系統中,工作流的設計是不可避免的一個重要部分。設計好一個後臺工作流,不僅可以使得後期使用系統的時候更加高效,同時也是十分考驗產品經理的。剛好最近自己在做這方面的工作,所以總結了一些方法經驗與大家共勉。
  • 後臺系統:產品設計「七步法」
    1.了解後臺在做後臺產品設計之前,我們先從硬幣的三個面了解一下後臺系統。從硬幣正面看後臺:可以減輕運營的壓力,注重數據之間的流轉,側重功能模塊的實現。從硬幣反面看後臺:設計風格過於單一,業務邏輯複雜,缺少對應的系統說明。從硬幣側面看後臺:數據處理準確有效,操作流程簡單,系統簡單好用。
  • 圖書管理系統中UML圖分析與設計
    圖書管理系統中UML圖分析與設計 UML統一建模語言相信大家有所了解,它是如何使用的呢,這裡通過基於B/S模式的圖書管理系統中UML圖的分析與設計這個實例來向大家介紹一下,歡迎大家一起來學習。
  • 每天一手黑客技巧《網站後臺報錯注入-SA權限》
    技巧一:通過禁用網站js進行越權訪問技巧二:通過分析網頁原始碼尋找利用點<前端驗證驗證碼.網站跳轉地址等>網站後臺是一個網站的靈魂,在很多人想進一步獲取網站的更高權限的時候,都需要先找到後臺,然後才能有下一步的操作,所以一個一個網站的後臺藏的深不深也是自身安全建設的一個重要環節
  • B端產品設計:用戶角色權限系統設置
    本文首先對B端產品的用戶與需求進行了解析,進而利用RBAC模型做了權限劃分,並做了詳細的案例分析。詳細案例設計3.1 公司管理一個B端的用戶角色權限系統大致可以包含:公司管理、部門管理、角色管理、用戶管理。
  • 後臺產品:欄位設計
    這篇文章將通過「匯總欄位」、「處理欄位」、「設計欄位」這三個方面來詳細闡述如何進行欄位設計。讓你之後在面對後臺產品繁多的欄位時,遊刃有餘!後臺產品和前臺產品的一個很大的不同,在於後臺產品的欄位信息會比較多。如何合理地設計這些欄位,成為後臺產品設計的一個重要工作。
  • Web經典B/S快速開發框架,強大後臺+簡潔UI一體化開發工具
    本框架旨在為.NET開發人員提供一個Web後臺快速開發框架,採用本框架,能夠極大的提高項目開發效率。4.強大的權限管理組件,完成業務功能開發後,系統可以直接使用通用權限來管理業務功能的操作權限及數據權限。5.集成工作流引擎組件,使業務流程靈活可控。6.集 BS 開發、微信組件、APP 開發組件於一體。
  • HDINTRA在企業人力資源管理中的應用實例分析
    一、考勤管理  對公司人員的考勤是每個公司都不可或缺的部分。下面這個實例,使用系統對考勤過程中瓶頸的部分進行分析處理。   下面看一下我們的設計思路。  【設計方案】   如果我們能夠把人力採集,計算的過程,由系統代替人力採集,系統代替人力計算,那麼,那麼就會大大減少由於人工進行手工統計,操作導致的效率低下,錯誤率高等問題對該管理流程的影響。
  • 2B產品的用戶權限管理問題與RBAC模型
    ToB產品的用戶角色問題》中,我們討論了 2B產品的用戶角色設計 問題,著重探討了在整個系統中,用戶和角色的關係,並基於業務過程對角色進行了場景的細分,並詳細的解釋了為什麼要在做產品原型設計之前分析業務角色,設計各個角色的關係。本文則討論如何基於用戶角色進行權限管理。
  • OA工作流之表單和報表的設計與應用實例
    在上一篇文章「OA工作流之圖形化流程設計和條件跳轉實例」,我們了解了OA工作流的流程設計特點,本文將繼續在華天動力OA系統的試用版本中進行實例演示,介紹一下表單和報表在工作流中的應用。  一、什麼是表單?什麼是報表?  表單用來顯示查詢或輸入的數據。
  • 架構設計:企業總體架構要如何做?小白也能快速領悟的設計思想
    ,角色設計,資源權限設計。2.3、資源權限設計資源權限設計對於所有後臺系統來說,是一個最重要的部分,主要是針對不同人可以訪問不同的資源權限,接口權限,數據權限等,這些權限的控制上的缺少或者操作問題引發的風險,是非常巨大的,最直接的後果就是導致數據串聯了從而隱私數據洩漏。