後台系統的許可權設計

許可權設計通常隱藏於後台系統深處，以至於我們說起來都知道，但是在真正面對複雜的業務需求和邏輯關係，又有些抓瞎。

這篇文章是我對之前許可權設計的一次復盤，希望在自己重新梳理的同時，也能給其他小夥伴帶來一點想法。

許可權系統設計的需求背景

業務流程複雜化：

隨著業務越來越複雜，之前一個訂單只需要一名銷售跟進，現在卻需要五個銷售協同完成一個訂單的流程（每個銷售負責其中一個流程）。

此時我們就可以通過許可權系統，分別賦予五個銷售處理各自流程的許可權（比如銷售A只有錄入意向訂單的許可權，銷售B只有補充客戶信息的許可權，等等），這樣每個銷售都只能看到流轉至自己手上的信息，將複雜的流程簡單化。

信息敏感：

當同級部門不止一個時，便會在同一公司內產生競爭關係。例如，銷售1組辛苦挖掘的用戶數據並不想被銷售2組看到。

許可權系統可以設置不同部門的數據彼此獨立，即便是各組組長也無法互看對方數據。

操作安全，權責明確：

在一個大型系統中，一個誤操作產生的後果可能是非常嚴重的。

許可權系統的存在最大程度上避免了這類問題——只要是界面上出現的功能，都是可以操作或不會產生嚴重後果的。

頁面簡潔：

如果系統沒有進行許可權管理，那麼每個帳號登錄後看到的界面都是一樣的，充斥著各種與自己無關的，冗餘的信息，甚至還需要專門培訓，花費巨大的成本去學習。

經過許可權系統的管理，每個帳號登陸後只能看到和自己有關的信息，可以更快速地理解自己工作範圍內的業務。

許可權系統的基本構成

許可權系統主要由三個要素構成：帳號，角色（實質就是許可權組），許可權。

帳號是登錄系統的唯一身份識別，一個賬號代表一個用戶。由自己註冊或系統管理員統一註冊分配。

角色實質為許可權組，為賬號批量分配許可權。在一個系統中，不可能為每個帳號訂製許可權，所以給同一類帳號賦予一個「角色」，以達到批量分配許可權的目的。

許可權又分為操作許可權，頁面許可權和數據許可權。

其中操作許可權指的是用戶可以進行的操作，例如是否可以新增、刪除、編輯等。頁面許可權指的是可以看到的頁面。數據許可權指的是可以查看數據的範圍。

簡單範例如下：

許可權系統設計實例

實例背景

這是一個訂單管理系統，銷售、客服等角色通過系統完成整個訂單的流轉。

系統使用人數眾多，等級複雜，有大量的銷售團隊存在同級競爭關係。

帳號管理

當前案例創建帳號的流程為：管理員在系統中新增帳號，用戶自行通過郵箱激活。默認角色為「職員」，只分配最基礎許可權。

為了減少管理員的工作量，同時也支持通過excel上傳，可以按照模版規範excel格式。

角色管理

當前案例中的角色就是「職位」，不同「職位」的用戶，有著不同的許可權。

角色管理的入口在「許可權管理」頁面，只具有基本的新增角色，編輯角色，刪除角色，以及添加角色描述。

通常主流後台系統還會有複製角色等功能，複製角色是指：在新創建一個角色的時候，先選擇一個已有的許可權相似的角色，然後再修改新角色的許可權。這樣避免了許可權太多的情況下，每個新角色都必須重新設置的繁瑣情況。

許可權管理

在實際設計中，很多系統會選擇將頁面許可權與操作許可權合併為功能許可權，比如當前案例：

每一個頁面有一個總開關，打開則意味著分配了頁面許可權。針對頁面內所有的欄位，有增刪查改這四種主要的操作許可權。如果對頁面內某些敏感欄位需要進行單獨的操作許可權設置，可以打開高級設置，進行欄位級的操作許可權配置。如下圖：

在當前案例中，在有多個小組同級競爭的情況下，僅僅通過職位無法滿足數據許可權分配的需求，所以我們引入「部門」，以保證在同一級別的銷售小組中，彼此信息保密，公平競爭。

另外，更高級別的部門，例如城市經理，甚至總經理，是理應有許可權看到自己所負責部門以及下級部門的所有數據的。

所以「部門」這個許可權組有了等級劃分，根據等級進一步分配數據許可權。例如，基層銷售只能看到本人的數據，銷售組長可以看到本部門的數據，總負責人可以看到本部門及下屬部門的數據，總經理可以看得到全部數據。

部門的等級劃分我們放在了公司設置頁面，作為公司組織架構的介紹。

寫在最後

許可權系統的基本結構就是這樣，但是現實中的許可權設計卻千差萬別。

理解清楚基本概念，還要結合實際需求，去設計獨一無二恰到好處的許可權系統。也可以多參考些主流後台系統的許可權設計，了解下類似的問題，別的系統是如何解決的。

一個小Tip：比起不厭其煩地去註冊試用各種後台系統，不如直接去官網找幫助文檔，有些簡直詳細到可以當prd了。

歡迎一起交流後台系統相關的設計思考～