【问题标题】:Prevent certain optionset changes in CRM via plugin通过插件防止 CRM 中的某些选项集更改
【发布时间】:2015-12-22 17:45:10
【问题描述】:

当有人编辑选项集时,是否可以让插件进行干预?

如果存在引用它们的实体,我会认为 crm 会阻止删除选项集值,但显然情况并非如此(有许多引用不再存在的选项的孤立字段)。是否有消息/实体对可用于检查是否有实体使用要删除/修改的值并在有时停止它?

【问题讨论】:

  • 我从来没有听说过这样的自定义事件(你可以注册一个插件——我不会把它列为答案,以防它确实存在)。一般来说,任何有权更改选项集值的人都应该具备足够的技术来理解这样做的含义,并且应该在弄乱数据模型之前进行尽职调查。对不起,我不能提供更多帮助。
  • 理论上数据管理员确实知道其中的含义,但是人们健忘会导致不可避免的问题。除非系统阻止用户做一些愚蠢的事情,否则他们会在有足够时间的情况下这样做。

标签: dynamics-crm-2011


【解决方案1】:

不确定这是否可行,但您可以尝试在执行方法上创建一个插件,并检查上下文中的输入参数以确定正在处理的请求类型是什么。可以肯定的是,您会想要为本地 OptionSets 寻找 UpdateAttributeRequest,或者为两者寻找 UpdateOptionSetRequest。然后,您可以运行其他逻辑来确定哪些值正在更改,并确保数据库值正确。

对此的最大警告是,即使您拥有中等数量的数据,我猜您也会达到插件执行的 2 分钟限制并且它会失败。

【讨论】:

  • 这听起来有道理,我明天去看看。幸运的是,我们是一个小型组织,其记录以数千而不是数百万/十亿计,因此时间限制不应该成为问题(手指交叉)。如果可行,我会将其标记为答案!
  • 好的,所以我终于开始尝试您的建议,不幸的是我无法让它发挥作用。我确认我的插件已被激活,只需单击各种屏幕即可激活“执行”步骤。奇怪的是,从选项集中添加/编辑/删除选项不会触发“执行”消息。出于绝望,我还尝试了“SetState”和“SetStateDynamicEntity”,但没有运气。
  • 感谢您的想法,我认为我不能将其标记为答案,但我会赞成它,因为它有助于消除可能性。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-01-21
  • 1970-01-01
  • 1970-01-01
  • 2011-01-01
  • 2015-04-05
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多