Ваяю нечто вроде Service Desk. Структура данных выглядит вот так:

В левом верхнем углу находится таблица, которая задает совокупности допустимых комбинаций "пользователь - ПО - юрлицо".
Пытаюсь сделать WEB-форму для запросов (таблица Requests). В эту форму уже добавлено три поля (два ComboBox и одно DynamicComboBox). Пытаюсь добавить четвертое - пользователь (тоже вроде DynamicComboBox), но в нем необходимо отфильтровать только тех пользователей, которые содержатся в таблице допустимых совокупностей. То есть, необходимо каким-то образом построить запрос (или SQL-запрос), который нужно "подсунуть" в ComboBox. Никак не получается это сделать.

То есть, задача звучит так:
В ComboBox, источником данных для которого является Requests.SoftwareUsers, необходимо дополнительно отфильтровать записи таблицы SoftwareUsers таким образом, чтобы в ComboBox отобразились только те пользователи, которые содержатся в таблице допустимых комбинаций для заданных значений "Юридическое лицо" и "Программный продукт".

Эта задача вообще решается?

bahrovGarya,
на чем это вы ваяете таком симпотичненьком?В названии топика написано, на чем.

АБЕсли я правильно понял, предлагается:
1) ссылку из запроса на пользователя заменить ссылкой на использование ПО пользователем, чтобы можно было задать фильтр по организации и программному продуктуПонял. Спасибо. Им и воспользуюсь.
Немного непривычно, что основная таблица бизнес-процесса должна иметь ссылки на все остальные. Стереотипы мышления приходится ломать, поэтому такие вопросы и возникают... :)

АБ2) денормализовать таблицу использования ПО пользователем, внеся в нее имя пользователя из таблицы пользователей, чтобы его можно было отобразить его в комбо-боксеНе очень здорово денормализовать таблицу пользователей, чтобы повторять атрибуты одного пользователя множество раз.

АБПо ходу, ссылка из запроса на класс ПО - лишняя, требуемый результат достигается одной ссылкой на программный продукт и dynamic combo box на форме.Дело в том, что программ - очень много. Неудобно выбирать из выпадающего списка, если в нем слишком много записей. Поэтому я предполагаю, что пользователь сначала выберет класс ПО (классов относительно немного - порядка 20), затем ПО выбранного класса (около десятка каждого класса). Для этих целей и использую две ссылки - на класс ПО и на собственно ПО, при этом для выбора ПО использую dynamic combo box. Если эту же задачу можно решить каким-то еще образом, то можно немного подробнее - как?

AlexeyBK2Ещё, для использования dynamic combo box необходимо задать иерархию, а это можно сделать только у таблиц типа Parameter.
Сейчас у вас таблицы Класс программных продуктов и Программный продукт имеют тип Master, измените тип этих таблиц на Parameter.

http://wiki.bizagi.com/en/index.php?title=Dynamic_Combo_example Понял, спасибо. Завтра попробую.

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

АБ,

У нас уже есть служба SD, у нее есть недостатки, которые я попытаюсь исправить в новом варианте, который и пытаюсь реализовать. Но уже в этой службе регистрируются не инциденты, а запросы на изменение и проблемы. Например, инциденты, которые разрешаются консультациями пользователей, в ней не регистрируются.

Запросы на изменение регистрируются не теми людьми, у которых возникла та или иная проблема, а только специалистами самой службы SD, которые способны отличить инцидент от запроса на изменение и которые способны коротко, понятно и исчерпывающе изложить в описании проблемы ее суть (в отличие от многих пользователей, для которых описание проблемы изначально озвучивается в стиле "у меня ничего не работает!").

Однако, специалист службы SD должен зафиксировать, какой именно пользователь обратился в службу SD. Иными словами, проблема возникает у одного человека, а регистрирует ее в системе другой. Поэтому под "пользователем софта" подразумевается НЕ пользователь BizAgi.

