“求救。用户说看不到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就行了。”
“马上去改！”
月度归档： 2018 年 3 月
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？