本篇參考:
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
作爲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多測試。篇中有錯誤地方歡迎指出,有不懂歡迎留言。