АБ...информацию об инцидентах, не переросших в проблему, необходимо фиксировать - это ведь база знаний.Согласен, что вообще-то надо. Но для этого требуется перейти на новый уровень корпоративной культуры. Для начала следует решить задачи более приземленные. Пока же сами пользователи не хотят ничего регистрировать. Воспринимают требование регистрации как надуманный бюрократический препон, и в какой-то степени они правы. Если регистрация инцидента отнимает у пользователя время, сравнимое со временем получения консультации при прямом обращении к специалисту службы техподдержки, то смысл регистрации, по крайней мере, самим пользователем, уже в какой-то степени расплывается.

Поставьте себя на место пользователя. Например, бухгалтера. Который знает, что при возникновении каких-либо проблем с программой бухучета нужно просто поднять трубку и набрать телефон ИТ-специалиста Васи Пупкина. Вася Пупкин за 5 секунд средствами удаленного администрирования подключится к рабочей станции пользователя, моментально сориентируется в ситуации, если что, задаст дополнительные вопросы, и через 1-2 минуты в 90% случаев проблема уже будет решена.

А тут от пользователя вдруг начинают требовать письменно зафиксировать проблему (тогда как в школе по сочинениям/изложениям у него едва-едва вытягивалась троечка). Нужно еще сообразить, какая дополнительная информация может иметь существенное значение (что делалось, в какой последовательности, и какие именно данные были выбраны). Если на экране отобразилось сообщение о фатальной ошибке на каком-то непонятном аглицком языке длиной в целый абзац, то как о нем подробно рассказать. 95% наших пользователей морально не готовы вникать в то, как делается скриншот ошибки и как потом этот скриншот приложить к регистрируемому инциденту (обычно за пользователя такие действия всегда делает специалист SD). Самое же главное, что убив на регистрацию инцидента достаточно много своего времени, пользователь скорее всего не получит решения своей проблемы за 1-2 минуты, а вынужден будет отвечать в режиме, похожем на email-переписку на уточняющие вопросы, и пока специалист наконец поймет суть проблемы, вместо 1-2 минут уйдет 1-2 дня. То есть, да, мы получим регистрацию всего и вся, но путем потери оперативности решения проблем. Поэтому и нужно смотреть, чтобы в погоне за "лучшими практиками" с водой не оказался выплеснутым ребенок.

Регистрация инцидентов - это то, к чему мы стремимся. И мы решим эту задачу, но не кавалерийским наскоком. Сначала должен быть полностью готов "обвес" такого процесса. Вот над ним я сейчас и работаю.

ViPRosпросто в первой таблице {юрлицо, пользователь, продукт} все входящие типы равноправны
эта таблица долна разбиться на 2
{юрлицо, пользователь} и {{юрлицо, пользователь}, продукт}
Да, ты прав. Приму к сведению, спасибо.

ViPRosа для Запрос не надо никакой таблицы - это просто представление + фильтр, т.е. метаданные, а не хранилищеВ BPM-системе все немного иначе, чем в обычной жизни... :) В BizAgi обязана существовать "наиглавнейшая таблица", в которой фиксируется информация экземпляров процесса. На рисунке ее изображение отличается от изображения других таблиц тем, что вокруг нее не одинарная, а двойная рамка. Поскольку разрабатывается БП обработки запросов на изменение, главной таблице присвоено имя Requests.

Разобрался как работает Dynamic Combo Box.
Действительно, прикольно, спасибо за наводку. Получается, что в режиме конструктора формы на форму добавляется один контрол, а в режиме выполнения на форме появляется несколько комбо-боксов друг под другом.
Сделал ввод класса программного продукта и самого программного продукта одним Dynamic Combo Box, ссылающимся на один Entity "Программы" типа Parameter.

