本篇参考：
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多测试。篇中有错误地方欢迎指出，有不懂欢迎留言。
