salesforce零基礎學習（一百一十八）Restrict Rule

本篇參考：

作為salesforce從業人員，資料的許可權管理是一個特別重要的內容。我們熟知的設定許可權的方式就是先設定 OWD進行一下 high level的設定。然後通過 Role Hierarchy / Share Rule / Manual Share進行資料許可權的擴充從而達到不同的場景下，不同的USER可以擴充他可以看到的資料範圍。

當然，不同的公司需求也千變萬化。以下是潛在的場景需求：

MD關係的資料，針對某個 Role的客戶，只希望master型別的資料通過sharing setting進行了許可權的擴充，但是detail的資料還是隻能看到各自own的。因為MD關係的許可權設定是 control by parent，沒法去限制detail的許可權，這種開發時我們只能將 detail設定成 private，然後增加很多 sharing rule或者 manual share對大部分人進行資料許可權共用而只是為了忽略一小部分。
一個表有很多的 record type，需求是希望指定使用者（比如user的某個欄位）只能看到某個record type的一些資料，其他資料不支援檢視（列表/report等等）

當然，demo中只列舉了兩個簡單場景，實際場景會更多更復雜。SF的許可權管理是特別厲害的，但是仍然要記住有很多限制。我們可能通過一些 workaround solution解決了，比如 sharing rule等，但是我們要知道這些都是有數量限制的，隨著業務的不斷變動，觸發了一些government limitation以後，我們這種還是一個好的方案嗎？現在salesforce針對這種類似的情形，增加了 restriction rule。

一. Restriction Rule概念和基礎知識

簡單來概括， Restriction Rule的目的是用來隱藏掉一部分基於之前的資料許可權，保證滿足 restriction rule的資料可以被 user看到，從而增強了salesforce的資料存取的許可權。

通過上圖我們可以看到這個功能很強大，當然，回想一下之前的 dynamic form / dynamic action等等強有力的功能，使用時必不可少的受制於他的 limitation，所以使用前我們需要先了解一下 restriction rule consideration。

1. classic 和lightning 都支援嗎，所有的表都支援嗎？

Answer: 只支援 lightning，classic環境不保證。所以如果專案是新專案，僅在 lightning下使用，那可以考慮，否則別給自己找坑。不是所有的表都支援。

　　custom objects,external objects, contracts, events, tasks, time sheets, and time sheet entries

2. Restriction Rule支援哪些 Feature？或者說我從哪裡可以直觀的看到這個功能所產生的效果。

Answer: 以下的 feature 支援 Restriction Rule.

List Views
Lookups
Related Lists
Reports
Search
SOQL
SOSL

這裡需要提示幾個注意事項，當然官方的consideration特別多，這裡例舉幾個我們常用到的項。

restriction rule建立以後，如果之前 search box搜尋過相關的記錄存在 shortcut，則search還是可以看到。如果最近瀏覽過記錄，在 recently view的檢視中還是可以看到。當然，當你點選這條記錄的時候，會給你報錯告訴你無法存取。
當user執行克隆操作時，如果這條記錄的 lookup欄位因為 restriction rule導致你無法存取情況下，克隆會報錯。比如 order資料會關聯 contract資料，如果contract因為restriction rule導致你無法存取，當你克隆 order時便會報錯。
Restriction Rule 不適用於 System Mode下程式碼執行的場景。
Restriction Rule不適用於以下的這些許可權場景： View All, Modify All, View All Data, and Modify All Data.
儘管一條記錄因為 restriction rule導致了沒法檢視，但是我們沒法通過 UserRecordAccess這個表來確定。舉個例子，某個user針對一條資料擁有許可權，但是restriction rule給它限制住了存取。儘管這條記錄存取不到，但是 UserRecordAccess卻會顯示對這條資料有許可權。所以後續碰到對某條記錄沒有許可權但是 UserRecordAccess卻可以展示有存取許可權的場景下，可以先查詢 Restriction Rule作為快速排查。

二. Demo

我們建立了一個 Demo Object的custom object，包含兩個 record type: Sample 1 & Sample 2. 我們在這個表設定了一個 restriction rule，當 user的 Role為 Installation & Repair Services情況下，只能檢視 Record Type 為 Sample 1的資料。

我們可以看到Demo Object的 OWD設定的是 Public Read Only.

我們建立了4條資料，兩條 sample1的，兩條 sample 2的，針對system admin的資料，我們可以看到4條資料。

針對demo user，設定了他的 role為 Installation & Repair Services，可以看到儘管OWD設定的是 Public Read Only，但是因為restriction rule的影響，只能看到 sample 1的資料。

這裡做一下自定義邏輯的補充，我們通過lwc元件展示restriction rule的影響。

Demo_ObjectController.cls

public with sharing class Demo_ObjectController {
    @AuraEnabled(cacheable=true)
    public static List<Demo_Object__c> getAllList() {
        List<Demo_Object__c> demoObjectList = [SELECT Id, Name
                                                FROM Demo_Object__c
                                                LIMIT 50000];
        return demoObjectList;
    }
}

demoObjectList.html

<template>
    <lightning-datatable
        data={datas}
        columns={columns}
        key-field="Id"
    >
    </lightning-datatable>
</template>

demoObjectList.js

import { LightningElement, track, wire } from 'lwc';
const columns = [
    { label: 'Name', fieldName: 'Name', type: 'text' }
];
import getAllList from '@salesforce/apex/Demo_ObjectController.getAllList';
export default class demoObjectList extends LightningElement {
    columns = columns;

    @track datas;

    @wire(getAllList)
    getAllList({ error, data }) {
        if(data) {
            this.datas = data;
        } else if(error) {
            //TODO
            console.log(JSON.stringify(error));
        }
    }
}

通過demo user存取以後的效果：

with sharing是遵循 restriction rule的

將程式碼改成 without sharing，會發現所有的資料都可以搜尋出來。

我們再用 UserRecordAccess這個表進行一下驗證。

儘管UI上demo user存取不了sample 2的資料(下圖是管理員使用者檢視的資料)

但是通過UserRecordAccess是可以存取到的。（下圖是demo user id進行的查詢展示）

這個其實是一個很危險的行為，不知道後續salesforce是否會增強。因為後續我們自定義的list view如果使用了 without sharing並且進行一些filter，結果集可能獲取到的是超過restriction限制的資料，因為code的SOQL是 system mode， restriction rule沒法生效。結果集搜尋出來點選跳轉到詳情可能 list展示了，但是點選報錯，使用者行為極其不友好，並且沒法通過 UserRecordAccess去實際的判斷是否擁有許可權，所以如果專案中有用到 restriction rule情況並且有自定義 list view，建議先將 restriction rule的條件和過濾的結果集也在後臺看著過濾一下，避免造成不必要的影響。

總結：從功能來看，restriction rule對於許可權控制又提升了特別多，也可以優化很多曾經各種繞來繞去的設計（針對一小部分特殊user的特殊存取）。使用前多看一下 consideration多測試。篇中有錯誤地方歡迎指出，有不懂歡迎留言。