Ваяю нечто вроде 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-полей кроме аплода файла, сформированного за пределами системы?