Salesforce的权限体系我相信大家已经很熟了。
数据级别权限,表级别权限,字段级别权限,功能权限,分别坐落在Profile/Permission Set和role/Sharing rule当中,还有一些是作为Feature License放在了User上。
可是对于自定义功能,SFDC并没有提供太好的控制方式。
逼的广大开发人员不得不开各种脑洞。
比如在人事系统里,HR和领导能看见员工评价,普通员工看不到员工评价,
这用Profile的FLS简简单单地就能控制了。
但是在所有人都能看到的VF上,假如有个员工评价Section不想给普通员工看的话,就不好办了。
在VF里可以判断当前User的Profile,判断一下当前用户的Profile在不在允许列表里不就行了嘛。
好家伙,一打听,500个Profile能看。这不行啊,还是看看谁不能看吧,呦呵,800个Profile。
开发人员就开脑洞了,我把能看的Profile的末尾加一个“VIP”,不能看的都没有。接着就动手把500多个Profile一个一个的改了名字。
然后在VF里判断User的Profile结尾是VIP的才显示。
妥了,实现,下班。
第二天,经理过来搂住你的肩旁,说,昨天那个功能实现的很好,今天还要再加一个Section,和昨天的差不多,不过普通员工Level里的组长可以也可以看。开发人员想了想,总不能再给Profile加一个后缀吧。就算这次可以,那以后再来一个怎么办。。。。。
后来,听说开发人员被120拉走了。
像这种自定义功能的权限控制,SFDC提供了Custom Permission,作为Profile与Permission Set向自定义功能领域的延伸。
说白了,就是Profile与Permission Set原本能控制的都是标准功能,Custom Permission就是一个插件/拓展包,赋予了Profile与Permission Set控制自定义功能的能力。
所以遇见上面的场景,我们只需要针对每一个Section建一个Custom Permission,
然后将这些Custom Permission挂到需要此权限的Profile或者Permission Set,
然后在VF中写上Custom Permission的判断。
如下方官方文档提供的例子一样
<apex:pageBlock rendered="{!$Permission.[Your Custom Permission API Name]}"> <!-- Confidential Content Here --> </apex:pageBlock>
在Apex中想用Custom Permission控制业务逻辑的话,
就要使用下面的方法,官方文档
if(FeatureManagement.checkPermission([Your Custom Permission API Name])) { // Your Codes Here }
这样一来,想控制一个群体,就挂在Profile上,想控制个别人,就挂在Permission Set上。
为什么叫“挂在”呢,因为只有在Profile和Permission Set下面才有添加Custom Permission的按钮。
那么,想创建一个Custom Permission,在哪创建呢?
第一种方式是官方文档常写的 —– 点击Setup,然后左上方Quick Find,输入Custom Permissions。
第二种方式是按照本博客的风格 —– Setup -> Build -> Develop -> Custom Permissions。
Custom Permission本身需要定义的内容倒是不多,就一个Label一个API Name是必须的,其他都可有可无。
虽然Custom Permission只是Profile与Permission Set的功能拓展,
但由于在VF中官方提供了方便的检查方式($Permission),倒是给我们提供了另外一个用途,
正所谓,有心栽花花不开,无心插柳柳成荫。
什么用途呢,举个例子。
DevOps团队免不了要做修正数据的活儿。修数据这种事情,力求的是外科手术一般的精准,影响越小越好。
遇到Account这种业务注定很庞杂的表的时候,不管是Trigger,还是WorkFlow上面都会有大量的业务,并不需要都跑一遍。
有时候修正数据还会被Validation Rule拦住。也不可能修数据的时候把Validation Rule都关掉吧,那样影响太大。
就拿Validaiton Rule来说,为了跳过Validation Rule,我见过有人是这么做的,
在Validation Rule里套了一层
AND( NOT($Profile.Name = "System Administrator"), XXXXXXXXXXXXXXXXXXX )
这好家伙,您管理员老先生是有特权了,以后什么Validation Rule也拦不住您嘞。
这以后想让Validation对您老生效可就麻烦了。
这时候就想,哎呀,要是能判断Permission Set,而不是判断Profile该多好。
需要修数据的人assign到这个Permission Set下面,修完数据把人remove出去。
可惜SFDC并不支持Permission Set。
哎,不怕。
这时候就轮到Custom Permission登场了。
用来判断Custom Permission的$Permission既可以在VF上使用,也可以在Validation Rule里使用。
这就给了我们可乘之机。
只要我在Validation Rule里套上一层
AND( NOT($Permission.[Your Custom Permission API Name]), XXXXXXXXXXXXXXXXXXXXXX )
就算是埋下了开关,把这个Custom Permission挂到专用的Permission Set下面,
谁想跳过Validation Rule,就把谁Assign到这个Permission Set下面。
就这样,做到了人员的灵活配置。
同理,在Workflow的触发条件里也可以套上这么一层。
Trigger里用FeatureManagement的checkPermission方法,也可以实现跳过的功能。
这就算是利用Custom Permission的特性,实现了针对特定User跳过Validation Rule,Workflow,Trigger的开关。
当然这种开关还有很多方式可以实现,但这个功能用的人很少,本着介绍功能的目的,推荐这么一种方案。
具体的功能介绍,看官方文档。
另外,Custom Permission还支持Connected Apps。就是通过绑定的App连接系统就会自动赋予Custom Permission,算是提供了系统集成自定义权限控制的方法。今后有机会写集成相关内容的时候,再详细聊聊。
现在是不是可以用permission set了?https://help.salesforce.com/s/articleView?id=sf.perm_sets_best_practices.htm&type=5
向邱老板学习。读了两遍,终于明白VF那是什么意思了。
下次尽量不用缩写了(捂脸)
缩写我明白,我是不明白你写的场景。我开始想数据应该是可以按照profile里定义的显示或者不显示,最后才搞明白是页面的section.
话说为啥每次评论都要写电子邮件啊,哈哈
我也没看明白VF是啥 只能猜一下visualforce?
是的,我把Visualforce Page缩写成了VF。