Доброе утро.

Можно для Вашей карточки редактирования указать в качестве родительской BaseModulePageV2 из пакета NUI, тогда кнопка [ACTIONS] должна появится.

Если же Вы не хотите наследоваться от этой карточки, то можете посмотреть, каким образом реализуется добавление этой кнопки и пунктов её меню в 'Base card schema' (BasePageV2) пакета NUI.

Алла Савельева,

Спасибо, сделала по первому совету - появилась. 

Добрый день. Тут два момента: 1) этот метод имеет сигнатуру addToolsButtonMenuItems: function(toolsButtonMenu) 2) вы get сделали, а вот set обратно - нет. В итоге локально в методе объект изменен, но на детали ничего не видно. Если указанные места поправить - все работает.

добрый день! можете полный код написать , не получается добавить пункт меню на деталь 

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

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

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