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