我的Case去哪了?

“求救。用户说看不到Case了。”
“Case看不到了?一条都看不到?如果一条都看不到的话看看Object Permission,是不是Case的CURD都没勾选?”
“看了,CRUD都有。不过。。不是所有Case都看不见。是看不见Owner是自己之外的Case。。。”
“唔。。。我之前说过的,Profile管全表,Role管数据。
“我记得的。。”(唰唰翻笔记中)
“所以,看看OWD是不是设成了Private,并且勾选了Grant Access Using Hierarchies。如果是的话,看看这个用户的Role是不是在最底层。”
“没错,OWD为Private,开启了Using Hierarchy,Role也确实在最底层。并且没有任何Sharing Rule。”
“所以他只能看见自己的Case没毛病啊。”
“好吧。。。那现在用户想看到自己的Account下面的所有的Case怎么办啊?”
“把Case的Owner都改成他不就行了。”(喝口茶)
“囧。”(囧脸)
“你先自己想想。”
“好吧。。。啊!我想到了!用Sharing Rule!”
“嗯哼,继续说。”(坏笑)
“Sharing Rule有两种,一种是Base on record Owner,一种是Base on criteria。”
“没错。那么你打算用哪种呢?”(善意的坏笑)
“当然用Owner。。。等等,不行。我不确定要把哪个User的Case分享给哪个User。Criteria的话。。。我也不能确定Share的条件。”
“那该怎么办呢?”(单纯的善意的笑)
“我把OWD改成Control by parent。”(舒了一口气)
“你确定可以改成Control by parent?”(扬起嘴角)
“我记得Contact是可以的啊,Case应该也可以吧。。。。我确认一下。。。。哎呀,只能Private和Public二选一。”
“那怎么办呢?”(翘起二郎腿抿了口茶)
Apex Sharing!”(两眼放光)
“我说过的,能用标准功能就不要写代码。”(放下茶杯,duang一声)
“可是。。。标准功能也实现不了啊。。。”(委屈脸)
“Case与Account的关系不同于Account与Contact。Case有复数个标准爹。所以对于Case的访问权限控制,需要更加精细的选项。打开那个User的Role。”
“打开了。”
“看没看到一个叫Case Access的东西。”(背手昂头)
“看到了,现在写的是Users in this role cannot access cases that they do not own that are associated with accounts that they do own。哦~~~~~User无法访问自己拥有的Account所关联的不是自己拥有的Case。”
“没错,用户想看到自己的Account下面的所有Case的话,就把这个选项改成View或者Edit就行了。”
“马上去改!”

Salesforce的Number类型的小坑

我们知道,在Salesforce中,Number型的字段,整数位数与小数位数加一起,最多18位。
如果我们不要小数位,则可以存放18位整数。(18, 0)
假设这个整数为123,456,789,012,345,678的话,
来,跟我一起念,
十二京三千四百五十六兆七千八百九十亿一千一百二十三万四千五百六十七
这数字有多大,很大。

接下来,我们在画面输入这个数字。
然后在Developer Console里查询一下这个字段会发生什么呢?

咦?最后两位怎么回事?

好吧,我们在where语句里加一个条件,看看到底数据库里存的数字到底是多少。

Unknown error parsing query?解析query出错了?
马上拿去咨询了大神一下,大神淡淡的回答道:“加个.0”。

果然加.0就可以了!
这里推测是SFDC的SOQL解析器的锅。

我猜SFDC的SOQL解析器是这么处理的——————————
解析器在拿到字符串”123456789012345678″之后,
首先找一下包不包含小数点。
如果不包含小数点,则放到int里,
包含小数点,则放到double里。
由于SFDC里的Integer与JAVA里Int的最大值(INT_MAX)一样,都为2,147,483,647。
所以String to Int失败。

下面我们来验证一下这个脑洞,如果确实是遇到不带小数点的数字就放int里,那么理论上2,147,483,648就也会报同样的错误。
而2,147,483,647则不会报错。

脑洞证实。
所以当number字段里的值大于INT_MAX的时候,我们不得不手动加一个.0来告诉解析器,“把我放double里,谢谢。”
不过在Apex里倒是应该不会出现这个问题,因为你要查询一个大于INT_MAX的数字,首先就不能用Integer型的变量。。。

那么,Unknown error parsing query问题解决之后,我们也发现虽然查询结果显示的是123456789012345680,但仍然需要使用123456789012345678进行检索。这是怎么回事呢?

我换了一个工具进行检索。

原来由于位数太大,被科学计数了。

总之。虽然某些国家的货币金额之类的可能数字比较大,但能应用到这么多位数的情景应该不多,
能用其他类型就尽量使用其他类型,以免掉坑。

