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

• 2022 年 9 月 19 日
• 筆記
• admin學習, salesforce&apex, salesforce學習

本篇參考：

//help.salesforce.com/s/articleView?id=sf.security_restriction_rule.htm&type=5

//help.salesforce.com/s/articleView?id=sf.security_restriction_rule_examples.htm&type=5

//developer.salesforce.com/docs/atlas.en-us.236.0.restriction_rules.meta/restriction_rules/restriction_rules_intro.htm

作為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多測試。篇中有錯誤地方歡迎指出，有不懂歡迎留言。