использовать по триггеру слепок используемых в условиях сценариев данных

[Халфин Тимур Маликович]

Насколько я понимаю, сейчас при срабатывании триггера используются текущие данные
т.е. возможен такая последовательность:
1. Происходит событие.
На момент события "Данные = 0"
Сценарий 1: "Данные ==0" - ACK
Сценарий 2: "Данные == 1" - NACK
2. Cработывает триггер по событию
3. Cценарий 1
проверяются условия: "Данные == 0" - ACК
изменяются данные "Данные = 1"
4. Сценарий 2
проверяются условия: "Данные == 1" - ACК
происходят неожиданные изменения

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

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

Предлагаю: запоминать значения полей, которые используются в условиях сценариев, подписанных на триггер

[Dmitry Goncharenko]

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

Поэтому обещать такого не готов, кажется что овчинка не стоит выделки.

[Илья Федоров]

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

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

[Дмитрий Макаров]

Для новичков отлично было бы использовать сценарии, описанные в этой хотелке viewtopic.php?f=46&t=5188

Вот так бы новичкам сильно понравилось бы.)

[Халфин Тимур Маликович]

Не думаю что ПФ ставит цель "упростить освоение новичкам", чем сложнее становится система тем выше порог входа в её освоение, особенно в настройки.

Поскольку мне не известен роадмап развития ПФ, я могу делать только предположения:
1. В ПланФиксе настройки сделаны NoCode - т.е. рассчитаны не на программистов, а скорее на проектировщиков бизнес-процессов - я делаю вывод, что ПФ рассчитан на новичков в программировании, которые своими силами могут запрограммировать сценарии.
2. ПланФикс слабо поддерживает средства сопровождения сложных сценариев: нет возможности комментариев, поиска, подключения Git и т.п. - я делаю вывод, что ПФ рассчитан на основную целевую аудиторию с небольшим количеством относительно простых сценариев (см.п.1).

В общем-то, аргумент обратной совместимости все решает:

- Есть много ситуаций, когда люди при конструировании сценариев закладываются именно на текущее поведение. Если изменить его, у них все сломается и нас распнут.

поэтому снимаю свое предложение

[Халфин Тимур Маликович]

Вот так бы новичкам сильно понравилось бы.)

не думаю - опыт визуального программирования показывает, что для коннекторов нужно довольно сильно заморачиваться.

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

[Дмитрий Макаров]

Вот так бы новичкам сильно понравилось бы.)

не думаю - опыт визуального программирования показывает, что для коннекторов нужно довольно сильно заморачиваться.

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

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