惊!List型Custom Setting惨遭SFDC抛弃,上位者居然是……

一夜之间,List型Custom Setting惨遭抛弃,SFDC发布冷血声明。
上位者从默默无闻变成人尽皆知。
SFDC开发者不禁议论纷纷。
到底是人性的扭曲,还是道德的沦丧。
接下来请看————————————谁杀死了List型Custom Setting?

继续阅读“惊!List型Custom Setting惨遭SFDC抛弃,上位者居然是……”

关于Stub API

Spring’17,Salesforce为开发者提供了一个强大的工具,Apex STUB API

看完官方文档提供的例子之后,感觉确实很美好,但又觉得没什么机会用。
不同于Java项目对框架和设计模式的极致追求。
我接手的Apex代码均为意识流散文诗式写法。根本没有抽象化,解耦等操作。

Stub Api是基于Java的Mocking Framework
mockito开发的。
使用Mocking Framework的前提是代码必须进行解耦,就是所谓的依赖注入(Dependency Injection)。
要求代码不能按业务直接写成流水账,而是将模块之间的强依赖解开。

比如,A类的构造强依赖与B类,如果没有B则没有A。

A a = new A();
//-----------------------------------
Class A {
    private B b;
    public A() {
        b = new B();
    }
    public String getName() {
        return b.getName();
    }
}

Class B {
   public String getName() {
       return "I'm the B";
   }
}

那么,问题来了,如果我有一个C类,返回“I’m the C”,我就要为C类新建一个A1类,在A1类中将A1与C进行强依赖。
如果需求越来越多,代码也随时越来越膨胀。
那么怎么改变这个局面呢?

B b = new B();
A a = new A(b);
-----------------------------------------------
Class A {
    private CustomObject co;
    public A(CustomObject cObj) {
        this.co = cObj;
    }
    public String getName() {
        reutrn co.Name;
    }
}

Class B extends CustomObject {
    public String getName() {
        return "I'm the B";
    }
}
abstract Class CustomObject {
    abstract public String getName();
}

这样一来,A和B的强依赖就解耦了,不再是每次new一个A,就必然得到B的内容,而是根据我传进去的B来决定A返回的内容。
如果想返回“I’m the C”,就不用再去新建一个A1类,想返回“I’m the D”,不用再去新建一个A2类。

只有依赖注入的写法才能进行方便的Mocking。

Stub Api可以做到的是,在解耦之后,为A类mock一个B类,C类。做到完美的单元测试(模块隔离)。
Whatever,用不上。至今还没见到过有控制反转思想的的Apex。
说句题外话,apex-enterprise-patterns(官方介绍文章)到现在还没推广开呢。

// 未完待续

Salesforce的StandardSetController使用Demo

先放Github地址
https://github.com/Kealthals/Salesforce-StandardSetControllerDemo.git

事情起因,是有人问我为什么StandardSetController无法保存Selected状态。
我觉得既然标准List View可以,那么使用StandardSetController应该也可以。
虽然这个Class我用的也不多,但还是动手写个一个小Demo验证了一下我的想法,虽然花了些小心思,但证明确实可行。
验证完毕,转念一想,既然已经动手了,就干脆把所有的methods都演示一遍吧。权当给自己留一个财富。

StandardController大家都比较熟悉,用来处理单条数据。模拟的是Create/Edit页面和Detail页面。
StandardSetController用的不多,因为模拟的是List View页面。标准List View页面已经很强大了,很少会遇到这种需求。
这个Demo也就是尽量做一个和标准List View类似的页面,时间有限,肯定做不到标准页面一般的好看和完美。
最低目标是将这个Class提供的method都使用一遍,除了一个不明所以的method之外,最低目标我觉得是完成了。
功能上,也提供了基本的
1. 罗列数据
2. 翻页
3. 选择数据(Selected)
4. 选择List View
5. 改变Page Size
6. 跳转指定页
7. Inline Edit(还不完美)
作为一个独立功能来讲,勉强达到了凑合着用的程度。
在功能实现的时候,又不断遇到了一些或新或旧的小问题,在大家的帮助下都找了比较好的小方案解决掉了这些小问题。
比如SFDC的autofocus,inputtext的输入类型限制等等。

继续阅读“Salesforce的StandardSetController使用Demo”

如何优雅的干掉VF的autofocus

