別人家的SaaS為啥就是好用——權限體系設計實戰分析
本文主要介紹B端產品中權限體系的設計模式,并賦予實際案例展示。
一、權限體系簡介
權限管理是一個幾乎所有大中型B端系統的都會涉及的一個重要組成部分,主要目的是對整個后臺管理系統進行權限的控制,而針對的對象是員工,避免因權限控制缺失或操作不當引發的風險問題,如操作錯誤,數據泄露等問題。
抽象來看權限體系可以分為如下兩類:功能權限與數據權限兩部分:
- 功能權限:指的是在系統中的一系列操作。常見的如:刪除,編輯,提交等
- 數據權限:指數據中存在的數據是否能查看,如:釘釘中個人的出勤數據每人能看到,但是全公司的考勤數據卻只有管理員能看到。
在這里權限的實現一共有兩種模式:
“所見即所得”模式
用最通俗的話來說也就是,能看見相關操作就能執行對應的操作,所有的權限限制就在隱藏對應的操作頁或按鈕上,不進行區分查看與操作。
例如一個項目管理軟件,當用戶擁有了訪問項目操作頁的權限,在本模式里該項目的增刪改查都對應擁有了,這里的核心就是只要能看到就能操作。
這個模式的好處是適合中小型B端客戶,其本身沒有復雜的崗位劃分且要求系統簡單易上手,畢竟一款B端的產品要是權限讓用戶配置半個小時,這對用戶來說是個無比巨大的負擔。
根據我的經驗來看“所見即所得”這種模式基本滿足80%的SaaS系統對權限管理的需求。
“讀寫分離”模式
所謂的讀寫分離,就是在第一種模式上進行了升級(這里的寫泛指一切關于某模塊的操作)。
怎么理解呢?當我們擁有了進入該頁面的權限時,如果沒有分配寫的權限,就算看到了這些操作也不能使用。這種模式多用在數據權限上,而功能權限上是多用于預告給用戶,只有當用戶完成指定條件時才可以去操作。如未完成指定信息填寫時,不能點擊提交,但是提交按鈕必須要在頁面出現。
如果讓我們用一張圖來闡明這兩種權限的設計體系的話,應該是這個樣子的:
圖:權限顆粒度
二、功能權限設計
具體來說我們可以劃分為如下三步:
圖:設計步驟
讓我們一步步來看:
步驟1:功能點封裝
這里就是將我們系統中的功能進行梳理,得出一顆完整的功能樹。你的權限系統想要控制到哪一層級,就將功能拆分到對應的層級即可。
例如:
圖:功能拆分示例
步驟2:權限授予
在拆分完功能點后,我們就相當于有了一個完整的系統權限表(也稱之為權限池),可以清楚的告訴用戶什么環節可以進行配置,接下來我們需要設計的就是如何讓用戶去分配權限,即:權限授予。
在權限授予上我們要滿足如下兩個基本方向的設計:
- 角色概念:角色的理解,我們可以簡單的理解為是一個個權限的集合。它通過提前將一部分權限進行配置成通用模板,隨后只需將需要的人員授予這個角色就能擁有對應的權限。
- 權限池內自定義授予:在SaaS軟件里經常我們會遇到這樣的情況,之前我們配置的某某部門經理或助理的角色由于臨時性工作借調可能會涉及多個崗位的工作,從而導致之前的角色權限不能滿足,而此時這種個例現象又不好再單獨創建角色給他,因此需要能在角色外再單獨指派權限的功能。這里我們就稱之為權限池內自定義授予。當然這里也適用于不在角色表中的任意權限分配。
值得提一句的是:一般的權限系統中要支持一人授予多個角色的功能。
步驟3:權限累加器
想必在步驟2大家肯定有疑問了,一人可以承接多個角色,又可以自定義額外權限,這樣到最后個人權限要怎么定呢?
這里的權限累加器其實就是在解決這個問題,這里相當于是一個單獨權限計算器,通過將前后授予的權限進行累加得到用戶的最終權限。
這里的計算規則如下:
- 計算1:將變動前的權限集合在被授予新權限集合后兩者取并集,去重相同的權限;
- 計算2:最終權限 = 角色權限 + 權限池內自定義授予權限
在一般權限授予中,我們給予權限一般都是越給越多。但是也有可能會是將某一角色的權限進行統一減少,此時我們就需要交由累加器幫我們去批量將多個擁有該角色的權限進行計算。
舉個例來看:
在上面的例子中,我們的權限體系在上面進行了三次變動:
第一次:U298,278兩位用戶獲得了初始員工權限并給予了發布新聞權限,此時由權限累加器幫我們計算出共擁有了7個權限;
第二次:新增了兩位用戶,并將四位用戶在員工角色上又增加了部門助理角色,并額外增加了數據查看權限,此時權限累加器計算出這四位用戶權限數為:
員工角色與部門助理的權限相同權限6項 + 部門助理獨有的4項權限 + 發布新聞權限 + 數據權限 = 12項;
第三次:四位用戶的共有角色部門助理被減去了一個權限,此時權限累加器計算出這四位用戶權限數為11;
三. 兩種實現示例
“所見即所得”模式
讓我們直接進入權限模塊來看。
首先進入系統管理面板:
在進入內部人員管理界面進行權限配置:
這里由于原來系統的業務顆粒度本身不高,因此我只將功能劃分到頁面級,也降低了企業管理員的學習配置成本。在這部分里,用戶只需給每位人員配置擁有什么頁面的訪問權限,就有了對應的功能權限。
舉例來說如果在上頁我勾選擁有了審批配置權限,也就是可以進入審批模板列表頁,因此這里所有的功能都可以使用。
“讀寫分離”模式
這種模式其核心在上文已經介紹過了,就是將每個頁面內還要進行只能查看與能編輯兩種狀態。
具體來看看配置頁的實現:
大家可以看到在這里配置的顆粒度更細,在每個頁面中都進行了進一步劃分,分為查看名稱,進入詳情,刪除三大權限。
而功能頁是這個樣子的:
綜上
對于權限模塊來說,在上面介紹的兩個思路中沒有所謂絕對正確的解決方案。我們應該做的是去選擇最適合自己業務體量的設計模式,避免出現“小馬拉大車”的現象。
PS. 如果喜歡,自愿訂閱,投食,良心不痛!
本文由 @?三爺 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
角色應該和權限拆分開
在企業內部存在角色的概念,如果把角色和權限綁定,會產生問題:比如,企業里面有兩個人事a,b,有三個人事權限A,B,C,經常會遇到a有A權限,b有B,C權限,如果把A,B,C和人事這個角色綁定在一起,就會造成賦權問題,可以嘗試以下辦法:
權限池必須有,在權限池中預設權限組
角色和人員綁定,利用角色進行賦權
功能權限通過以上方式來。
再說操作權限,不外乎增,刪,改,查(以及這幾個封裝在一起的完全控制),這些采用讀寫分離的方式,結合上面的權限池
權限組是什么概念?
權限組是對權限進行一個分類,主要是將模塊操作的權限進行打包在一起
有點意思,經常會遇到a有A權限,b有B,C權限如果是一個問題需要這三個權限才能解決,那豈不是更麻煩了
權限和用戶是分離的啊,如果你需要一個人有A,B,C三個權限,你用角色把人員和權限關聯起來就可以
不錯
哈哈