Однако, далее опять возник затык. Пытаюсь создать Entity "Связка Программы-Юрлица". Если делаю его типа Parameter, то BizAgi требует кроме ссылок на "Программы" и "Юрлица" добавить в список полей хотя бы одно текстовое поле, которое мне совершенно ни к чему. Без лишнего текстового поля тоже никак не получется, потому что в свойствах Entity BizAGi поля-ссылки исключаются из перечня полей, которые могут быть выбраны в качестве "Display Attribute" (кстати, не совсем понятно, почему, они вполне могли бы быть отображаемыми). Оставить "Display Attribute" пустым BizAgi не позволяет. А добавлять лишнее текстовое поле очень не хочется, потому что заполнять его той же самой информацией, которая уже указана в других полях, как бы не фонтан.

Тут я вспомнил, что простой комбо-бокс по Entity типа Master позволяет выбрать в качестве отображаемого поля любое поле, в том числе и поле-ссылку. Поэтому принимаю решение сделать Entity "Связка Программы-Юрлица" типа Master, и на форме использовать простой комбо-бокс, у которого будет задан фильтр по выбранной в Dynamic Combo Box программе. Однако, при попытке воплотить это решение в жизнь я вдруг столкнулся с новой проблемой, когда попытался заполнить эту таблицу значениями. Кнопка, которой добавляются новые записи в таблицу, почему-то оказалась недоступной (серенькой - см.приаттаченную картинку). Причем, самый "наипервейший" раз когда я открыл эту таблицу для добавления записей, она не выглядела серенькой. Но когда я по ней кликнул мышкой, она тут же стала серенькой (и более ничего не произошло). После чего она уже всегда и сразу выглядит серенькой. В чем может быть проблема?

Спасибо за ответы. Вынужден был переключиться на решение срочных вопросов, поэтому возникла небольшая пауза.

Переделал все Entity в тип Paramener. Однако, задача так и не решена.

Еще раз по сути. Есть две пары Entity:
1. Юрлицо
1.1. Филиал юрлица
и
2. Класс ПО
2.1. ПО

Понятно, что выбор данных из любой пары может быть реализован с помощью Dynamic combo box пока эти пары никак не взаимодействуют. Однако, они взаимодействуют через еще одну вспомогательную таблицу (Entyty) "Допустимые комбинации филиалов и ПО").

По большому счету без разницы, с какой пары начинать выбор на форме.

Вариант 1. Пользователь сначала указывает юрлицо и филиал. Понятно, что в этом случае выбор "Юрлица" и "Филиала юрлица" можно осуществить с помощью одного Dynamic combo box. Но далее необходимо отфильтровать выбор класса ПО и само ПО таким образом, чтобы юзверь мог выбрать из списка только тот перечень ПО, который может использоваться для уже указанного им филиала. То есть, для выбора класса ПО нужно "подсунуть" комбобоксу (или чему-нибудь еще) что-то вроде следующего SQL-запроса:
select SoftwareClasses.ID, SoftwareClasses.SoftwareClassName
from SoftwareClasses
inner join Softwares on Softwares.SoftwareClassID=SoftwareClasses.ID
inner join ValidCombinations on ValidCombinations.SoftwareID=Softwares.ID
where ValidCombinations.BranchID= ?ID_Уже_Выбранного_Филиала
Для выбора собственно ПО нужно ограничить его выбор следующим образом:
select Softwares.ID, Softwares.SoftwareName
from Softwares
inner join ValidCombinations on ValidCombinations.SoftwareID=Softwares.ID
where ValidCombinations.BranchID= ?ID_Уже_Выбранного_Филиала

Вариант 2. Пользователь сначала указывает класс ПО и собственно ПО. Понятно, что в этом случае выбор из энтитей "класс ПО" и "ПО" можно осуществить с помощью одного Dynamic combo box. Но далее необходимо отфильтровать выбор юрлица и филиала юрлица таким образом, чтобы юзверь мог выбрать из списка только тот перечень юрлиц и их филиалов, который может использоваться для уже указанного им ПО. То есть, для выбора класса юрлица нужно "подсунуть" комбобоксу (или чему-нибудь еще) что-то вроде следующего SQL-запроса:
select Firms.ID, Firms.FirmName
from Firms
inner join Branches on Branches.FirmID=Firms.ID
inner join ValidCombinations on ValidCombinations.BranchID=Branches.ID
where ValidCombinations.SoftwareID= ?ID_Уже_Выбранного_ПО
Для выбора филиала юрлица нужно ограничить его выбор следующим образом:
select Branches.ID, Branches.BranchName
from Branches
inner join ValidCombinations on ValidCombinations.BranchID=Branches.ID
where ValidCombinations.SoftwareID= ?ID_Уже_Выбранного_ПО

