層級權限生效邏輯

1. 數據決策系統中的權限載體【部門】可以為樹狀結構，存在父部門和子部門。下文中稱為權限載體樹。

2. 數據決策系統中的權限實體【目錄】可以為樹狀結構，存在父目錄和子目錄。下文中稱為權限實體樹。

3. 按照不同的時間先後順序給父部門/子部門分配父目錄/子目錄的權限，最終生效結果各不相同。

        對於樹狀結構，先配置子節點的權限，再配置上代節點的權限。上代節點的權限會改寫子節點的權限，即清除子節點原本的權限，子節點直接繼承上代節點的權限。

        對於樹狀結構，先給上代節點配置權限，再給子節點配置不同的權限，父子節點權限各自生效，互不影響。

注1：職務和子部門同理，都會被父部門配置的權限改寫掉。

注2：權限快捷配置同理。

1. 邏輯：對於樹狀結構，先配置子節點的權限，再配置上代節點的權限。上代節點的權限會改寫子節點的權限，即清除子節點原本的權限，子節點直接繼承上代節點的權限。

1

權限載體樹。

1. 邏輯：對於同一權限實體（如同一目錄），先給子部門配置權限，再給父部門配置權限，父部門的權限會清除子部門設定的權限，子部門直接繼承父部門的權限。

2. 場景：先給子部門分配目錄的【查看、授權】權限；再給父部門分配目錄的【查看】權限。

3. 結果：子部門原先的【查看、授權】權限被清除，繼承父部門的【查看】權限。

2

權限實體樹。

1. 邏輯：給當權限實體是一棵樹狀結構（例如目錄樹），給同一權限載體（例如角色）先配置子節點的權限，再配置上代節點的權限，會清除原本子節點的權限，子節點繼承上代節點的權限。

2. 場景：先給角色X分配子目錄的【查看、授權】權限；再給角色X分配父目錄的【查看】權限。

3. 結果：原先的【查看、授權】權限被清除，直接繼承父目錄權限，角色X對子目錄只有【查看】權限。

3

平行權限樹。

1. 邏輯：對於權限載體樹（父子部門）和權限實體樹（父子目錄），先給子部門配置子目錄權限，再給父部門配置父目錄的權限，會清除之前給子部門配置的子目錄權限，進而繼承父部門的父目錄權限。

2. 場景：先給子部門配置子目錄的【查看、授權】權限。再給父部門配置父目錄的【查看】權限。

3. 結果：原先配置的子部門對子目錄的【查看、授權】權限被清除，繼承父部門對父目錄的權限，子部門對子目錄最終有【查看】權限。

4

交叉權限樹。

1. 邏輯：對於權限載體樹（父子部門）和權限實體樹（父子目錄），先給子部門配置父子目錄權限，再給父部門配置父目錄權限，會清除子部門的父子目錄權限，進而繼承父部門的父目錄權限

2. 場景：先給子部門配置父目錄的【查看、編輯】權限，給子部門配置子目錄的【查看、編輯、授權】權限。再給父部門配置父目錄的查看權限。

3. 結果：此時查看子部門的權限，子部門原有的的父子目錄的編輯/授權權限被清除，繼承父部門配置父目錄的查看權限。

1. 邏輯：對於樹狀結構，先給上代節點配置權限，再給子節點配置不同的權限，父子節點權限各自生效，互不影響。

1

權限載體樹。

1. 邏輯：對於同一權限實體（如同一資料連結），先給父部門配置權限，再給子部門配置權限，父子部門的權限互不影響，各自生效自己的權限。

2. 場景：先給父部門分配權限管理的【使用、授權】權限。再給子部門分配權限管理的【使用】權限。

3. 結果：父部門對權限管理的【使用、授權】權限不變，子部門對權限載體的【使用】權限不變。

2

權限實體樹。

1. 邏輯：當權限實體是一棵樹狀結構（比如目錄樹），給任一權限載體先配置上代節點的權限，再配置子節點的權限，父子節點的權限均正常保留，互不影響各自生效。

2. 場景：先給角色X分配父目錄的【查看、編輯】權限。再給角色X分配子目錄的【查看、編輯、授權】權限。

3. 結果：角色X對父目錄的【查看、編輯】權限不變，角色X對子目錄的【查看、編輯、授權】權限不變。

3

平行權限樹。

1. 邏輯：對於權限載體樹（父子部門）和權限實體樹（父子目錄），給父部門配置父目錄權限，再給子部門配置子目錄的權限。對於子部門來說，子目錄保持子部門的設定，父目錄及其他子目錄都繼承父部門的父目錄權限。

2. 場景：先給父部門配置父目錄的查看權限。給子部門取消子目錄1的查看權限，配置子範本2的授權權限（權限縮減和權限放大）。

3. 結果：父部門對父目錄的【查看】權限不變。並且父部門對子目錄繼承該權限，父部門對子目錄有【查看】權限。

              子目錄1和子目錄2保持子部門自己的權限配置，子部門對子目錄1無權限，子部門對子目錄2有【查看、編輯、授權】權限。

              父目錄和其他子目錄都繼承父部門對父目錄的【查看】權限，子部門對父目錄和其他子目錄有【查看】權限。

4

交叉權限樹。

1. 此種情況在10.0.17前後版本不同，請根據自己的工程版本選擇合適的範例。

2. 10.0.17 及之後版本：時間優先最高。

3. 10.0.17 之前版本：權限實體繼承優先大於權限載體繼承。

5

10.0.17 及之後版本。

1. 邏輯：對於權限載體樹（父子部門）和權限實體樹（父子目錄），給子部門配置父目錄權限，給父部門配置子目錄權限。按照權限設定的時間先後順序，對於子部門的子目錄來說，先繼承子部門對父目錄的權限，再改寫繼承父部門對子目錄的權限。

2. 場景：先給子部門配置父目錄【查看】權限。再給父部門配置子目錄的【查看、編輯、授權】權限。

3. 結果：當子部門配置父目錄的「查看」權限，此時子目錄繼承該權限，子部門對子目錄有【查看】權限。然後父部門配置子目錄的【查看、編輯、授權】權限，按照時間優先，此時子部門改寫繼承該權限，子部門對子目錄有【查看、編輯、授權】權限。

6

10.0.17 之前版本。

1. 邏輯：對於權限載體樹（父子部門）和權限實體樹（父子目錄），給子部門配置父目錄權限，給父部門配置子目錄權限。對於子部門，父子目錄均保持子部門本身的設定對於子部門的子目錄來說，同時有兩個繼承權限，分別是父目錄的權限（來自子部門本身）和父部門的權限，由於權限實體繼承優先大於權限載體繼承，所以優先繼承父目錄的權限，不會繼承父部門的子目錄權限。

2. 場景：先給子部門配置父目錄的【查看】權限。再給父部門配置子目錄的【查看、編輯、授權】權限。

3. 結果：再次查看子部門的權限，父子目錄都只有查看權限。對於子部門的子目錄來說，同時兩個繼承權限，一個是子部門配置的父目錄的查看權限（權限實體繼承），一個是父部門配置的子目錄的授權權限（權限載體繼承）。由於權限實體繼承優先大於權限載體繼承，所以子部門的子部門優先繼承查看權