哈哈哈哈，打不過我吧，沒有辦法我就是這麼強大，哈哈哈哈，追不上我吧，沒有辦法被我打敗啦，哈哈哈哈，看不見我吧，分析許可權根本沒在怕！

所謂資料分析的許可權控制，就是指標對不同的使用者分別配置不同的訪問規則，使他們在登入後看到的資料不一樣。有些東西不是你想看，想看就能看的，想看還得問問俺老孫答不答應…

首先我們來捋捋分析的許可權是如何體現在資料中的。

一、分析中的使用者許可權

在很多應用系統中，經常有兩個典型的使用者，root 和 guest。對於資料分析來說，root 使用者許可權最大，可以查詢全部表的資訊； guest 使用者只有部分許可權：只能檢視個別表的資訊。例如：

root 使用者的查詢頁面 demo 如下圖：

guest 使用者的查詢頁面 demo 如下圖：

怎麼樣，大不相同吧，guest 們是不是有種被“歧視”的感覺？那麼，是怎麼做到讓你看啥你就只能看啥的呢？其實並沒那麼奇妙，說白了 root 和 guest 使用者不同的許可權，只是因為對應了不同的可視檔案（字尾名為 vsb），而 vsb 檔案中一些表和欄位的可見性設定就是決定許可權的最根本因素。具體而言，其中對於表的可見性又分為可見、不可見或者條件可見。

可視檔案？什麼鬼？——不要著急，接下來就教你製作可視檔案。

二、使用可視檔案控制分析許可權

同學們可以翻到《當多維分析碰到預定義語義》，回顧一下如何建立元資料檔案，然後，我們就可以繼續講解如何建立可視檔案了。

在選單欄中點選【系統】-【匯入元資料】，將元資料檔案中的表匯入。

下面用 root.vsb 和 guest.vsb 給大家板書一下。敲黑板，注意了…

首先編輯 root 使用者的可視檔案 root.vsb，對於 root 使用者我們可以使他看見所有表的資訊所以對每一個表我們都給他可見的許可權：

然後再編輯編輯 guest 使用者的可視檔案 guest.vsb。對於 guest 使用者，諸如 vip 客戶等一些表不想讓他看到，所以將這些表等設為不可見：

“表可見性”設定為可見時，使用者就可以正常查詢該表的資料。而設定為不可見時，在查詢該表資料時就會報錯。如果設定為條件可見，那麼將根據設定的條件，在查詢表的資料時強制過濾。這樣，通過使用不同的可見性配置檔案，就可以使不同使用者瀏覽到的記錄不同了。

接下來的問題來了，怎麼使用這個可見性配置檔案呢？簡單地說，就是通過 Tag 屬性傳遞。不過，潤乾官方提供的只是查詢工具，本身不具備使用者許可權系統。因此，客戶在把查詢頁面引入到自己的系統後，還需要在相應的 jsp 檔案中的 java 程式碼里根據當前使用者準備不同的 Tag 屬性值，從而達到許可權控制的目的。（關於 Tag 屬性的詳細介紹需要同學們去自學《程式設計師參考》查詢分析控制元件。）

例如，如果當前使用者是 root ，那就通過 Tag 屬性傳遞如下值：

String visibility = “root.vsb”;//root.vsb: 對元資料中的所有表都可見

而如果當前使用者是 guest 則需要通過 Tag 屬性傳遞如下值：
String visibility= “guest.vsb”;//guest.vsb: 僅對元資料中的訂單表、 產品類別和產品表可見

然後，再用下面的標籤就可以了。

潤乾報表提供了 qyx.jsp 頁面，直接把這個放進去即可。

三、使用巨集靈活控制分析許可權

現在我們知道了，想要完成許可權控制，只需要製作不同的 vsb 檔案就可以了。但是實際場景中真的要這麼實現就很複雜了。例如在這樣一個銷售場景中，要求每個員工只能查詢自己的訂單情況

如果 ** 按照上面的思路：** 有 N 個銷售代表就要做 N 份可視檔案，拿某個銷售代表“李芳”為例，需要把訂單表的“表可見性”設定為“條件可見”，並輸入相應的條件：

那麼當李芳查詢的時候在 WEB 端的結果就會像下面這樣：

不過，如果真要這麼做，那麼有多少個僱員就要做多少個可視檔案，那豈不是廢了老勁了？這時候我們就該想有沒有哪個大神能來幫幫我們了……

