許可權設計的最終目標就是定義每個使用者可以在系統中做哪些事情。

當我們談到許可權的時候，一般可以分為功能許可權、資料許可權和欄位許可權；

功能許可權：使用者具有哪些權利，比如特定單據的增、刪、改、查、審批、反審批等等；一般按照一個人在組織內的工作內容來劃分；比如一個單據往往有錄入人和審批人，錄入人具有增、刪、該、查的許可權；而審批人具有審批、反審批和查詢的許可權。有時，功能許可權被細分為頁面許可權和操作許可權。

資料許可權：使用者可以看到哪些範圍的主資料，比如按照部門或業務條線來劃分。使用者張三看到A團隊的資料，使用者李四隻能看到B團隊的資料。

欄位許可權：在特定的單據中，可以看到哪些欄位；比如針對入庫單，財務人員能看到採購成本，而庫管員看不到等等。欄位許可權和資料許可權的區別在於，資料許可權規定了哪些行的資料看不到，而欄位許可權規定了哪些列的資料看不到；這種許可權設計現在見的比較少了，因為如果兩個使用者看到的列都不一樣，通過設計不同的表單也能實現，此時欄位許可權就轉換為功能許可權了。

如上圖所示，資料許可權決定使用者看到的是團隊A還是團隊B的資料，欄位許可權決定能否看到金額這一列的資料。

對功能許可權和資料許可權的抽象

這個就是角色的引入，網上有很多這方面的文件介紹可以參考，我這裡挑重點簡單說一下；

在一般的組織中，使用者的許可權是由崗位決定的，由於使用者可能面臨轉崗、離職等工作；所以崗位和許可權的關係比使用者和崗位的關係要穩定的多。

所以為了簡化使用者許可權的分配操作，降低操作風險；同時，也便於把許可權管理移交給統一的使用者管理部門，一般會引入角色的概念，作為功能許可權和資料許可權的抽象；

注意：許可權、角色和使用者是多對多的關係；

資料許可權的進一步抽象

考慮一種場景，一個集團有50個分支機構，每個分支機構下平均有3個部門，各個部門的組織架構是大體類似，在系統中都分為單據的錄入者、複核者、審批者和查詢者；這種情況下，如果按照角色來設定，需要設定50*3*4共600個角色；而且一旦面臨的部門和團隊的增加和撤銷，也面臨角色的大量設定和調整。

由於這個組織結構比較均勻，所以使用者許可權其實等同於功能許可權和資料許可權的交叉組合，功能許可權表示橫向的錄入、複核、審批和查詢許可權；資料許可權表示具體某個分支機構下的部門。

資料許可權的抽象，有些系統稱之為“崗位”，有些稱之為“組織”，鑑於“崗位”和角色的含義有些衝突，此處暫且稱之為“資料組織”吧。

剛才的案例中，如果使用角色+資料組織的組合，只需要預設定50*3=150個數據組織和4個角色。而且方便於將來的組織拓展，比如某個分支機構下要新增一個團隊，按照原來的方案，需要新增4個角色，現在只需要在基礎資料里加1個數據組織就可以了。

資料組織的層級管理

多層級組織時，上級組織往往具有下級組織的所有資料許可權；所以通過設定組織的層級關係能進一步優化配置方案。比如上圖中上海分支機構下的團隊a和團隊b都可以合併為一個數據組織，華東片區的資料組織可以在這個基礎上繼續向上合併。

一人多崗和交叉型的組織結構

資料組織和角色能發揮作用的前提是組織呈現出縱向部門團隊和橫向崗位的完美組合關係；但是實際上可能存在一人多崗的情況，則破壞了這種規則。比如使用者張三是A團隊的錄入人和B團隊的審批人；如果按照剛才的方案，角色設定為錄入崗和審批崗，資料組織設定為A團隊和B團隊；那麼實際的效果是使用者張三同時具備A團隊和B團隊的錄入+審批許可權。

還有一些臨時型組織，可能會從原來的組織中跨部門、跨團隊抽調人員形成臨時性的新組織，而這些使用者原來的組織崗位仍然保留；也會出現這種問題；所以要採用新的規則進行處理。

處理方案有2種；

1、新增使用者名稱，相當於一個使用者有多個使用者名稱，每個使用者名稱賦予的許可權的不同。優點是邏輯簡單，設定便捷。但是缺點也很明細，隨著資訊化系統的建設越來越多，使用者需要管理的使用者名稱已經越來越多，密碼越來越複雜，多使用者名稱容易造成混亂；而且有的公司為了整合使用者管理和許可權管理，使用公司入口網站跳轉到各個應用系統的方式，不太支援多使用者名稱；

2、建立資料許可權的優先順序。上述這個案例，如果將資料許可權繫結在角色上，則可以通過讓使用者切換角色來實現許可權的控制；

所以解決方案是：

角色和使用者名稱都可以繫結資料組織；但是角色的優先順序高於使用者。只有到角色沒有繫結資料組織時，系統獲取使用者名稱所對應的資料組織。

如上圖所示，張三同時具有錄入角色和審批角色，使用者名稱本身繫結的資料組織是北京的團隊；當張三切換到錄入角色時，由於錄入角色沒有繫結資料組織，所以使用其自身的資料組織，那麼張三隻能新增北京分支結構團隊A的單據；如果切換到審批角色時，由於審批角色綁定了上海的資料許可權，所以張三隻能查詢並審批上海分支機構b提交的單據。

有的系統資料許可權設計的更為複雜，可以分配給角色、資料組織和使用者名稱本身，在此基礎上建立優先順序關係，從事實現更為複雜和靈活的許可權配置。

審批的處理

審批本身無需特殊說明，這裡單拉出來是因為自己負責過一個專案，本來許可權的架構是按照上面的思路進行的，但是由於涉及的資料計算量很大，開發商給的方案是按照批次進行提交和審批，我想了一下，覺得沒有什麼問題就同意了。然而在實操中產生了一定的問題。

多層組織結構下，上級組織會審批來自於下層組織的資料；審批可以按照批次或按照最明細的資料；按照最明細的資料進行審批，其邏輯和上面描述的一樣，一般沒有什麼問題。

但是按照批次的話，需要保證提交者的批次資料，必須全部被審批人看到，而不能部分被看到；否則這批資料同時存在已審批和未審批兩種狀態。換句話說，審批人的資料許可權必須完全包含被審批人的這一批次資料許可權；在許可權設計時需要額外加一些校驗。當時專案的問題是，由於一個批次資料量太大，複核人需要分批進行復核，後來發展為2個複核人對同一個人的資料，根據不同的業務場景進行分工複核，和上面的原則產生了衝突。

轉https://zhuanlan.zhihu.com/p/396125748