Dynamics 365 POA表记录的产生

时间:2023-03-08 16:26:36

微软动态CRM专家罗勇 ,回复314或者20190311可方便获取本文,同时可以在第一间得到我发布的最新博文信息,follow me!我的网站是 www.luoyong.me 。

前面的博文 Dynamics 365 POA表记录的查询 讲了查看POA表的记录数,那这些记录怎么来的呢?我今天就根据文章 Excessive PrincipalObjectAccess Table Growth in CRM 4.0 from the Reparent – Cascade All Setting 来讲解下。

来源主要分为如下四个途径。

1. 记录更改Owner后和共享该的所有可能权限给该记录原来的Owner。这个行为会不会发生与一个系统管理配置项目有关,在【设置】>【管理】>【系统设置】中可以查看,默认是否的。如下图所示的【设置是否与原始负责人共享重新分派的记录】。

Dynamics 365 POA表记录的产生

这样产生的记录的AccessRightsMask字段会有值(不会为0),但是InheritedAccessRightsMask字段值为0。我修改后实际做了一个分派的例子,分派后在POA表的确创建了一条记录。可以看到该记录的AccessRightsMask字段值为 852023,PrincipalTypeCode值为8,因为是共享给个人。ObjectTypeCode的值为被共享记录对应实体的ObjectTypeCode,ObjectId为被共享记录的Id,PrincipalId为给想给的对象的Id。

如果继续分派给我自己的话,还会增加一条POA记录,共享权限给分派前的记录的Owner。我在分派给别人的话,不会增加给我自己的共享记录了,应该是修改。POA表有如下的唯一索引。

ALTER TABLE [dbo].[PrincipalObjectAccess] ADD  CONSTRAINT [UQ_PrincipalObjectAccess] UNIQUE NONCLUSTERED
(
[PrincipalId] ASC,
[ObjectId] ASC,
[ObjectTypeCode] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80) ON [PRIMARY]
GO

界面上是可以通过点击【共享】按钮看到该记录得共享记录的,实例如下:

Dynamics 365 POA表记录的产生

共享给的权限很大,所有权限。若被共享用户本来不能删除这个记录,但是通过这个共享给了他删除权限,他是可以删除的,所以谨慎使用该功能,在项目上我们一般不启用【设置是否与原始负责人共享重新分派的记录】这个选项,还好这个默认就是关闭的。

如果我把这条记录删了,这些共享记录在POA表中不会立即自动删除,是由每天运行的服务(Operation Code为14,名称为 Deletion Service)来删除的,请参考  More juicy details on Dynamics CRM 2011 Asynchronous Service’s maintenance jobs 。

2.直接共享。这个容易理解,这样产生的POA记录的AccessRightsMask字段会有值(不会为0),但是InheritedAccessRightsMask字段值为0。下面我做一个表来列出共享权限及其对应的AccessRightsMask值,但是我估计啊,这个值不一定对应对,别对这个表太当真。

共享权限 AccessRightsMask字段的值
1
读&写 3
读&写&删除 65539
读&写&删除&追加 65559
读&写&删除&追加&分派 589847
读&写&删除&追加&分派&共享 851991
读&追加 21
读&共享 262145
读&写&分派 524291

3. 【行为类型】为【父】这种类型导致的共享,主要是因为【重定父级】这个选项的行为为【父】导致的。这里解释下,我这里有两个实体,一个是工单实体,一个是工单项目实体,假设我设置他们俩之间的【行为类型】为【父】。

Dynamics 365 POA表记录的产生

现在有一条名称为【测试工单】的工单实体记录,记录的owner为我这个系统管理员。我用另外一个账号,新增一个工单项目记录和这个【测试工单】关联。保存后这样会产生一条POA记录,该POA记录的AccessRightsMask字段字段值为0,但是InheritedAccessRightsMask字段有值(不为0)。当然如果父记录的owner就是创建子记录的用户的话,这个POA记录不会产生。这种产生的共享记录点击【共享】按钮后在界面上看不到,但是在POA表中会存在记录。据我观察,如果重新分派后的owner和子记录的owner一样,那么POA记录表中子记录的AccessRightsMask字段字段值为0,且InheritedAccessRightsMask字段值为0。这种产生的共享记录点击【共享】按钮后在界面上看不到,但是在POA表中会存在记录。但是每天运行的系统作业(AsyncOperationType = 14)来定期运行来清理它(删除这条记录)。关于这个作业的临时修改运行时间请参考 Dynamics 365中的公告(Post)分析。所以要删除POA表记录,我认为一个方法就是,就是重新分派父记录,使其和子记录的owner一样,这样由【重定父级】产生的共享会被系统作业(AsyncOperationType = 14)运行后自动删除。当然,建立这种1:N父关系的那个字段的值如果清空,那么产生的POA记录也会被被系统作业(AsyncOperationType = 14)运行后自动删除。

如果要清除大量的由【父】这种行为类型的POA记录通过更改父记录Owner或者清空子记录和父记录做关联的字段值的话,耗时会比较就。这里介绍一种方法,可以执行类似如下的SQL,处理后这些记录会被系统作业(AsyncOperationType = 14)运行后自动删除。如果是Dynamics 365 Customer Engagement Online,可以开case来请求工程师帮忙处理。

update principalobjectaccess
set inheritedaccessrightsmask=0
where inheritedaccessrightsmask !=0 and accessrightsmask=0

特别提一下活动实体,默认情况下支持活动的实体和该所有的活动实体的【行为关系】为父,这样的父行为也会产生一条POA记录,POA记录的ObjectTypeCode为4200,AccessRightsMask字段字段值为0,但是InheritedAccessRightsMask字段有值(不为0)。该POA表对应的ObjectId是活动的Id,但是这里并不知道是哪种活动。当然啦,你可以拿这个ID用Web API查出来是那种活动,如下示例,这个返回的就是活动实体的逻辑名。

https://demo.luoyong.me/api/data/v9.0/activitypointers(94321554-6D44-E911-A81D-000D3A5129C5)?$select=activitytypecode

若是到数据库中查询,示例如下,返回的是实体的ObjectTypeCode:

select ActivityTypeCode from ActivityPointerBase where ActivityId='94321554-6D44-E911-A81D-000D3A5129C5'

4. 间接共享。就是关系行为中的【重定父级】和【共享】设置【全部级联】、【可用项的级联】、【用户负责项的级联】就很可能产生POA记录。比如【共享】设置为级联,共享了父记录,会产生POA记录自动共享子记录。如果【共享】设置为级联,强烈建议【取消共享】也设置级联,这样取消共享父记录的共享后,其子记录相关的共享记录会被系统作业(AsyncOperationType = 14)运行后自动删除。

总结一下,POA记录表中子记录的AccessRightsMask字段字段值为0的记录点击【共享】按钮看不到,一个用户/团队对一条记录最多产生一条POA记录。

你会发现有些共享是不需要的,特别是后两种自动产生的共享,如果用户本身就对这些被共享的记录有权限,就没有必要共享了,可以对POA表做一些清理,清理POA表可以参考:How to control PrincipalObjectAccess table growth in Microsoft Dynamics CRM 2011