電商行業中,後台會有客服、采購、财務等不同的角色,對應展示不同權限、界面數據。在設計B端後台權限模塊時,簡單的用權限勾選即可,然而複雜的需要涉及到多角色、多權限相互匹配的場景中,則需要引入一個概念——RBAC權限模型。本文作者對RBAC權限模型進行了介紹,一起來看一下吧。
這是一篇實戰經驗 概念解釋文章。
想法來自近期在進行一個後台産品中,涉及到權限管理的設計,需要設計多種角色、并需要對應不同級别,需要區分不同權限的設計,說半天,上個圖!
大概意思就是在D的角色下會有A、B、C這3人,而C又包含角色A、B的權限,角色A、B下方又有A-1、B-1等人;而D擁有最大權限,對應下分不同角色配對不同權限,而下一級又是不同權限!于是一層層套娃開始了!
做過電商行業的應該都知道,在後台會有客服、采購、财務等不同的角色,對應展示不同權限、界面數據。
這就要求設計師在設計時,就要從業務角度上,去對每個角色進行代入、根據實際業務理解後進行設計。
通常在設計B端後台權限模塊時,需要先厘清角色與權限之前的關系,比如對子賬号進行角色管理、權限分配等場景進行分類,如果簡單一點的模式設計就很好處理,用權限勾選即可,但複雜一點的就需要涉及到多角色、多權限相互匹配的場景中,簡單權限勾選就不足以支撐起權限模塊了。
因此,在B端後台界面設計中,就需要引入一個概念:RBAC權限模型,現今權限設置幾乎都是在RBAC模型上進行擴展的,本文下面将會對RBAC權限模型進行簡略介紹。
一、RBAC模型定義
那說起RBAC權限模型,那我們來看下它在“維基”上的定義:
可以看到:RBAC是Role-Based Access Control的英文縮寫,意思就是以【角色】為基礎進行【權限】的【控制】。
換句話說:就是劃定【權限】範圍,賦予【角色】,再将【角色】賦予【賬戶】,這樣【賬戶】擁有了權限,權限邊界會很清晰,而去命定賬戶權限時隻要去管理角色即可。
還是不懂?看圖
更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!