權限設計的最終目標就是定義每個用戶可以在系統中做哪些事情。
當我們談到權限的時候，一般可以分為 功能權限、數據權限和字段權限；
功能權限：用戶具有哪些權利，比如特定單據的增、刪、改、查、審批、反審批等等；一般按照一個人在組織內的工作內容來划分；比如一個單據往往有錄入人和審批人，錄入人具有增、刪、該、查的權限；而審批人具有審批、反審批和查詢的權限。有時，功能權限被細分為頁面權限和操作權限。
數據權限：用戶可以看到哪些范圍的主數據，比如按照部門或業務條線來划分。用戶張三看到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