Видимо, нужно разрабатывать что-то подобное механизму подбора продуктов в заказе. Или, ещё боле похоже по смыслу, подбор листингов по лиду в bpm’online real estate (см. стр. 27). И то, и другое — сложная логика, нужно разбираться, как она реализована.

Здравствуйте, Павел.

Изменения дизайнера - это сериализированная в БД (в таблицу EditPageModification) последовательность действий над полями страницы. То есть, если вы добавляете, перемещаете, а затем скрываете поле, то в таблицу будет занесено примерно следующее: добавить поле А, передвинуть поле А, скрыть поле А.
Если вы впоследствии удалите колонку, на которую ссылается поле А из объекта, то при попытке открыть страницу будет возникать NullReferenceException, так как при выполнении последовательности действий дизайнера приложение будет ссылаться на несуществующую более сущность. Нужно изменять последовательность действий дизайнера в БД.

Вторым важным аспектом, является то, что действия дизайнера отрабатывают после выполнения structure.userCode. И если это 7.0.0 (в которой еще не была реализована возможность расширения finalizeStructure), то вы не сможете наложить доп. логику на созданные с помощью дизайнера поля в замещающем модуле.

Рекомендую, если вы еще не разобрались в тонкостях работы дизайнера и не знаете всех его нюансов, добавлять с его помощью поля, которые впоследствии не будете переименовывать или скрывать.

Спасибо, Максим!
Со стороны пользователя кажется очевидным безболезненность добавления и потом удаления того, что было им самим добавлено- ведь то, что разработчики сделали не трогается.
Теперь понятно.