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

本篇參考：

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

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

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