Эта задача вообще как-нибудь решается? Или я пытаюсь решить неразрешимую проблему? Можно ли XPatch-функцию exists как-нибудь примострячить к условию фильтрации комбобокса (у меня не получилось использовать функции в условии фильтрации)?

И еще несколько вопросов, если не сильно затруднит...

1. Можно ли как-нибудь настроить bizagi, чтобы тот, кто стартует БП мог бы отказаться от его старта, если он вдруг почему-то передумал его стартовать, пока заполнял форму исходными данными? Или если нажал кнопку "запустить", то он так и будет "летать на орбите", даже если на форме имеются ошибки, которые не позволяют никаким образом продолжить выполнение процесса?

2. В какой момент отрабатывает условие фильтрации, заданное для контрола на форме в поле "Filter" и загружаются данные для отображения на форме (например, для комбобокса)? У меня такое ощущение, что при загрузке формы. А можно ли как-нибудь заставить контрол обновить данные после того как указано значение для другого контрола?

3. Можно ли создавать на форме контролы, не привязанные к данным? У меня такое ощущение, что нельзя. Поправьте меня пожалуйста, если я ошибаюсь. Можно ли как-нибудь адресовать не к данным Entity (то есть, не к источнику данных для контрола), а к данным собственно формы, если контролы, не привязанные к данным могут существовать?

4. Если требуется организовать на форме что-то вроде ReachTextBox с возможностью ввода текста произвольной длины, то существует ли какая-либо альтернатива использования строки длиной 4000 символов для использования BLOB-полей кроме аплода файла, сформированного за пределами системы?

Продублировал свой вопрос на форуме BizAgi. Может быть там что посоветуют.

