不得不说,有些事情不亲自经历过,你是永远无法记在心里的...

看到这鲜红的报错小伙伴们应该就知道了,没错一如往常一样,小喵又遇到问题了.

INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY  

还好Salesforce 为我们提供了异常转态 的查询 ,也为我们进行了一定的翻译,要不然光看这个错就很懵懵的.

An operation affects an object that is cross-referenced by the specified object, but the logged-in user doesn’t have sufficient permissions on the cross-referenced object. For example, a logged-in user attempts to modify an account record, and the update creates a ProcessInstanceWorkitem. If the user doesn’t have permission to approve, reject, or reassign the ProcessInstanceWorkitem, this exception occurs.

操作会影响指定对象交叉引用的对象，但登录用户对该交叉引用对象没有足够的权限。例如，登录的用户尝试修改帐户记录，更新将创建ProcessInstanceWorkitem。如果用户没有批准、拒绝或重新分配ProcessInstanceWorkitem的权限，则会发生此异常。

翻译了一下官方的英文,看得出来,是因为权限不足才导致的错误.

但是小喵查看后发现对象的权限是有的,于是小喵问了一下公司的前辈,前辈看了看错误数据、简档、对象的权限,又看了看程序,当看到程序的时候,前辈就知道是哪里的问题了,是因为小喵的程序 声明的有误.

在Salesforce 中有三类声明类的方式,分别是将类声明为with sharing,without sharing,inherited sharing;

// with sharing 声明
public with sharing class TestCls {

}

// without sharing 声明
public without sharing class TestCls {

}

// inherited sharing 声明
public inherited sharing class TestCls {

}

//无声明
public class TestCls {

}

四种声明区别如下:

     *  with sharing:类声明称with sharing类型，则需要走sharing settings中的sharing rules；

     *  without sharing:类声明称without sharing类型，则不需要走sharing settings中的sharing rules;

     * 无声明：类无声明上述两种类型，则默认走sharing rules,如果别的类调用此类，则按照别的类的sharing rules 校验。

     *  inherited sharing ： 用inherited sharing 修饰的Apex类和省略共享声明的Apex类有明显区别。如果该类用作Apex事务的入口点，则省略的共享声明将运行为without sharing。但是，继承共享确保默认情况下与共享一样运行。声明为继承共享的类仅在从已建立的无共享上下文显式调用时作为无共享运行。

总结：具体用哪个形式，看项目需求，如果项目需要可控度高，防止因为salesforce自身的坑而无可奈何，则可以通过without sharing形式，校验自己用apex代码搞定；如果需要salesforce封装的sharing功能进行快速开发，可以通过with sharing。

今天的分享就到这里了,

(^_^)~喵~!!