Противоречение функциональности "Кейс" - "Бизнес-правило"

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

Перед сохранением делайте доп проверку на обязательность полей из настроек пользователя (Те что он тусует) Как то так....

Вы поняли, Григорий, что я написал? Возьмите любую карту с панелей стадий и настройте обязательность полей на стадии, на которую объект переводится. Ну например - у оплаченной фактуры дожно быть обязательно поле "Дата оплаты". На стадии "Неоплачена" это поле не обязательное - так? Но кейсы работают так - при нажатии на стадию сначала выполняется сохранение объекта (и срабытвают все процессы) а уже потом проверка на поля поштучно. Как только выясняется незаполненность первого, все, объект откатывают на предыдущую стадию. Вы извините, но Ваш рецент нерабочий изначально. 

Те вам нужно сделать проверку до сохранения, на обязательность полей в той стадии на которую переходите?!

Григорий Чех,

Мне не нужно :) Как у вас работает обычное бизнес-правило? Вы выбираете, например, из списка значение стадии, например, "Оплачена". И по значению данной стадии срабатывают бизнес-правила на обязательность полей на ней. Т.е. на карточке будут обозначены обязательные поля, значение стадии будет новое, выбранное, но объект при этом не будет сохранен. Так? Дальше у вас два пути - либо заполнять поля (знаете какие, они выделены), либо вернуть ее на предыдущую стадию, не заполняя полей. Никакая логика, кроме джаваскрипта не задействована, ибо все это отрабатвывается на клиенте исключительно. При работе с панелью стадий все тоже самое работает несколько иначе - при нажатии на стадию система сначала выполняет сохранение объекта (т.е. наступает событие onChange/onSave) и переставляет стадию на следующую. Только после этого запускается проверка обязательности полей уже сохраненного объекта, которая естесственно не проходит и объекту второй раз меняется статус на предшествующий (т.е. снова наступает событие onChange/onSave). Визуально это выглядит как секундное мигание красной звездочки (обязательности) у первого поля правил, которое будет обработано. На предшествующем статусе данные поля не являются обязательными и пользователь не знает об этом, т.е. до клика на стадию он не знает о полях ибо они не обязательные, после клика тоже не знает, ибо стадию вернули на исходную Таким образом одновременное использование бизнес-правила на клиенте и панели стадий невозможно. Либо то, либо это. 

ММ еще раз при нажатии на панели статуса перехватываем метод onActiveStageClickSection (смена кейса по щелчку на панели статусов/кейсов) из ActionsDashboard понимаем на какую стадию из какой пользователь хочет перейти по щелчку на панели статуса!!!!! И для будущей стадии проверяем обязательность полей (Той на которую будет переходить после смены по кейсу!!!!) И если для будущей стадии поля не заполнены то ругаемся (Подсвечиваем !)

Поясню еще проще сами проверьте что вам нужно. когда вам нужно (Заполненость нужных полей, до смены статуса из панели кейсов). Если что-то не так то не вызывать в перехваченном методе - "выполняет сохранение объекта (т.е. наступает событие onChange/onSave) и переставляет стадию на следующую"

Что не так?!?

Григорий Чех,

Да чтож такое-то!

1) Одновременное использование бизнес-правил и кейсов. 

2) почему клиент должен платить за эту вещь?

3) это и есть тот самый костыль, который мы применяем. Но! это метод один для всех объектов, т.е. вы должны там выделять ручками id схемы, перечень полей в разрезе статусов и т.д. Что крайне неудобно и криво и уж точно пользователю недоступно. 

Я считаю это логическим косяком системы, что вы собственно и подтвердили. 

Те вам нужно при изменении статуса по панели до сохранения выполнить проверки из Бизнес правил для той стадии на которую переходите (Которые пользователь настроил)? Такого функционала нет, можно попытаться самим сделать или зарегить пожелание о улучшении, а скорее исправлении логического бага!

Реализация полноценного взаимодействия Action Dashboards и бизнес-правил — достаточно трудоемкая задача. 

На данный момент, для наиболее оптимального решения проблемы Вы можете вывести поле «Стадия лида» на страницу и изменять стадию не в Action Dashboard, а в этом поле. В таком случае правила будут отрабатывать корректно.

Мотков Илья,

Так хотят через панель те именно ActionDashboards И логически у вас ошибка правило есть, но оно не работает и фиг юзер поймет почему!!! 

Мотков Илья,

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

Также см. это обсуждение.

Я это все прекрасно знаю, ибо с базовой логикой этой боремся от ее рождения, но спасибо тем не менее.

Дмитрий Степанов,

Мое мнение, что это повод для команды разработки bpm'online crm пересмотреть необходимость и приоритетность реализации данного функционала в нормальном виде, чтобы описанных Вами выше проблем не возникало.

А клиент у Вас - молодец, с такими работать интересно!

Алла, спасибо за поддержку :)

Дмитрий Степанов пишет:

ибо с базовой логикой этой боремся от ее рождения

С базовой логикой бороться не нужно. С ней нужно дружить.