Смена кейса, предварительная проверка значения (Рекомендуемый подход)
Зачастую при взаимодействии пользователя с элементом кейсов, перед тем как сменить статус (сохранив значение) необходимо проводить дополнительные проверки.
По факту смены можно сделать зависимость на колонку.
Но вот как идеологически корректно "вклинивать" проверку до смены статуса, прерывая ее в случае необходимости)
Я конечно нашел методы в схемах дашборда, замещая которые можно вклиниваться... но мне как-то кажется такой подход как минимум не "каноничным" и не очень элегантным, для такой типовой задачи ?
Нравится
А зачем прерывать? Просто не давать сохранить, если при определенном статусе не проходит валидация.
Илья, здравствуйте!
Уточните, пожалуйста, эта задача может быть решена бизнес-правилами? Также в объекте раздела/страницы редактирования можно задать процесс на событие "Перед сохранением записи". В результате перед сохранением записи будет выполняться проверка разработанной логики.
Суть:
Согласно тех.заданию в статусных моделях зачастую, условия строятся таким образом:
При переходе со статуса A на статус B:
Должны выполняться некоторые условия, заполненность полей, принадлежность пользователя осуществляющего переход к функц.роли и т.д.
Т.е. все эти проверки должны производиться до того как стадия будет изменена и в случае несоответствия условиям - переход осуществляться не должен, возможно даже выполнятся какая-то дополнительная логика, открыть lookup для выбора незаполненных полей, показать некое информационное сообщение, редиректнуть на карточку и т.д.
Ну и само собой есть логика которую необходимо выполнять уже после перехода, с эти проблем нет - вешаемся на изменение колонки.
Вот...
Ранее для этого я замещал схему "SectionActionsDashboard" а в ней в свою очередь, приходилось расширять метод onActionChanged, ну и вообще все это конечно работает но выглядит сущим "костылем".
Мне подсознательно кажется что для такого юзкейса как предварительные проверки перед сменой статуса, ну просто обязан быть более лаконичный подход.
"Демьяник Алексей" написал:задать процесс на событие "Перед сохранением записи".
В таком случае можно задать только Бизнес-процесс, мне же требуется выполнить довольно сложный код клиентской части приложения.
Кстати может быть в событийной модели есть какое-то событие "Перед сохранением записи", на которое я мог бы зацепить свой JS-код.
Может быть из БП можно как-то вызвать событие на которое подпишется JS-код карточки ?
Вообщем суть я думаю понятна.
В бизнес-процессе "Перед сохранением записи" у меня нет никакой информации с какого на какой статус переходят, что сводит на нет смысл его внедрения.
PS: почему для БП из списка событий объекта открывается какой-то отдельный мастер БП
Вроде по функционалу то же самое, но главный вопрос - "зачем?".
Далее не ясно какие входящие параметры вызова такого процесса.
Боже... что это вообще за редактор Бизнес-процессов такой, как там работать в принципе не ясно.
А можно как-то перейти в типовой интерфейс редактора ? я в упор не пойму как мне у элемента "Читать данные" просто произвести настройку откуда и какие колонки...
Жесть.
"Севостьянов Илья Сергеевич" написал:"Читать данные" просто произвести настройку откуда и какие колонки
А в событийном БП:
https://academy.terrasoft.ua/documents/technic-sdk/7-4-1/sobytiya-obekta
и нельзя использовать обычные элементы процессов. По сути там можно только использовать события и скрип-таски. Грубо говоря c# код. И используется там старый редактор БП. И перейти на новый редактор тоже нет возможности.
В будущем и вовсе планируется уход от событийных БП.
Для понимания как и что пишут в них, можете почитать базовые событийные БП базовых объектов в базовых пакетах.
Что касается вашего вопроса про переход со стадии на стадию:
Посмотрите в объект Activity в пакете Base, метод SetRemindDatesOnSaving
Там в момент сохранения как раз читают как старое значение колонки:
var oldStartDate = Entity.GetTypedOldColumnValue<DateTime>("StartDate");
Так и новое:
var newStartDate = Entity.GetTypedColumnValue<DateTime>("StartDate");
И дальше строят логику на основании того что изменилось ;)
"Максим Шевченко" написал:и нельзя использовать обычные элементы процессов.
Т.е. "Читать данные" и прочие типовые элементы - использовать просто нельзя в этих БП?
"Севостьянов Илья Сергеевич" написал:Т.е. "Читать данные" и прочие типовые элементы - использовать просто нельзя в этих БП?
Нельзя.
Так... хорошо.
Значит внедрить свою логику "честно" на смену статусов:
В JavaScript схемах - нельзя, так как логика будет не честной в случае если статус будет меняться например бизнес-процессом, или ESQ-запросом из другой карточки и т.д.
Событийные бизнес-процессы - не имеют возможности работы с типовыми элементами БП, там только суровые C# скрипты.
(А кстати вызвать подпроцесс (созданный в нормальном редакторе) с параметрами, может так?)
Обычные БП которые например вешаются на событие смены значения в колонке со статусом - абсолютно лишены возможности получить предшествующий статус, т.к. срабатывают после изменения.
(Как грязный трюк - реализовывать скрытое поле которое будет содержать предыдущий статус)
Как-то все прям сурово... учитывая сколько бизнес логики обычно приходится на смену статусов всяких бизнес-сущностей
"Севостьянов Илья Сергеевич" написал:в случае если статус будет меняться например бизнес-процессом, или ESQ-запросом из другой карточки и т.д.
А как пользователь должен реагировать на такие случаи?
Ну во первых у него должны отрисоваться изменения как минимум :)
Но я говорю в общем про бизнес логику смены статуса.
При смене из статуса A на статус B
необходимо в поле X поместить значение Z + R, создать активность такую-то и установить ответвенного на такого-то если то или это и т.д.
Если это все реализовывать на уровне JS кода клиентской схемы (Это можно).
Но работать сие будет только если Статус/Стадия меняются из карточки непосредственно.
Если по условиям например другой задачи в другой карточки, другого объекта необходимо при смене его статуса, так же менять статус объекта связанного например справочным полем. То JS логика смены стадии там должна быть и тут продублирована (причем со всеми причудами контекста, которого тут не будет), да и в конце концов может статься и так что стадия вообще будет меняться ESQ запросом или бизнес-процессом.
А реакции пользователя можно придумать какие угодно.
"Севостьянов Илья Сергеевич" написал:При смене из статуса A на статус B
необходимо в поле X поместить значение Z + R, создать активность такую-то и установить ответвенного на такого-то если то или это и т.д.
Это выглядит на обычный процесс за исключением последнего значения.
С другой стороны, для статусов мы всегда делаем деталь Status history, откуда и можно считать предпоследний статус.
"Владимир Соколов" написал:С другой стороны, для статусов мы всегда делаем деталь Status history
Ну т.е. вы самостоятельно заботитесь о сохранении хронологии, а стало быть и описываете бизнес-логику которая эту хронологию контролирует и ведет,
Так же вы имеете в таком случае весьма витьеватые БП в которых вам надо будет получать данные из связанной детали.
Вообщем "полный оверхед" как говорится :)
Когда изначально сама архитектура и идеология статуса/стадии сущности просто обязывает имплементацию предоставлять событийные средства реагирования на "до" и "после", в том числе обеспечивающая предоставление значения стадии сменяемой и стадии целевой в событийные обработчики, будь то callback события в JS или Бизнес процес запущенный по сигналу.
Даже мастер кейсов сделали - прям "годный"...
Но для разработчиков опять "костыли"... как говаривает небезызвестный Umputun: "как будто писали чужие для хищников..."
Ну ведь это же просто очевидно, что надо иметь возможность валидировать переход на стадию до ее осуществления, особенно если сам факт перехода является инициатором сопряженной бизнес-логики.
PS: Для обработки смены статуса в обычном БП есть 2 большие проблемы:
1) В случае если валидация не пройдена - вам потребуется делать откат. Т.е. роизойдет аш 2 сохранения в БД вместо того чтобы при потенциально правильной архитектуре - не сохранять вовсе.
2) Откат это тоже изменение стадии - т.е. бизнес процесс становится рекурсивным, в случае невалидного состояния - вызывается 2 раза как минимум, вместо того чтобы не вызываться вовсе, в случае невалидности (например проверяемой обособленным БП).
Почему: потому что на старте БП, на сигнале вы никак не сможете провести проверку на предмет рекурсивной сработки по откату - только в теле БП.
3) Пользователь открывший карточку сущности стадия которой поменялась - ни сном ни духом... вот это прям совсем трабла, даже не костыльнуть никак (ну только если вебсокеты крутить с событиями в C#, и повсеместной подпиской в JS на перерендер).
Вообщем оверхед просто сумашедший...
Илья, здравствуйте!
Зафиксировали ваше пожелание по настройке валидации при изменении стадии/состояния записи через DCM.
Спасибо... было бы очень здорово.
И это действительно улучшит, сильно, кастомизируемость при разработке не типовых конфигураций на платформе.