基于选项集值的CRM账户实体记录权限控制方案咨询

嘿，这个需求我太熟了——安全角色确实搞不定这种基于记录属性的权限控制，因为它是针对整个实体的，没法区分slaved和mastered类型的账户。给你几个靠谱的方案，按推荐程度排序：

1. 业务规则（无代码轻量化方案） #

这是最省心的方案，不用写代码就能搞定大部分场景：

• 打开账户实体的主表单，新建一条业务规则
• 设置触发条件：账户类型 等于 slaved
• 添加动作：选择「设置表单状态」，把表单改成只读模式
• 额外优化：如果想阻止用户创建slaved类型的账户，可以在创建表单里加一条业务规则——当用户选择slaved类型时，显示错误提示文本，同时禁用「保存」按钮。不过要注意，业务规则没法完全拦截API或者批量操作的创建请求，如果需要严格控制，得配合下面的插件方案。

2. 插件（严格底层控制方案） #

如果需要彻底阻止所有渠道（表单、API、批量编辑）的非法操作，插件是最优解：

• 注册两个插件执行步骤：
  • 针对Create消息（账户创建）：在Pre-operation阶段检查账户类型，要是是slaved，直接抛出错误阻止创建
  • 针对Update消息（账户编辑）：同样在Pre-operation阶段检查目标记录的类型，slaved就抛出错误拦截编辑
• 给你个简单的C#代码示例参考：

public void Execute(IServiceProvider serviceProvider)
{
    var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
    var targetEntity = context.InputParameters["Target"] as Entity;

    // 只处理账户实体
    if (targetEntity?.LogicalName != "account") return;

    // 检查账户类型是否为slaved
    if (targetEntity.Contains("accounttype") && 
        targetEntity.GetAttributeValue<string>("accounttype") == "slaved")
    {
        throw new InvalidPluginExecutionException("无法创建或编辑标记为slaved的账户记录");
    }
}

• 注册插件时记得选择正确的消息、阶段，并且用系统用户身份执行，避免权限问题。

3. 记录级安全（RLS）+ 共享规则（适合特定关联场景） #

如果你的slaved账户是和特定用户/团队绑定的，也可以试试这个方案，但维护成本稍高：

• 创建两个安全角色：一个给账户实体只读权限，另一个给创建/编辑权限
• 设置共享规则：把所有slaved账户共享给只读角色的用户，mastered账户共享给编辑角色的用户
• 缺点是如果账户类型经常变动，需要手动或者用自动化流程更新共享规则，灵活性不如前两个方案。

总结一下：如果只是前端表单控制，用业务规则就行；要严格控制所有操作，选插件；如果是基于用户/团队的关联权限，再考虑RLS+共享规则。

内容的提问来源于stack exchange，提问作者KCodeR