Если бы фильтр контрола допускал использование XPath-функции exists(), задача решалась бы с пол-пинка. Проблема в том, что никакие выражения за исключением ссылок на поля Entity фильтр не допускает. :(

Ок. Попытался решить задачу обходным путем. Создал во вспомогательной БД VIEW, в которой отфильтровываются допустимые для выбора записи в привязке ко всем экземплярам процесса (параметризованные запросы, насколько я понял, не допускаются). Надеялся, что смогу отфильтровать из него нужный набор данных по текущему экземпляру процесса, задав условие фильтрации в свойствах контрола на форме. Создал виртуализованное энтити, сославшись в нем на это VIEW. Осталась самая малость - отфильтровать в виртуализованном энтити записи, которые имеют отношение только к текущему экземпляру процесса. Так ведь опять фильтр не дает этого сделать... :( :( :( Что за черезмерная интеллектуальность у него! :( Сравниваю значение int со ссылкой на ключ Master Entity, который тоже имеет тип int. BizAgi ругается - говорит, что типы данных не совпадают... :(

И на англоязычном форуме глухое молчание. Трам-тарарам... :(

Неужели такая простая задача не имеет решения?

ViPRosiscrafm,
простая, если посмотреть снизу вверх с точки зрения лукап)
сложная если сверху вниз, Роли и Взаимоотношения ролейСахават, при чем тут взаимоотношение ролей? Когда между таблицами имеются не только отношения один-ко-многим, которые можно трактовать как связь master-detail, но и имеются связи многие-ко-многим, которые необходимо учитывать в пользовательском интерфейсе, - такая ситуация весьма распространенная. Мне приходилось сталкиваться с подобной ситуацией в разных системах и жизненных ситуациях бесчисленное количество раз. И всегда выходили из нее легко и просто. Чаще всего такая ситуация разрешалась в пользовательском интерфейсе либо с помощью возможности использования параметризованного SQL-запроса, либо с помощью не-параметризованного SQL-запроса, но текст которого формируется динамически. В данном продукте нет возможности использовать SQL-запросы, она заменена XPath-коллекциями и XPath-функциями. Но в том месте, где они наиболее всего могут поднадобиться, возможность их использования почему-то закрыта.

P.S. Напрягши лобную мышцу, нашел вариант, с помощью которого можно обойти траблу, с которой столкнулся при решении исходной траблы. Сейчас создам дополнительное вспомогательное поле типа int в составе Master Entity и буду триггером присваивать ему значение такое же как у идентификатора записи. В фильтре буду ссылаться не на идентификатор записи, а на вот это вспомогательное поле. Надеюсь, при таком раскладе BizAgi уже не будет считать, что два int имеют разный тип.

АБAlexeyBKпропущено...


1. Когда вы в портале в меню "Процессы" сказали "Запустить" и указали процесс, который надо запустить, то процесс уже начал исполняться.

По идее case creation phase должно помочь: http://wiki.bizagi.com/en/index.php?title=Lane_and_Phase#Considerations_2 Спасибо, попробую. Правда вот эта фраза "All the activities in this type of phase have the property that they can return to the immediately previous activity" звучит как-то немного о другом. В моем случае речь идет об activity, у которого previous activity просто не существует.

AlexeyBK2. Да условие фильтрации отрабатывает при загрузке формы. Контрол можно заставить обновить данные, например у combobox и checkbox есть свойство Submit on Change, включите его, тогда при каждом изменении значения форма будет обновляться, соответственно все фильтры будут повторно отрабатывать.В этом случае после каждой попытки изменения значения контрола выводится дополнительный запрос в стиле "вы уверены, что хотите изменить значение этого элемента?". Этот вопрос совершенно неуместен, поэтому мне нужно что-то другое.

AlexeyBKПри нажатии на кнопку Сохранить, форма также обновляется. Также можно и свою кнопку положить на форму, и связать её с функцией, которая будет что-то вычислять и куда-то что-то прописыватьНеобходимость пользователю нажимать на кнопку "Сохранить" (или какую-то другую) после изменения значения контрола неочевидна. Юзер может просто ее не нажать, и при этом получит пустой либо некорректный набор айтемов в других контролах. Это неудачное решение. Должно быть какое-то другое. Например, обработка события потери фокуса или события AfterChange контрола, в которую можно было бы воткнуть скрипт автоматического сохранения промежуточных данных формы (Me.Save ?) и обновления источников данных для всей формы (Me.Requery ?) или для конкретных контролов формы (Me.ComboBox2.Requery ?). Ну, или типа того. Короче, эта логика должна отрабатывать в любом случае независимо от того, как поведет себя пользователь.

AlexeyBKМне кажется, что решается. Я в выходные попробую сделать ваш проект.Алексей, спасибо, конечно. И за Ваши ответы огромное спасибо. Мне, право, неловко. Не нужно делать эту задачу за меня. Достаточно подсказки, в какую сторону копать. А сделаю я сам. :)

AlexeyBKGarya,

ну я все равно не смогу все сделать. Только наброски. У меня получилась вот такая схема БД:Алексей, за попытку спасибо. Но дело в том, что по сравнению с тем как задача звучала сначала она несколько усложнилась (возможно, это несколько сбило с толку). О "пользователях" предлагаю на время забыть. Проблема в том, что у юрлиц имеются еще и филиалы. На Вашей схеме корректно отображено отношение "Класс ПО" (parent) - "Программный продукт" (child). Точно такое же отношение должно быть между "Юрлицо" (parent) и "Филиал" (child). Далее между парой чайлдов имеется таблица допустимых комбинаций. Нужно добиться, чтобы на форме после выбора из первой пары parent-child по второй паре parent-child отрабатывал фильтр, который позволяет выбрать только корректные комбинации по второй паре parent-child.

Вашу, Алексей, идею я понял так, что в энтити процесса устанавливается ссылка непосредственно на таблицу корректных соотношений. Но в ней очень много записей. Необходимо выбор сделать удобным для пользователя. Необходимо выбрать четыре сущности либо в таком порядке:
1) Класс ПО (все классы ПО)
2) Программный продукт (только выбранного класса ПО)
3) Юрлицо (включить фильтр только по допустимым комбинациям)
4) Филиал юрлица (фильтр по допустимым комбинациям + только выбранного юрлица)

либо, как альтернативный вариант решения, вот в таком порядке:

1) Юрлицо (все юрлица)
2) Филиал юрлица (только выбранного юрлица)
3) Класс ПО (включить фильтр только по допустимым комбинациям)
4) Программный продукт (фильтр по допустимым комбинациям + только выбранного класса ПО)

