Бизнес-правила (новые), недоступность поля "Добавить действие"
В мастере "бизнес-правил" (новые, в 7.10)
По какой-то причине недоступен пункт "Добавить действие", т.е. условия можно добавлять не ограничено, а вот действие - только одно. Промелькнула мысль, что "оно так устроено", но само наличие, пускай и не активного, пункта "Добавить действие" косвенно говорит о том, что действий может быть несколько на один набор условий (что вполне логично).
Я что-то делаю не так ?
Нравится
Это нормально, вам нужно под каждое действие сделать отдельное БП. Так же работали и рукописные БП, посмотрите на академии.
Как пожелание:
Иметь возможность выполнять группу действий основываясь на группе условий - весьма ожидаемый кейс.
Зачастую доступность/видимость/обязательность десятков полей, зависит от единой группы условий.
PS: мы понимаем что тут необходимо повесить требуемые конечные свойства видимость/доступность/обязательность - на атрибут и управлять его состоянием в логике.
Но, ИМХО, в бизнес-правилах, такой кейс очень будет "к месту".
и еще...
само собой тут не хватает "противоположенных" действий:
Если есть действие "Сделать поле редактируемым", то по идее должно быть и "Сделать поле недоступным"
Если есть действие "Скрыть поле", то должно быть и "Показать поле"
и так далее...
Можно конечно отталкиваться от "противоположенности" условий, но в таком случае необходимо предусматривать особые начальные состояния.
Например чтобы эффективно использовать "Показать поле на странице"
Его для начала следует "скрыть", т.е. описать его как изначально скрытое, в то время как по умолчанию (например из мастера) поля создаются видимыми.
По этому логичнее скрывать его там где оно не нужно, чем показывать его везде где оно нужно.
ну я думаю кейс понятен :) одно бизнес-правило, против нескольких бизнес-правил и работы со схемой, для реализации одного и того же поведения.
:) и еще немного.
В мастере редактирования бизнес-правил, очень не хватает сортировки, а в идеале еще и колонок с литералами полей на которые они влияют. Поскольку наименования формируются автоматически,
"глазками" очень сложно искать искомое в огромном списке.
Илья,
все Ваши замечания резонны, думаю, что они будут реализованы в ближайших релизах. То, что сейчас есть в версии 7.10 - это реализация в первом приближении.
От себя добавлю, что по логике, дизайнер бизнес правил должен предоставлять практически все возможности настройки, что есть и у настраиваемых в конфигурации правил.
Уже сейчас очевидно, что очень не хватает стандартной возможности автозаполнения по обратным связям.
И, если мы говорим о пользовательском инструменте, то и названия колонок, и пути должны указываться не через объекты энтити схем, а через пользовательский интерфейс настройки связей аналогичный тому, что есть при настройке фильтрации и колонок реестра.
Илья, здравствуйте!
Спасибо за обратную связь.
Данные пожелания нам известны и зафиксированы департаментом разработки для рассмотрения возможной реализации в будущих версиях.
Вопрос...
Так а каким образом согласуются/конкатенируются/мержатся несколько бизнес-правил, которые ориентированы на одно и то же поле, в рамках одной сущности.
Логическое "И" или логическое "ИЛИ"
или там вообще особая схема ?
Добрый день, Илья!
По моим наблюдениям, если написать такую логику, когда правило 1 противоречит правилу 2, то применится случайное. Не думаю, что на этот случай есть какие-то правила мержа, ведь непонятно зачем вообще такое делать.)
"Мотков Илья" написал:Не думаю, что на этот случай есть какие-то правила мержа, ведь непонятно зачем вообще такое делать.)
В пределах одного бизнес-правила можно использовать только группу "И" или группу "ИЛИ",
т.е. нельзя развернуть такую логику в пределах одно правила:
"Если поле X содержит Z или W, и поле Y равно Q, то делать поле N обязательным"
Такое в текущем положении вещей можно организовать только двумя бизнес-правилами:
1)"Если поле X содержит Z, и поле Y равно Q, то делать поле N обязательным"
2)"Если поле X содержит W, и поле Y равно Q, то делать поле N обязательным"
И вот теперь вступает в силу мой вопрос.
Так как же они конкатенируются объединяются.
PS: На самом деле два разработчика в разных схемах добавили свои бизнес-правила. пока у каждого было свое БП - все было нормально, после объединения в цепочку замещающих схем на тесте - правило ведет себя как-то странно, но оно точно не делает того чего от него ожидают :)
В итоге правила как-бы и не противоречат друг другу, и переписать его в одно правило тоже нет возможности. вот...
Добрый день, Илья!
Так ведь они никак не конкатенируются/объединяются. Если X содержит Z, отработает правило 1, если X содержит W, отработает правило 2. Так как они не противоречат друг-другу - все хорошо, сделать "более обязательным" поле Вы уже не сможете.
Не-а :)
В итоге не работают оба правила :) в этом то и кроется проблема понимания того как оно вообще должно работать в таком случае.
Результат для приведенного примера таков:
Имеем два правила:
1)"Если поле X содержит Z, и поле Y равно Q, то делать поле N обязательным"
2)"Если поле X содержит W, и поле Y равно Q, то делать поле N обязательным"
в итоге имеем следующее поведение:
правила вообще не работают - ни одно из них.
Если переписать правила иначе:
1)"Если поле X содержит Z или W, то делать поле N обязательным"
2)"Если поле Y равно Q, то делать поле N обязательным"
в итоге имеем следующее поведение:
Если поле X содержит Z или W, поле N становится обязательным
значение поля Y - вообще не играет ни какого значения.
Илья, здравствуйте.
Указанные Вами правила все же противоречат друг другу, так как если поле X содержит Z, то оно должно быть обязательным согласно 1 И не должно быть обязательным согласно 2. Возможно, более наглядным будет пример с правилом видимости. Поэтому работает только одно из них. Как уже указал мой коллега выше, добавили пожелание для реализации в будущих релизах - возможность создания сложных условий в бизнес-правилах с помощью дизайнера.