How to remove VF input field’s autofocus?
最近在写StandardSetController Demo的时候遇到了一个逼死完美主义者的问题。
在VF加载之后,SFDC会非常Nice的,热心的,把第一个文本输入框设为焦点。
我推测sfdc的产品设计逻辑是下面这样的。
嗯。。。你设置一个输入框,代表着用户一定得输入点什么才能继续。
既然用户必须输入点什么的话,那么就必须用鼠标点一下这个输入框。
那么让我们来做点什么吧,帮用户先把输入框点上怎么样,节省用户的操作。
看呐,如果用户双手都在键盘上,他们连右手离开键盘的工夫都省下来了,用户一定会非常满意的。

对于大部分业务场景,这个贴心的小设计确实很有用。但有的时候会起反作用。
比如我的StandardSetController的Demo。
在List View画面,一般只有在数据列表最下方才有输入框,为了输入Page Size或者Page No。
但是不碰这几个输入框并不影响我使用List View。
不过,当默认Page Size非常大,画面超出一屏的时候,由于sfdc自动把第一个输入框设成焦点,导致画面滚动条直接被拖到了滚动条最下面。
还有当VF的第一个input项目是Date型的时候,sfdc的自动设置焦点机制,会触发datepicker,就像大晴天自动弹开的雨伞一样,造成另一场灾难。

研究了半天,虽然标准List View并没有这个问题,但还是没有找到比较官方的解决方法。
只好Hack一下了。

在VF中插入

   <script>
        function setFocusOnLoad() {}
    </script>

问题完美解决。

关于Salesforce的15位ID与18位ID

众所周知,Salesforce的Id有15位和18位两种。
18位ID的前15位与15位版本相同。
比如,有一条Account,其URL上的Id为0016F00002Dbbt5。
其中头三位001为Account的prefix(关于prefix,参照《salesforce的prefix和suffix》)
四到六位的6F0为Org Id的第4到6位。由于OrgId的唯一性,所以每个ID在整个SFDC世界都是唯一的。

同样是这条Account,使用工具取得的Id为18位的0016F00002Dbbt5QAB。
前15位与15位版本的ID相同,后3位则是根据前15位计算得来。

插个题外话,Org Id为00D开头的15或18位ID,第四位代表org所属的Instance。
比如说,我的OrgId为00D6F0XXXXXXXXX,那么此org所属的Instance是6对应的NA4。
第四位代码与Instance的对应关系表,请参照《Instance代码对照表
通过这个对照表,可以轻松的通过Org Id知道其所属的Instance。

包括某些官方文档在内,都将15位ID称为15位大小写敏感ID(the 15-character case-sensitive ID),18位ID称为18位大小写不敏感ID(the 18-character case-insensitive ID)。
那么问题来了,假如18位ID大小写不敏感,那是否就意味着
1. 0016F00002Dbbt5QAB
2. 0016F00002DBBT5QAB (全大写)
3. 0016f00002dbbt5qab (全小写)
代表同一条数据吗?
继续阅读“关于Salesforce的15位ID与18位ID”

Salesforce的Custom Permission

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),倒是给我们提供了另外一个用途,
正所谓,有心栽花花不开,无心插柳柳成荫。

继续阅读“Salesforce的Custom Permission”

URL Hacking之动态report条件

上回书说道(《salesforce的field-id与url-hack》),URL Hacking可以用来跳转到指定的页面与设定新建页面的default值。

除此之外,URL Hacking还可以用来改变report的条件。
比如说,有这样的业务场景————客户想知道当前访问的Lead都被哪些特定种类Campaign纳入为Campaign Member。
有的同学说了,这个简单啊,不就是Releted List嘛,我知道。
但是,由于Releted List无法进行过滤筛选,所以所有种类的Campaign信息都混在了一起,客户不矫情的话也许勉强凑合着用了。

除了做VF页面之外,还可以使用URL Hacking来实现。
首先,在Lead的详细画面上放一个custom link,点击之后打开一个Campaign Member的report。
然后设置好report的Show范围为“All Campaigns”,如果是其他report,还要设定好时间范围。
只要实现每次点击custom link跳转到report时候,都能动态的设置campaign的record type与当前lead的Id,就可以实现。

// 接下来是重点
继续阅读“URL Hacking之动态report条件”

本博客引用Salesforce官方文档的说明

最近有一些同学说我写的文章骗人。
弄得我一脸黑人问号。

深入交流了一下才知道,是说我提供的所有官方链接都打不开。
无论点开哪个链接都是404。

这里我不得不澄清一下,
我所引用的所有链接都是基于英文版的sfdc文档。
由于并不是所有的官方英文文档都有对应的中文版,
所以,浏览器默认语言是非英语的同学,很容易会碰到404错误。

看到404没关系,如下图,将语言改成英语就可以了。

最后,还是想说一句,毕竟sfdc是英语母语者开发的,想好好做sfdc还是学好英语吧。