我正在设计 CRM 中的审批系统，需要一些有关安全设计的意见。我正在使用的实体具有用户/团队级别的 R/W 权限。整体实现有点复杂，但为了使这个问题简单，请考虑系统中涉及的以下两方:
请求者:需要对其创建的请求进行读/写访问。
审批者 团队:这些是预定义的团队，用户将批准/拒绝请求。需要对需要其批准的请求进行读/写访问。
问题: 如何同时为请求者和审批者团队提供读/写访问权限？由于 CRM 中的记录不能有多个所有者，因此“所有者”字段一次只能包含其中之一(请求者或审批者团队)。
我可以使用共享功能想到两种解决方案，并想确认我的理解:
a. 将请求者设置为记录所有者并以编程方式与审批者团队共享记录。这种方法的问题在于，即使我与审批团队共享记录，我也无法在主表单上显示共享详细信息(这是要求)。
b. 将审批者团队设置为记录所有者，并使用访问模板以编程方式与请求者共享记录。
是否有更好的解决方案来处理此要求，以防我错过任何 OOB 可能性？
最佳答案
嗯，我相信你可以通过一些编码来使解决方案 A 工作(我不确定你是否不介意编码，但我们在 StackOverflow 上，所以我认为你应该考虑这一点)。 首先，设计取决于一个简单的问题 - 该请求应该与多个团队共享，还是只与单个团队共享？单个团队很简单 - 只需在请求上添加一个查找，它将指向一个团队。当这个团队被填满时(我假设这个团队的选择是以某种方式自动完成的，但这并不重要，因为在任何情况下你都必须以某种方式选择团队)，你运行一个简单的插件来共享记录对于这支球队。使用SDK共享非常简单，只需使用GrantAccessRequest即可:
var grantAccessRequest = new GrantAccessRequest
{
PrincipalAccess = new PrincipalAccess
{
AccessMask = AccessRights.ReadAccess | AccessRights.WriteAccess,
Principal = teamEntityReference
},
Target = requestReference
};
因此，在请求的形式上，您将保留请求的所有者，并将查找指向正在处理此请求的团队。当然，您可以通过例如在请求被接受或拒绝或请求的查找发生更改等时取消共享来进一步完善它。这将使 POA 表更加满意，因为共享大量记录可以导致快速增长该表的数据，因此如果不再需要共享，取消共享记录非常重要。
如果您想共享给多个团队，您仍然可以在您的请求和团队之间创建 N:N 关系，并只需在请求和团队之间关联消息上的插件中共享您的请求(这是 Access Teams 之前的标准选项)为用户引入，仍然是团队的唯一选择)。这种关系可以在请求表单上显示为子网格(它看起来像访问团队子网格)。
当然，为了防止用户自己共享请求记录(在这种情况下，您的查找/子网格中不会有团队)，他们不应该具有共享权限。该插件应该在管理上下文中进行共享。
更新: 至于评论中的 POA 考虑因素:这两种解决方案都会使您的 POA 增长，因为对于这两种解决方案，您都必须与团队或用户共享请求。如果您将使用访问团队，则每个请求仍将有一个 POA 条目(因此每年 100K 条目)。我相信这里最重要的事情是请求结束其生命周期时会发生什么。如果它不必对团队可见，那么在它被接受/拒绝后，您应该简单地有一个机制(插件或某些及时运行的自定义应用程序)来取消共享不再需要共享的所有请求，保留您的 POA 表大小合理。
还有另一种处理场景的方法，不需要太多的共享/取消共享逻辑。您可以创建一个与 Request 具有 1:N 父关系的“Request Acceptation”实体。因为它是父关系，所以拥有请求的用户将看到所有“请求接受”，并且“请求接受”将由适当的团队拥有(因此只有该团队才能访问)。当然，我对业务逻辑一无所知，但我假设“请求接受”只能包含与团队相关的信息，这些信息可以在插件或工作流程中复制。
更新2:正如我刚刚看到的，您无法在稍后阶段取消共享记录。但我假设在某个时间点请求已完成/接受/完成/拒绝或其他。如果此时团队和用户都应该有权访问此请求，那么创建某种单独的实体“存档请求”可能是一件好事，该实体不会被共享，只需为所有有兴趣查看的主体进行克隆此信息并删除原始请求。这个想法有很多变体，我希望您能理解并根据您的场景进行调整
关于dynamics-crm - 如何同时为两个用户/团队分配 R/W 所有权，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43387581/