вам необходимо определить группу полей в diff секции карточки
и ёё свойство visible забиндить на атрибут (булево) значением которого в последствии управлять из Вашего клиентского кода, в зависимости от значения в атрибуте - группа полей будет скрыта или продемонстрирована.

как пример LeadPageV2 группа полей "Регистрационные данные"

attributes: {
...
//атрибут значением которого мы будем контролировать видимость группы полей
	"isLeadPageRegisterInfoVisible": {
		type: Terrasoft.ViewModelColumnType.VIRTUAL_COLUMN,
		dataValueType: Terrasoft.DataValueType.BOOLEAN,
                value: false
	},
...
}
diff: {
...
//merge для конфигурационного объекта группы полей
	{
		"operation": "merge",
		"name": "LeadPageRegisterInfo",
		"values": {
                         //"биндинг" (привязка) значения свойства viewModel к атрибуту
                         "visible": {bindTo: "isLeadPageRegisterInfoVisible"}
		}
	},
...
},
methods: {
...
     "onEntityInitialized": function() {
              this.callParent(arguments);
              //сохраним в глобальной области видимости контекст карточки, для удобного доступа из консоли
              document.thisPageScope = this; 
     }
...
}

теперь откроем карточку лида, и в консоли поиграемся значением атрибута:

document.thisPageScope.set("isLeadPageRegisterInfoVisible", true);
//наблюдаем появившуюся группу полей
document.thisPageScope.set("isLeadPageRegisterInfoVisible", false);
//наблюдаем как группа полей была скрыта.

Это нормально, вам нужно под каждое действие сделать отдельное БП. Так же работали и рукописные БП, посмотрите на академии.

Как пожелание:
Иметь возможность выполнять группу действий основываясь на группе условий - весьма ожидаемый кейс.
Зачастую доступность/видимость/обязательность десятков полей, зависит от единой группы условий.

PS: мы понимаем что тут необходимо повесить требуемые конечные свойства видимость/доступность/обязательность - на атрибут и управлять его состоянием в логике.
Но, ИМХО, в бизнес-правилах, такой кейс очень будет "к месту".

и еще...

само собой тут не хватает "противоположенных" действий:
Если есть действие "Сделать поле редактируемым", то по идее должно быть и "Сделать поле недоступным"
Если есть действие "Скрыть поле", то должно быть и "Показать поле"
и так далее...

Можно конечно отталкиваться от "противоположенности" условий, но в таком случае необходимо предусматривать особые начальные состояния.
Например чтобы эффективно использовать "Показать поле на странице"
Его для начала следует "скрыть", т.е. описать его как изначально скрытое, в то время как по умолчанию (например из мастера) поля создаются видимыми.
По этому логичнее скрывать его там где оно не нужно, чем показывать его везде где оно нужно.
ну я думаю кейс понятен :) одно бизнес-правило, против нескольких бизнес-правил и работы со схемой, для реализации одного и того же поведения.

:) и еще немного.
В мастере редактирования бизнес-правил, очень не хватает сортировки, а в идеале еще и колонок с литералами полей на которые они влияют. Поскольку наименования формируются автоматически,
"глазками" очень сложно искать искомое в огромном списке.

Илья,

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

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

Уже сейчас очевидно, что очень не хватает стандартной возможности автозаполнения по обратным связям.

И, если мы говорим о пользовательском инструменте, то и названия колонок, и пути должны указываться не через объекты энтити схем, а через пользовательский интерфейс настройки связей аналогичный тому, что есть при настройке фильтрации и колонок реестра.

Илья, здравствуйте!

Спасибо за обратную связь.
Данные пожелания нам известны и зафиксированы департаментом разработки для рассмотрения возможной реализации в будущих версиях.

Вопрос...
Так а каким образом согласуются/конкатенируются/мержатся несколько бизнес-правил, которые ориентированы на одно и то же поле, в рамках одной сущности.
Логическое "И" или логическое "ИЛИ"
или там вообще особая схема ?

Добрый день, Илья!

По моим наблюдениям, если написать такую логику, когда правило 1 противоречит правилу 2, то применится случайное. Не думаю, что на этот случай есть какие-то правила мержа, ведь непонятно зачем вообще такое делать.)

"Мотков Илья" написал:Не думаю, что на этот случай есть какие-то правила мержа, ведь непонятно зачем вообще такое делать.)

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. Возможно, более наглядным будет пример с правилом видимости. Поэтому работает только одно из них. Как уже указал мой коллега выше, добавили пожелание для реализации в будущих релизах - возможность создания сложных условий в бизнес-правилах с помощью дизайнера.

Анастасия, здравствуйте!

Действительно, Вы правы, этот функционал можно реализовать через бизнес-правило. Рекомендации описаны в руководстве для разработчиков https://academy.terrasoft.ua/documents/technic-sdk/7-8/biznes-pravila-i…

"Мария Ватулина" написал:

Анастасия, здравствуйте!

Действительно, Вы правы, этот функционал можно реализовать через бизнес-правило. Рекомендации описаны в руководстве для разработчиков https://academy.terrasoft.ua/documents/technic-sdk/7-8/biznes-pravila-i-...

К сожалению, не получилось это реализовать с помощью бизнеса-правила. Массив enums.property не подходит, т.к. нам нужно установить конкретное значение чекбокса, а не его видимость, обязательность и т.д. Что неправильно делаю:

rules: {
"UsrPaid": {
BindParametrVisibilePlaceByType: {
ruleType: BusinessRuleModule.enums.RuleType.BINDPARAMETER,
valueType: BusinessRuleModule.enums.ValueType.CONSTANT,
value: true,
conditions: [{
leftExpression: {
type: BusinessRuleModule.enums.ValueType.ATTRIBUTE,
attribute: "Type"
},
comparisonType: Terrasoft.ComparisonType.EQUAL,
rightExpression: {
type: BusinessRuleModule.enums.ValueType.CONSTANT,
value: "2cb5cac1-1523-e011-a94a-00155d043204"
}
}]
}
}
}

А правило FILTRATION удается применить только для фильтрации значений справочной колонки, а у нас чекбокс.

И не получится с помощью бизнес правила :)

Скорее сюда читать. Пункт 6 кроме того, что вам не надо заменять обработчик onentityinitialized.
Ваше поле (это же поле булевское как галка у вас отображается, да?) с галкой в attributes, в dependencies то поле с типом, метод напишите свой, чтоб галку проставлял снимал на основании значения поля тип

"Александр Кудряшов" написал:

И не получится с помощью бизнес правила :)

Скорее сюда читать. Пункт 6 кроме того, что вам не надо заменять обработчик onentityinitialized.

Ваше поле (это же поле булевское как галка у вас отображается, да?) с галкой в attributes, в dependencies то поле с типом, метод напишите свой, чтоб галку проставлял снимал на основании значения поля тип

Получилось!:) Спасибо, Александр, дай вам Бог здоровья)))