Коллеги, попался мне тут на глаза один из списков констант (ConfigurationConstants, в частности).
И мне кажется, что это очень плохая практика - зашивать эти Id в код, особенно, не имея возможности их переопределить.
Категории активности, которые администратор может на лету удалить, добавить, поменять
Типы адресов, которые тоже довольно гибко должны меняться
Средства связи, которые если сменить, то рухнет вся синхронизация с полями
Туда же типы договоров и другие полезные вещи.
В bpm'online есть прекрасные инструменты - справочники и системные настройки. Используйте их, а не создавайте потенциально опасные места для работы системы
Понравилась ли вам эта идея?
Здравствуйте, Владимир!
В базовой версии продукта данная схема недоступна для редактирования. Так же тех.поддержка Террасофта рекомендует в случае доработок базовой версии продукта выполнять замещение базовых объектов/схем/кода, чтобы была возможность откатиться назад.
Обычно внесением изменений в конфигурацию системы занимаются опытные разработчики, которые знают что необходимо делать и для чего необходимы данные ID.
Для рядовых пользователей зачастую предоставляются рекомендации с использованием справочников и системных настроек и крайне редко возникает необходимость вносить изменения через конфигурацию.
Так же я передам информацию по данному вопросу в отдел разработки для рассмотрения описанной вами проблемы и возможного нахождения её решения.
Гриценко Игорь,
А как в данном случае замещать модуль констант? Если создавать новый, то приходится за двумя схемами следить, чтобы не пересекались
Да, это проблема! Например, сейчас невозможно удалить организацию с ИД 'E308B781-3C5B-4ECB-89EF-5C1ED4DA488E', иначе сломается интеграция с LDAP, которая использует эту константу. http://prntscr.com/h55ikc. БУДЬТЕ БДИТЕЛЬНЫ!!!
Предлагаю ссылаться на системную настройку, в которой хранить ИД организации по умолчанию.
Чубко Илья пишет:
А как в данном случае замещать модуль констант?
Я так понимаю как любой другой модуль: создать замещающую схему и перекопировать туда всё. От слова совсем всё(включая localizable).
По теме, насчёт зашивания в код:
Очень интересно, как тогда работать с константами. Допустим у меня 10 страниц и 3 модуля. Везде так или иначе надо проверить вхождение пользователя в новую роль. И мне легче 1 раз создать поле в модуле с Guid-ом роли и во всех схемах его использовать при сравнении, чем потом по 30 раз везде всё менять(вдруг guid роли изменится). Ну и единственная проблема - нужно 1 в 1 роль перенести на прод.
А как реализовать всё это через справочник? вбивать в Name Constants.Roles.NewSysAdmins, а в другое поле значение? И так каждый раз для каждой константы? такое себе занятие. В сист. настройках то же самое, да и не для того они созданы. + надо будет в схемах реализовывать вычитку значений через esq/пилить mixin, куча гемора.
Резюмирую, по мне, так в новом проекте делаем свои константы и используем их по надобности, базовые не изменяем (да и зачем это вообще это надо)
Варфоломеев Данила пишет:
А как реализовать всё это через справочник? вбивать в Name Constants.Roles.NewSysAdmins, а в другое поле значение? И так каждый раз для каждой константы? такое себе занятие. В сист. настройках то же самое, да и не для того они созданы. + надо будет в схемах реализовывать вычитку значений через esq/пилить mixin, куча гемора.
Придумать механизм GetConst("OurCompanyID"), GetConst("PhoneID"), например.
Гриценко Игорь пишет:
Для рядовых пользователей зачастую предоставляются рекомендации с использованием справочников и системных настроек и крайне редко возникает необходимость вносить изменения через конфигурацию.
Как раз обычные администраторы (в компаниях без разработчиков) и приводят в порядок справочники, удаляют лишние типы, создают свою компанию, удаляют OurCompany.
Где есть список рекомендаций, что в системе нельзя удалять, чтобы не посыпалась функциональность?
Варфоломеев Данила пишет:
Я так понимаю как любой другой модуль: создать замещающую схему и перекопировать туда всё. От слова совсем всё(включая localizable).
Да, а потом отслеживать в каждой версии, какие константы Terrasoft добавил в этот модуль? И это решение для простых пользователей on-demand?
Варфоломеев Данила пишет:
Резюмирую, по мне, так в новом проекте делаем свои константы и используем их по надобности, базовые не изменяем (да и зачем это вообще это надо)
Мы наоборот, выносим их в System settings. И тогда запрос клиента при смене политики в 90% случаев решается консультацией по изменению системной настройки
Варфоломеев Данила пишет:
Резюмирую, по мне, так в новом проекте делаем свои константы и используем их по надобности, базовые не изменяем (да и зачем это вообще это надо)
Зачем? Например, клиент хочет вместо одной "своей организации" сделать несколько, то есть, завести филиальную сеть. Как вы думаете, с чего он начинает? - С удаления всех организаций. Он прав! Почему одна организация должна быть особенной? И вы не напишите в мануале прямым текстом "Не удаляйте никогда акаунт с ИД ... A поменяйте ему название на нужное!" Потому что это, мягко говоря, не профессионально. Посмотрите на мир глазами клиента!
В проектных решениях интегратор или клиент вольны делать, что и как им нужно: константы, настройки, справочники. Но зашивать константы в ядро, которых суть есть Guid'ы из пользовательских объектов-справочников, и не давать их менять в кастомизации - это не комильфо, связывает по рукам и ногам.