Насколько я понял, иного варианта решения этой задачи, нежели я предложил, просто нет. Во всяком случае, на англоязычном форуме глухое молчание уже несколько дней. Мое же решение получается каким-то уж очень громоздким. Оно требует создать вспомогательное поле типа int, приспособить к таблице энтити процесса триггер (который будет автоматом повторять в этом поле значение идентификатора записи), создать в отдельной базе данных VIEW (если пытаться делать в этой же самой, bizagi генерит ошибку, когда пытается создать таблицу с таким же именем), получить к нему доступ через виртуализированное энтити, и по нему уже настроить фильтр на форме. В общем, левой ногой через правое ухо. Конечно, в данном конкретном случае это решение - хоть какой-то выход из ситуации, но такие решения нельзя использовать в серьезных проектах. Я сейчас делаю пробный процесс, чтобы прощупать, как бороться с подводными камнями и какого рода они бывают. И этот камень весьма поубавил у меня оптимизма. Пока еще теплится очень небольшая надежда, что я нашел далеко не самое оптимальное решение, что существует более простой и изящный вариант. Но надежда эта тает...

ViPRos(Между прочим ты в последнем посте забыл про первичное отношение "Юрик-ПО", хотя из контекста можно понять, что оно присутствует)

Ничего я не забыл. Просто читая между строк, нужно не забывать читать еще и сами строки... :)
GaryaДалее между парой чайлдов имеется таблица допустимых комбинаций.

АБГоссспади... если ЭТО вопрос жизни или смерти (что вообще-то мне представляется странным)...Конечно же, это не вопрос жизни и смерти. Но то, что я сейчас делаю, это пробный проект с очень простым функционалом, на порядок более простым, нежели требуется для автоматизации главных процессов торговой компании. И я хочу иметь четкое представление о том, какие задачи и каким способом решаются. И какие могут случиться трудности. И какие могут возникнуть проблемы за гранью возможностей их решения. Я вообще могу не делать БП сервисдеск, никто мне и слова не скажет. Это моя собственная инициатива. В конце концов, сервисдеск находится исключительно в моей сфере ответственности, и я могу творить с ним всё что захочу. После того как этот процесс будет запущен в работу и в том случае, если я сам буду удовлетворен достигнутыми результатами я намерен продемонстрировать результаты своему руководству. В надежде на то, что мне будет предоставлена возможность использовать данный инструментарий для автоматизации более сложных процессов.

Однако, для этого мне следует продемонстрировать юзабилити на достаточно высоком уровне. В нашей компании этим вещам всегда уделялось внимание, и юзвери, можно сказать, избаловались. Они "встанут дыбом", если в новом инструменте что-либо будет менее удобно, нежели в старом. И если это произойдет, то вместо союзников в среде пользователей я получу противников этого инструментария. Поэтому я подхожу к этому вопросу настролько скурпулезно.

