Salesforce关于Update Records with Inactive Owners权限

// 老鸟直接去下面看重点

Salesforce作为平台，无论是Standard Object还是Custome Object，都提供了默认的系统字段。
这些字段普通用户无法直接更新与编辑，只有系统才可以修改，以此作为审计信息，保证数据的可靠性。

但是，由于并不是每个使用Salesforce的组织都刚刚步入信息化。
所以，从Legacy System迁移到我们全球最先进的CRM系统——Salesforce的时候，必然会涉及到数据迁移。
有的同学说了，数据迁移简单啊，把数据从原来的系统抽出来，然后插入到Salesforce里。
我们知道，如果直接导出，再插入的后果是导致创建日期等一众字段都会变成数据导入那天。
那么，如果有功能是基于创建先后顺序的时候该怎么办，五年前的数据将会比昨天创建的数据更靠前。

为了应对这种情况，Salesforce提供了Set Audit Fields upon Record Creation与Update Records with Inactive Owners两个权限。
开启的方法为：
1. Setup -> Build -> Customize -> User Interface -> Enable “Set Audit Fields upon Record Creation” and “Update Records with Inactive Owners” User Permissions 勾选
2. 创建一个PermissionSet将Set Audit Fields upon Record Creation与Update Records with Inactive Owners分别勾选。将此PermissionSet分配给需要的User。
3. 在Custom Profile里将Set Audit Fields upon Record Creation与Update Records with Inactive Owners分别勾选。
这里需要注意的是，System Admin是标准Profile，所以只能使用PermissionSet。

Set Audit Fields upon Record Creation顾名思义，就是在Insert数据的时候，可以设定Audit Fields。一次操作成型，不能再Update。

// 接下来是重点

那么Update Records with Inactive Owners权限呢？
看字面意思是，可以更新Owner是Inactive User的数据。
那就是说，如果没有此权限的话，Owner是Inactive的数据就不让更新呗？
唔。。。貌似印象里确实是这样的，不过为了严谨，还是试一下吧。
咦？ 在没有赋予权限的情况下，可以更新啊。。。。。。难道Salesforce又出Bug了？
去翻了一下Release Note, 好玩的地方来了。
Spring’15提到了，这么一点：
Previously, only administrators were able to edit accounts, opportunities, and custom object records that are owned by inactive users.
当管理员当惯了。。。原来我是一直有特权的，而且这个特权在Spring’15之后阳光普照给了所有人。对，是所有人，和这个Permission没有半毛钱关系。
那。。。既然所有人都可以编辑Owner是Inactive User的数据了，这个权限到底是用来干啥的?

继续看Release Note，发现这个权限是Winter’16加进来的。
如果这个权限真的如我假设的，是用来控制编辑Owner是Inactive User的数据的能力的话，
Spring’15已经开放给了所有人，Winter’16又加个开关，也不符合产品逻辑啊。况且，这个开关还并不好用。

针对这个权限，官方并没有给出太多的解释，
唯一提到的一句解释是”Update owner and sharing-based fields on records with inactive owners.”
嗯？。。。。。sharing-based fields又是什么，官方文档也查不到这个概念。

后来经过和官方长达一个月的沟通，终于弄明白了这个权限的来龙去脉。
首先，如我所料，这个权限果然不是字面理解的意思。
编辑Owner是Inactive User的数据这件事，对所有人开放是已经板上钉钉的。
这个权限的其实是控制Reparent时的行为。
什么是Reparent？
举个例子，
如果Account1的Owner1是Active的；
Contact1为Account1的子记录，Owner为已经Inactive的User2。
那么当尝试将Contact1的Parent记录改成Account2时，就会报错——”owner is inactive, cannot reparent record”
如果拥有Update Records with Inactive Owners权限的话，同样的行为就不会报错。

Update Records with Inactive Owners权限，一共掌管两个行为：
1. Insert数据的时候，Owner是Inactive User。
2. Re-parent的时候，子记录的Owner是Inactive User。

其实以上两个行为背后是一个同样的机制。
如果子记录与父记录的Owner为不同的User的时候，Salesforce会自动的为子记录的User，创建一条父记录的Share数据，以维护Salesforce的数据访问性体系。（Reason:Associated record owner or sharing, Root Cause:ImplicitParent)
但是Share表不允许为Inactive的User创建Share记录。
所以当Reparent的时候，系统自动创建Share记录会失败。
而这个权限，就是开启一个例外，在reparent的情况下，仍然可以为Inactive User创建特定类型的Share记录。
随后我又试验了一下开启权限的时候，手动创建Share记录，仍然不可以，说明它并不是针对整个Share表的特权，仅仅是针对ImplicitParent的一个例外。（ImplicitParent手动创建时并不可选）

所以，在官方文档里提到的sharing-based fields，就是指的这种在更改时，会触发系统自动创建Share记录的Field。
希望以后官方可以更新下说明文档和权限的名字，使其作用更清晰明了一点。

// 2017-12-18 补充

关于Sharing还想多说两句。根据官方文档。
虽然Share的Reason有很多，Access Level也有很多。
但并不是每种选项都可以人工设置的。摘抄如下。

下面是只有sfdc系统才能设置的Reason和rowCause

Reason Field Value	rowCause Value
Account Sharing	ImplicitChild
Associated record owner or sharing	ImplicitParent
Owner	Owner
Opportunity Team	Team
Sharing Rule	Rule
Territory Assignment Rule	TerritoryRule

下面是User可以使用的Reason和rowCause

Reason Field Value	rowCause Value
Manual Sharing	Manual
Territory Manual	TerritoryManual

除此之外，Apex可以设置自定义的Reason与rowCause

而Access Level有4种
Private（None）
ReadOnly（Read）
Read/Write（Edit）
Full Access（All）
其中Full Access只有通过系统管理的Sharing才能使用，其他三个可以由用户使用。