不用急！找到了潤乾報表中“巨集”一切就迎刃而解了。

巨集可以實現動態條件，對於這個實際場景問題，一個可視檔案就可以輕鬆解決：

首先，我們要知道巨集只能用在條件可見裡，其中巨集名稱就是 ${} 中變數名稱（這個例子中，巨集名稱就是“僱員”）；巨集值就是 ${} 裡面變數的值，在實際執行中，系統會用接收到的巨集值替換掉巨集名稱。接下來我們就通過兩個場景看看巨集值怎麼傳遞的：

場景一：某個僱員登入

在使用了巨集之後，系統會利用巨集拼接查詢條件：

SELECT * FROM 訂單 where 僱員 ID = ${僱員}

假設登入的僱員為“李芳”，從登入的 session 介面獲取到僱員值為“李芳”的僱員 ID 為 3，將巨集值 3 傳遞進去後就會得到：

SELECT * FROM 訂單 WHERE 僱員 ID = 3

為了把正確的巨集值傳遞過來，就需要程式猿帶上我們的 Java 程式碼上場了。在整合到應用系統後，應該由應用系統負責提供當前登入使用者的資訊，通過 session 傳遞過來。例如下面 getParamValues().put() 方法。（例子中為了演示直接在 jsp 寫了固定值，需要手動改這個值來模擬不同登入使用者）

場景二：某個經理登入

我們還是將條件拼接上……

不過不對呀，好像不符合要求呀，我們想要的是經理看到所有員工的訂單資訊，員工只能看到自己的訂單資訊。這個巨集似乎解決不了問題了——沒關係，沒什麼是多加一個巨集解決不了的問題：

上圖的程式碼首先從登入的介面獲取到登入者僱員 ID，判斷是否是經理 ，如果是經理使用者登入，就將經理巨集的值設定為 1=1，使得所有資料都滿足“1=1 or 僱員 ID= 登入使用者 ID”，也就查出所有的資料了。

而如果是普通員工登入，就將經理巨集的值設定為 1=0，這樣對於“1=0 or 僱員 ID= 登入使用者 ID”來說，只有登入使用者的 ID 滿足條件，也就限制普通員工使用者只能看自己的資料了。

假設登入的是鄭建傑經理，在拼接條件並傳遞巨集值後，SQL 為：

SELECT * FROM 訂單 WHERE 1=1 or 僱員 ID = 5

查詢時就可以看到所有僱員的訂單資訊：

四、DQLTableFilter 物件簡述

在上面的程式碼中，我們用到了 DQLTableFilter 物件。每個 DQLTableFilter 物件中儲存了多個表的許可權條件（也就是 vsb 裡的可視條件），同時也儲存了一套巨集的具體值。在 session 裡可以設定多個 DQLTableFilter 物件，給不同許可權的人使用。具體選用哪個 DQLTableFilter 物件，是通過它的名稱控制的，預設的是“default”。在拼 SQL 的時候，就會自動追加涉及到的表的許可權條件，同時替換巨集值。這樣，當有使用者登入時，可以從 session 中獲取到當前登入使用者的 DQLTableFilter 物件，其中包括和當前使用者匹配的一套巨集值，這樣在條件拼接時預設拼接當前使用者的這套巨集值，這樣就可以簡單實現許可權分配了。

當然一個巨集值，不僅限於是一個固定的欄位值，也可以是欄位名、比較符、欄位值等任何內容，只要確保可視條件裡的巨集被巨集值替換後，是一個合法的條件表示式即可。

不用 N+1 個可視檔案，不用 N+1 個可視條件，只要一個可視檔案，只要一個可視條件，就這麼 easy，有了可視檔案，老闆再也不用擔心角色分配了，有了“巨集”，員工再也不用擔心製作可視檔案了。

五、針對欄位控制權限

到這裡並沒有結束，許可權控制不僅侷限於表還可以深入到某個表中的某個欄位。我們繼續舉栗子，假設不想讓“趙軍”看到”上級”列，只需要在不可視欄位中新增上“上級”欄位即可：

此時 web 端，分析僱員表中“趙軍”（ID=200005）就不會看到“上級”資訊：

看到這裡的寶寶相信已經 get 到了一項新技能，開始了嗎？奧，已經結束了，如果新技能還沒有 get 過癮，就趕緊來潤乾報表《分析教程》入坑吧…