АБможно посадить программиста, чтобы сделал user field , в котором можно реализовать любую интерфейсную логику по собственному выбору.Спасибо за подсказку. Наконец-то я увидел еще одно решение этой задачи. Кстати, интересный вариант. Стоит попробовать. Конечно же, оно тоже не очень простое, но если получится сделать параметризованный контрол, который будет работать с любыми комбинациями энтити на отношениях многие-ко-многим (которые задаются в параметрах), то это, в конечном итоге, более красивое и более универсальное решение. Трудоемкие операции выполняются только один раз.

АБНо мне почему-то кажется, что ты не до конца разобрался с тем, что предложил Алексей. В его варианте пользователь задает хоть все критерии, хоть часть - получает список допустимых комбинаций - одним кликом выбирает требуемый.Я пытался построить фильтр для сабформы - натолкнулся на те же грабли. Без дополнительного поля, содержимое которого заполняется триггером, построить фильтр не получается. Я не против того, чтобы делать выбор из таблицы допустимых комбинаций (и даже "за"). Но дело в том, что в этой таблице задана связка между двумя чайлдами, то есть между ПО и филиалом. Каждая комбинация ПО-филиал появляется в ней ровно один раз, но перед тем как выбирать филиал, необходимо выбрать юрлицо. А юрлицо выбрать так, чтобы оно появлялось ровно 1 раз, не получается. Потому что в таблице допустимых комбинаций может быть несколько разных филиалов одного и того же юрлица. И если мы будем выбирать юрлицо по таблице допустимых комбинаций, мы увидим одно и то же юрлицо не один раз, а столько раз, сколько у него филиалов. В то же время в перечне юрлиц при выборе юрлица не должны показываться те, ни один из филиалов которых не использует уже указанное пользователем ПО.

АБ,

Может быть, замолвите слово по поводу расширения слишком ограниченной функциональности фильтра для контрола на форме? В идеале было бы здорово подставлять в него любые XPath-выражения. Но для начала можно было бы включить в состав выбираемых полей не только поля энтити, созданные пользователем, но и системные поля, такие как идентификатор экземпляра, планируемое время завершения, создатель и т.п. Или мне об этом лучше самому написать в "Request New Feature"?

АБ, почитал твою переписку с сапортом. И понял, что действительно лучше самому. :) Кстати, поддерживаю тебя на все 100% и восхищаюсь твоей настойчивости.

Отметился тут .

АБ...что идентификатор надо присваивать не при создании кейса (стоит по умолчанию), а при завершении case creation phase. См. http://wiki.bizagi.com/en/index.php?title=Example_Sequences Спасибо. Вот это ценная инфа.

Был в отпуске, поэтому возникла небольшая пауза. Итак, продолжим... :)

Бизагишный сапорт предолжил пользоваться совокупностью простых combo box. Я пытаюсь реализовать предложенный саппортом вариант.

Теперь мне нужно, чтобы при изменении содержимого combo_box_1 это содержимое автоматом сразу же сохранялось в entity процесса таким образом, чтобы оно могло использоваться в фильтре combo_box_2. Соответственно, источник combo_box_2 должен быть повторно запрошен с новым значением фильтра. То есть, речь идет о том, чтобы реализовать нечто вроде dynamic combo box с помощью совокупности простых combo box. При этом если, например, юзверь после выбора значения в combo_box_1 не обнаружит нужных данных в combo_box_2 и спохватится, что неправильно указал значение для combo_box_1, то после изменения значения в combo_box_1 в combo_box_2 он должен увидеть уже другой набор записей. Всё это должно работать на автомате без нажимания вспомогательных кнопок (типа "сохранить"), чтобы поведение приложения не зависело от того, забыл пользователь или не забыл нажать на кнопку, которая должна нажиматься всегда . Я так себе понимаю, что ежели кнопка должна нажиматься всегда, то ее просто не должно быть видно на форме, и связанный с ней функционал должен отрабатывать на полном автомате .

В аксессных или дельфишных формах у контролов имеются "события" ("после изменения", "при потере фокуса" и т.п.), к которым можно пришпандорить обработчик. А как в бизаги делать подобные вещи?