Динамика CRM 2011: добавление полей формы не-сущности

Question

Я продолжаю искать себя, чтобы добавить поля в формы CRM, которые фактически не представляют физические поля в сущности. Я хочу, чтобы эти поля были отправлены в сообщении «Обновление», в интересах моих плагинов ...

Например, представьте себе что-то вроде функциональности контактов/адресов из коробки. Основной контактный адрес отображается как набор полей в форме контакта. Однако на самом деле происходит некоторая магия за кулисами, которая вызывает создание Адреса для контакта, содержащего данные адреса. Я действительно не хочу воспроизводить это, но это хороший пример ...

Теперь я знаю, как написать плагин, который берет поля адреса, введенные в сообщении Создать/Обновить, и фактически записывает их в Вместо этого адресуйте объект. Это достаточно просто. Кажется, что трудная часть убеждает CRM отображать поля в форме, чтобы пользователь мог ввести данные адреса.

Единственный способ, которым я могу это сделать, - создать «поддельные» поля в форме Contact-equivilent, чтобы редактор формы позволял мне добавлять поля в диалог. Затем я должен отфильтровать эти атрибуты в плагине, поэтому поддельные поля фактически не записываются в БД.

Это будет работать, но включает в себя заполнение схемы БД поддельными столбцами, которые (или должны) никогда не имеют в них данных. Это делает будущую cusomisation системы более запутанной, поскольку на всех графических интерфейсах есть деликатные поля под названием «НЕ ИСПОЛЬЗУЙТЕ - Address1». Проблема ухудшается, когда мне нужно поддельное поле Lookup - это связано с созданием фальшивых отношений.

Итак: Есть ли способ достичь того же самого, не выгружая фальшивый мусор в схему базы данных?

Возможно, существует какой-то способ создать поле формы для атрибута в Javascript в форме, чтобы атрибуты были включены в сообщение Update?

Несомненно, я понимаю, что я мог бы IFrame или Silverlight что-то сделать для этого, но я предпочел бы использовать поля формы подлинной формы CRM и обрабатывать данные в окне обновления/создания сообщения.

Answer 1

К сожалению, вы уже упоминали два варианта, о которых я могу думать: поддельные поля или пользовательские IFrames.

Я знаю, что он чувствует себя «грязным», но на самом деле у меня не было особых проблем с созданием фальшивых полей. Стандартизованные соглашения об именах - ваш друг. Я предпочитаю поддельные поля над IFrames, потому что пользователи могут все еще запрашивать и фильтровать их в Advanced Find, отчетах, представлениях и т. Д.

Просто убедитесь, что они только для чтения и убедитесь, что ваши плагины не проглатывают исключения - вы хотите, чтобы исключения были пузырьками и отменить транзакцию вместо возможности обновления основной записи без детей.