Коллеги, недавно SectionActionsDashboard (Кейсы т.е.) уже обсуждали. Однако в пятницу была обнаружена еще более прикольная штука при его использовании. Если использовать кейсы на поле "Стадия" (ну например стадия продажи), то теряется функциональность lookupListConfig в декларации данного атрибута. Т.е. конструкция вида в модуле OpportunityPageV2:
"Stage": { lookupListConfig: { columns: ["MaxProbability", "End"] }, dependencies: [ { columns: ["Stage"], methodName: "setProbability" } ] } setProbability: function() { console.log(this.get("Stage").End); }
при изменении стадии кликом на стадию в кейсе никогда не вернет true. При этом (а это самое занятное) перестают отрабатывать и базовые функции, которые используют например Stage.End и не завязаны на инициализацию. Исследование показало следующее: - при объявленных колонках в атрибуте все работает ок при инициализации страницы (базовая логика onEntityInitialized, нет никаких пользовательских функций):
{ value: "325f0619-0ee0-df11-971b-001d60e938c6", displayValue: "Prezentace", primaryImageValue: "", End: false, MaxProbability: 30 }
а при клике на кейс так (функция setProbability из примера выше):
{ value: "fb563df2-5ae6-df11-971b-001d60e938c6", displayValue: "Uzavření smlouvy" }
как видно, никаких дополнительных колонок нету. Т.е. никакая логика их использующая работать не станет. Но дальше совсем интересно - после того, как отрабатывает кейс страница снова инициализируется второй раз и вуаля - наши колонки снова на месте:
{ value: "fb563df2-5ae6-df11-971b-001d60e938c6", displayValue: "Uzavrení smlouvy", primaryImageValue: "", End: false, MaxProbability: 90 }
прикол конечно в том, что наши функции на End и MaxProbability уже не сработают, так как нет события изменения поля. На инициализацию их тоже нельзя вешать (например вероятность не всегда совдадает с MaxProbability. Некоторые подумают - ну и что? Возьмем нужные значения в функции изменения с помощью esq. И это не сработает, думаю понимаете почему.
Итог - например, простейшая задача клиента при изменении стадии в поле вероятность подставить максимальную вероятность для данной стадии, которая решается функцией в одну строку при наличии такого косякка вообще становится нерешаемой :( Поддержка прореагировала очень вяло, посему вопрос - может кто-то колдовал с последовательностью изменение стадии в кейсе - сохранение - инициализация? Спс.
PS: Не знаю, как у вас, но по мне от кейсов в такой реализации скорее вред чем польза. Работает либо кейс либо остальное. Бред какой-то :(
Нравится
Если в разделе используется DCM, логику вычисления значений полей лучше перенести с клиентского кода на него же. В кейс на переключение стадии можно добавить БП, где и реализовать заполнение вероятности.
Если бы была реализована логика обновления страницы, то да. Проблема в том, что реализация Вашего совета потребует переписывания всей страницы в принципе, ибо на это поле реализована другая функция, на которую в свою очередь другая и так далее.
Можно еще в MS Excel выгрузить и там посчитать кстати
В таком случае нужно либо переписать всё на серверную логику при смене стадии, либо вместо использования DCM сделать обычное справочное поле «Стадия».
Ну вы, Илья, в очередной раз подтвердили то, что я говорю уже давно - либо кейсы, либо все остальное. Спасибо за комментарии.
Илья, ну предположим, я сделал процесс на изменение стадии. Процесс на сервере стадию поменяет. При возврате на предыдущую стадию значение вероятности станет меньше предыдущего и сохранится в БД. На карте все останется как было, включая значение вероятности, ибо страница не перечитается новыми значениями. При этом система даже не пикнет, ибо проверка максимальной возможной вероятности у вас стоит на изменение данного поля, далее пользователь что-то поменяет (ну не вероятность) и сохранит карту. Какое значение вероятности сохранится в бд? А какое значение производной функции (вероятность х сумма продажи) сохранится? Я вам отвечу - старое значение вероятности и старое значение производной функции. Т.е. новые процессные значение просто перепишутся старыми на карте. Ну, ей богу, вы бы не предлагали такие вещи :(
Если вероятность пользователем не вводится, можно вообще попробовать считать её в БП объекта на событии смены значения в поле.
В комментах написано - может вводиться. Но это все равно не отменяет того, что я написал. Это вот цена того, что у вас связь со стороны клиента с сервером есть, а в обратную сторону извините.
Связь с сервера в сторону клиента возможна по веб-сокетам, логику нужно реализовывать программно.
Илья, вы надо мной глумитесь что-ли? Вопрос звучал Каким образом реализовать поставленную задачу. На текущий момент ответа нет. Я не сомневаюсь в том, что можно и веб сервисом достать. Но что это за система, в которой нужно веб сервис писать, чтобы значение поля из БД получить измененное этой же системой?!
Значит вывод. Если используется DCM и при этом нужна какая-то логика манипулирующая данными этого же объекта (изменение полей, расчеты, проверки и т.д.), завязанная на DCM , то данная задача в данной архитектуре bpmonline не является реализуемой.
Нет, её нужно реализовывать в той самой DCM. Там есть возможность привязать на смену стадии логику в виде запуска подпроцесса. Если оно конфликтует с какой-то логикой на стороне браузера, нужно тестировать и адаптировать.
Илья, вы вообще читаете, что я пишу? Если вы реализуете процессом, то последующее сохранение карты на клиенте перетрет все ваши процессные значения на сервере.
Ну и даже если Вы правы - мне что, для 4 кейсов из 8 стадий каждая 32 шага описывать? А потом еще и менять каждый раз, как кейс поменяют!
Илья, не секрет, что вы будете биться до последнего со мной и мою точку зрения не примете. Смысл данной дискуссии считаю утраченным и не вижу смысла ее продолжать. Горе поддержке, которая считает самым важным своим занятие не решение проблем и не исправление ошибок, а доказывание своей абсолютной правоты клиенту и отсутствие в системе ошибок и недоделок как таковых. Вы могли привести нормальный реализуемый пример, вы его не привели. В данном контексте я останусь при своих, так как цена реализации того, что вы мне напредлагали несоизмерима с выгодами для клиента. Если мне нужно полсистемы переписать, чтобы одно поле на карте заполнить, то это означает, что это такая система, которая не позволяет это поле заполнить. Все, закончили тему.
Дмитрий, примеры разработки кейсов есть в академии. Если Вы нашли ошибку в стандартной логике системы, пожалуйста, воспроизведите её на чистой демо-версии без доработок и сообщите в поддержку.
Если же разработанный Вами кейс конфликтует с разработанной Вами же клиентской логикой, то в такой переписке сложно будет выяснить, как можно верно реализовать задуманное, тут нужно подключатся и смотреть, тестировать разные варианты.