一、資料許可權定義

資料許可權主要分為維護許可權，使用許可權，特殊許可權。

操作是與業務實體相關聯的業務行為，分為維護類操作和使用類操作。

A.       維護類操作：對業務實體資料進行維護，改變其屬性的操作，例如刪除、修改等。

B.       使用類操作（使用場景）：不改變業務實體資料的屬性，只是引用業務實體資料的操作，例如參照，引用等。

NC6.0系統中對資料許可權做了重大調整，對資源實體做了擴充，引入了許可權規則，操作等概念，模型概念圖如下圖所示：

二、資料許可權規則

目前NC6.0資料許可權採用禁止權優先的原則，例如一旦使用者所在的角色有一個設定了無權那麼他就沒有操作的許可權。如果特殊許可權和維護許可權都配置了，則依然採用禁止權優先的原則。

NC6.0資料許可權按照使用的場景，分為維護許可權和使用許可權兩部分，維護資料許可權是指對某種資源實體的資料有無增刪改查的許可權，典型的應用場景包括對某條單據進行修改操作或者刪除操作時，校驗當前使用者是否有許可權進行這項操作。

而使用許可權則是指在資源實體被引用到某個場景的時候，對當前使用者的限制，換句話說就是控制使用者對某資源實體的資料引用檢視校驗。

三、規則控制組合

3.1不需執行後臺任務生效的

1.使用者關聯一個角色，定義規則，全部有權，全部無權均應控制正確；角色未定義規則，即未啟用資料許可權，控制結果集為全部

2.使用者關聯兩個角色，兩個角色均定義使用許可權規則，控制結果集取兩個規則的合集

3.使用者關聯兩個角色，一個角色定義規則，一個角色不定義規則，控制結果集為按規則控制

4.使用者關聯兩個角色，一個角色定義規則，一個角色全部有權，控制結果集為全部有權

5.使用者關聯兩個角色，一個角色定義規則，一個角色全部無權，控制結果集為全部無權（即使使用者關聯多個角色，只要有一個是全部無權，控制結果集便為全部無權）

6.為某個已關聯使用者的角色增加規則

7.修改規則，由規則A修改為規則B，按更新後的新規則控制

8.修改規則，由規則A修改為全部無權，所有關聯該角色的使用者全部無權

9.修改規則，由規則A修改為全部有權

9.修改規則，由全部有權修改為全部無權

9.刪除規則（注：因為刪除規則會帶來許可權分表的刪除，通知到前臺快取會有2-3分鐘的等待時間）

10.為某個未啟用資料許可權的角色啟用資料許可權（特別關注使用者關聯多角色，其中某個角色未啟用資料許可權，然後為其啟用資料許可權，定義規則），按規則控制

11.將某角色下的所有規則刪除，（特別關注使用者多角色場景）

12.取消使用者與角色的關聯關係，曾經角色的規則不在起作用

13.使用者共享與調動

   使用者由A集團共享至B集團，在A，B集團均啟用資料許可權，各個集團內的控制結果正確

   使用者由A集團調動到B集團，在A，B集團均啟用資料許可權，A集團的許可權取消，B集團控制正確

3.2、需定義執行後臺任務“許可權有效期及資料變更調整定時任務”

14.符合規則的資料集中檔案的增加；（如定義客戶的使用許可權規則為：客戶分類=A，在分類A中增加客戶檔案add1，需執行完後臺任務才可在參照中參照到add1）

15.使用者關聯角色到達生效日期與失效日期

3.3場景的說明

    1.產品出廠時，若產品領域有預置場景，則產品下各單據起資料許可權的欄位預設走產品領域的預置場景；沒有預置場景的產品單據，起資料許可權的欄位預設走通用引用場景

      （已測試通過，以物料採購分類為例）

2.可擴充套件單據欄位適用的場景範圍（元資料管理節點）

四、資料維護權測試要點

4.1、維護資料許可權規則

同上述資料許可權測試要點中規則控制

4.2、維護權的組合

--禁止權優先，（禁止權中包含建立者無權，全部無權），其餘為合集

五、資料許可權分表目前有兩種機制

1.可及時生效的分表任務

2.通過定義後臺任務執行的分表任務

