文章結合具體業務場景對電商後台設計中的系統權限設計的業務邏輯展開了梳理説明，並對相關問題展開了分析，希望通過此文能夠加深你對電商後台設計的認識。
在説權限設計前我們先來看個現實中的實例，大家在電影裏面應該都見過這樣的場景，當一個客户想進入銀行倉庫查看自己的私人保險櫃信息時，通常都需要經過幾個步驟：
在上面的實例中，客户在看到保險箱的物品之前，他需要有這麼幾個必要條件：
瞭解了上面的過程，對於我們理解一個系統的權限就會容易很多，我們再來梳理一下用户在系統中看到數據的過程：
在上面的過程中，除了第一步的分配賬號是由管理員操作的，剩下的三步都和用户所擁有的權限相關。通過具體操作對象的不同，上面三步可以分為兩類：
知道了需要對哪些對象進行管控限制，那麼設計功能也就有了針對性，接下來我們一一分析。
功能權限指的是用户具體能訪問哪些菜單，以及對菜單頁面中的哪些按鈕有操作權限。把多個菜單和對應的功能按鈕組織到一起就行程了一個權限列表，具體的組織方式如下圖：
對於用户來説，它又是如何獲得這些權限列表的呢？通常有以下幾種方案：
方案一：ACL(Access control list), 權限訪問列表
通過直接將用户和權限列表綁定在一起，實現的權限管理
方案二：RBAC(Role-Based Access Control)，基於角色的訪問控制
通過先創建一個角色，然後將權限列表在綁定在這個角色上，之後再將角色和綁定到用户身上，用户就可以獲得這個角色的所有權限。
如對於同一職位的職員，正常來説大家的權限都是一樣的，但是也會有特殊情況發生，比如給其中一個添加或減少部分權限，這個時候就沒有辦法了。對於這種情況，在現有的設計功能上也是有辦法解決的。
通常的方案就是在給角色綁定權限時，先採用權限最小化原則，能少給就少給，然後再做一個角色綁定多餘的權限，再把這個角色也綁定給職員，這個時候兩個角色的權限就合併到一起了，也就是用户和角色之間是一對多的關係。
對於RBAC還有幾個擴展模型：
實際開發中這些擴展模型，我們基本都不用，開發成本太多，實際意義和並不是很大，基本的模型已經足夠完成我們的系統需要。如果想了解的同學，網上搜索一下RBAC，有很多教程我這裏就不説了。
下面是基於RBAC的原型設計圖：
角色列表頁
角色授權頁
對於數據權限的管理比較複雜，這個主要還是有具體的業務來決定的，下面我們就看幾種常見的數據場景以及解決方案。
企業中通常都有銷售部，銷售部下又分各個大區，大區下又劃分小組。對於銷售人員來説，他們的薪資是和業績掛鈎的，所以沒有人會把自己的客户資源讓你別人的，這就導致數據處理上，銷售專員通常只能看自己的(自願共享的就不再這裏討論)，而對於銷售主管則能看到手下所有的銷售專員的客户資料，同理，大區經理，和銷售總監也都能看到自己手下所有人的客户資源。
在這種場景下的數據，很明顯是能看出，這是根據企業的組織架構，根據職員的職位高低來控制數據的訪問權限。所以它通常的解決方案是和組織架構相關聯的，具體邏輯如下：
分區塊的典型案列就是電商企業員工對多個倉庫的訪問問題，我們假設有一個大的電商平台，它在全國有多個倉庫，如北京倉、上海倉、西安倉、甘肅倉。對於各個倉庫的職員來説，通常他們只有當前倉庫的數據訪問權限，而對於總公司的買手、技術等人員來説，他們平時要巡檢查看各個倉庫數據，所以需要有全部倉庫的數據。而倉庫的組織架構和買手、技術所屬部門並不存在上下級關係。
在這種場景下的數據，它就是按照分區塊的方式來劃分。要解決這個問題其實也很簡單，就是上面講的【用户-角色-權限列表】，只是這裏的權限列表內容不再是菜單和操作按鈕，而是各個倉庫。
數據共享的場景是很常見的，像我們經常使用的協同文檔軟件，裏面都會有將內容共享給個人或者共享給某個組的功能。
這種場景下的的數據，我們需要通過單獨建表，維護共享者和被共享對象的關係，獲取數據時從對應關係表中讀取對應共享數據即可。
分狀態的數據控制，這種場景比較少見，一般出現在流程比較長的業務中。如金融借貸系統中，比如一個用户想要去借貸平台上貸款，假設他們的流程如下圖：
通常要完成整個業務流程，需要多個部門相互配合的，由於整個業務涉及了許多客户隱私信息，所以各個部門的職員一般只允許看到對應步驟的數據，如審查組通常只能看到狀態為【待審核】的信息，風控組只能看到【待評估】的信息，財務組只能看到【待放貸】的信息。
基於這種場景，有兩種解決方案：
上面兩種方式其實內部邏輯是一樣的，都是先根據用户的部門和職位先獲取狀態碼再獲取數據，但是可操作性和擴展性缺完全不一樣。
以上就是權限功能涉及的內容，如果你的業務還有更多花樣，請在下方留言。最後再給出一張用户綁定權限原型圖，大家根據自己的業務適當調整：
作者：JackLiu；個人微信公眾號: 揚帆去遠航（ID:Jackai_liu)
本文由 @Jack 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。