5.1、可及時生效的分表任務

使用者關聯角色；

取消關聯關係；

為使用者關聯的某個角色增加使用許可權規則；

刪除某角色某場景下的規則；

規則的變動（如編輯規則，由規則改為全部有權或全部無權等）

……

5.2、通過後臺任務執行的分表任務

符合規則的資料集中檔案的增加；（如定義客戶的使用許可權規則為：客戶分類=A，在分類A中增加客戶檔案add1，需執行完後臺任務才可在參照中參照到add1）

5.3、分表任務的驗證

1.分表的緯度為：使用者，資源實體，場景，集團

2.表的建立時機：在角色分配完規則會去計算， 如果角色關聯了使用者產生分表，未關聯不產生分表

                為使用者分配角色會去計算分表。 如果角色定義了資料許可權  則能產生分表，未定義不分表

3.表的刪除時機：某使用者在一個集團內，在某個資源實體，某個場景下已沒有規則，則刪除相應的分表。（可通過取消使用者角色的關聯關係；刪除角色的許可權規則來實現。）

5.4、驗證步驟建議

庫中查詢分表資料的SQL語句：select* from sm_dpprofile_reg where cuserid='10021110000000000HIH' （查詢某使用者的分表任務，其中cuserid可以通過使用者表sm_user查詢出）

在這張表裡可以查詢出生成的分表名，資源實體，場景和集團

 1.U1關聯RA1（角色若定義了規則，則按照使用者+資源實體+場景+集團的維度生成表）

 2.若使用者+資源實體+場景+集團下已沒有規則，則刪除表；若還有規則，則按照新規則計算結果更新表內容（刪除規則，刪除使用者與角色的關聯關係）

 3.使用者關聯多個角色，仍按照使用者+資源實體+場景+集團的維度生成表，若依照該維度已經存在有表，則表不變，按照新規則計算結果更新表內容）

 4.共享使用者，保留原集團內表，按照目的集團內規則再生成表

 5.使用者調動，共享集團B的表無變化，源集團A集團的表被刪除

 6.使用者停用，許可權被清空，表被刪除

六、資料許可權引數設定

使用系統管理員登入環境，

【應用系統管理】-【系統初始化】-【系統引數設定】

         按照使用者—資源實體的模式進行分表，把資源實體對應的具體資料的ID儲存在分好的表中。

         由於規則資料分表儲存是一個後臺的非同步任務，所以在規則設定之後並不是立即生效的，需要等待一段時間之後才能夠生效，通常有三種模式需要重算規則資料。

1．  使用者重新委派角色

2．  角色的許可權設定發生變化

3．  檔案資料發生變化。

         由於前兩個和我們關係不大，我們只關心最後一個我們自己檔案一旦發生資料變化應該如何處理。

         現行的資料使用權，是採用資料庫分表來記錄符合條件的資料。當對應的檔案資料發生變化時，也需要重新運算分表結果。

        為了解決這兩個問題，許可權模組提供了一個後臺任務，任務名稱為“許可權有效期及資料變更調整定時任務”。此定時任務在實施時啟動，建議

每天執行一次，在每天凌晨00：05：00執行。它將處理前面提到的兩個問題。

    為了能夠讓許可權系統知道檔案資料發生了變化並進行變化記錄，需要支援使用許可權的檔案，當資料發生變化時(新增後、修改後、刪除後)，傳送

業務事件。預設規定事件源ID即為檔案資料對應元資料實體的ID（即定義的許可權實體資源所關聯的元資料ID），事件型別為：

IEventType.TYPE_INSERT_AFTER新增後； IEventType.TYPE_UPDATE_AFTER 修改後；IEventType.TYPE_DELETE_AFTER刪除後。

傳輸事件物件為：nc.bs.businessevent.UsePermChangeEvent。平臺註冊的監聽會收集上述事件並記錄資料變化。當發生資料變化時，呼叫

EventDispatcher.fireEvent(newUsePermChangeEvent(mdid, IEventType.xxx))。

第一步：部署後臺任務

註冊外掛（UAP註冊）這裡需要說明的是這個事件是全域性的只要傳送新增後 修改後 刪除後都會走這個監聽。

insertinto pub_eventlistener (dr, enabled, implclassname, name, note, operindex,owner, pk_eventlistener, pk_eventtype, ts) values (0, 'Y','nc.bs.rbac.bizlistener.BaseDocDataPermChangeEventListener', '檔案資料許可權分表任務外掛', '資料使用許可權分表任務', 99, '1012', '1001ZZ10000000016F0A','1001ZZ10000000016F09', '2011-04-28 16:57:24');

insertinto pub_eventtype (dr, eventtypecode, eventtypename, note, owner,pk_eventtype, sourceid, sourcename, ts) values (0, '1002', '資料使用許可權分表_檔案新增後', '新增檔案之後，資料許可權分表任務關心檔案的新增事件，對已經進行資料許可權分配的檔案，要進行資料許可權分表任務排程，將分表中的記錄進行更新', '10','1001ZZ10000000016F09', 'ALL', '所有檔案', '2011-04-28 16:56:04');

注意：由於檔案自身可能會有一些業務單據對其進行新增後，修改後，刪除後進行監聽，所以我們要在其他監聽類加上如下程式碼

元資料型別：

元資料型別規則編輯器

規則編輯器： nc.uap.rbac.core.rule.impl.MetaDataRuleEditor

規則生成工廠： nc.uap.rbac.core.rule.impl.MetaDataRuleFactory

離散型別：

離散樹型編輯器

規則編輯器：nc.ui.uap.rbac.rule.discret.ZDiscretDataTreeRuleEditor

規則生成工廠：nc.uap.rbac.rule.discret.DefaultDiscretRuleFactory

離散表規則編輯器

規則編輯器：nc.ui.uap.rbac.rule.discret.DiscretDataTableRuleEditor

規則生成工廠：nc.uap.rbac.rule.discret.DefaultDiscretRuleFactory

許可權分表介紹：

資料許可權的使用權目前主要涉及兩種方式，一種是在參照中加入使用權控制。一種是使用者呼叫許可權接

口獲得關心檔案的使用權規則sql條件。 在開發使用過程中，這兩種情況的發生率都是很高的。如果每次都去集合使用者所有的角色對關心檔案所定義的資料許可權使用權規則，然後根據規則生成一條複雜的sql條件提供給參照或者開發者。參照或者開發者再連線到自己的查詢條件後，再去查詢自己需要的資料，這樣勢必造成效率問題和sql的複雜度的升高。      

為了解決這個問題，為每個定義了使用權規則的檔案或者單據建立一個分表。此表中僅有id一個欄位，

用於儲存能唯一標識業務實體資料的列值。這樣許可權介面提供給開發者的sql條件變為了 “pk  in (select id fromzdp_xxxxxxx)”簡單語句。

八、測試要點：

1、資料許可權生效機制

1.可及時生效的分表任務

n  使用者關聯角色；

n  取消關聯關係；

n  為使用者關聯的某個角色增加使用許可權規則；

n  刪除某角色某場景下的規則；

n  規則的變動（如編輯規則，由規則改為全部有權或全部無權等）

2.通過定義後臺任務執行的分表任務

符合規則的資料集中檔案的增加；（如定義客戶的使用許可權規則為：客戶分類=A，在分類A中增加客戶檔案add1，需執行完後臺任務才可在參照中參照到add1）

2、基礎資料(參照、查詢以及快速查詢)

         參照查詢：只能參照到許可權規定內的可使用的資料

3、單據的分單、整單、空值

Ø  分單：( 拉式)

一張採購訂單的單據，包含2條屬於不同分類的物料

當採購入庫單引用採購訂單時，只能看到規則內的值(資料許可權定義有許可權的物料分類下的物料)

Ø  整單：(推式)

         一簽字就生成下游單據，這時整單據的表體內容都會生成

4、關聯關係以及跨組織參照

         定義了某部門的使用權，這時做單據需要參照到這部門下的人員時，也無法參照到。

         不同組織下的可見範圍，無論參照規則外的任何組織，都無權看到資料

5、模版、元資料管理

         模版優先，模版設定中“是否啟用資料許可權”；如果不勾選，分配的使用者就不受許可權的控制

6、引用場景(資產通用引用、供應鏈通用引用等)

7、資料許可權分表的效率