Да совладал, совладал... :)))
Но вот только в штатной поставке нет официальной поддержки следующей функциональности: есть несколько проектов, в каждом проекте есть по две группы: программистов и тестировщиков. Причем состав этих групп для этих двух проектов различный. После завершения этапа разработки при переводе запроса на этап тестирования хочется, чтобы для проекта А отображались тестировщики проекта А, а для проекта Б - тестировщики проекта Б. Отображать весь перечень assignable users для того или иного проекта не интересно. Это делается путем установки хака, с которым я пока не разобрался до конца.
Кроме этого хочется, чтобы определенный transition, например, "перевести запрос в тестирование", видели и могли исполнить только члены определенной группы, например, руководители программистов, которые для проекта А и для проекта Б различные. Опять же в штатной поставке этого нет и нужно ставить очередную "приблуду". :)))
А в остальном проблем вроде не было.

[

Максим, не в той ветке дал ответ вам. Смотрите на уровень выше в этой же теме.

Спасибо, Максим, за ваш ответ.
За это время я в целом разобрался в JIRA и нашел ответы практически на все вопросы сам. Нужно было сделать все своими руками. Вначале выстроил длинную цепочку (не особо разобравшись, а нужно ли мне это), потом спрямил и объединил некоторые звенья процесса - стало короче и понятнее. Остались два вопроса, на которые не могу найти времени, чтобы установить плагин (точнее хак) и проверить его - ограничение множества возможных assigner'ов при transition в зависимости от роли и ограничение на видимость (выполнимость) transition в завимости от роли.
В остальном же система оказалась вполне приемлемой. Настривать, правда, с нуля ее довольно муторно, после первичной настройки приходится еще докручивать какие то мелочи, которые не видны сразу при просмоте workflow. Проше оказыватеся выгрузить в XML и прикрутить там с последующим импортом из XML.
За ваши ссылики спасибо. Я читал ваши статьи еще до этого.
Пару вопросов по вашей системе. Возможен ли в вашу систему импорт данных из JIRA? Есть ли триальная версия вашей системы, чтобы ее установить импортнуть из JIRA и посмотреть, насколько это будет удобнее. Сравнительная таблица - это лишь таблица, а вот когда пару ошибок/требований проведешь через систему - впечатление совсем другое может быть... :)))

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

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

Сорри, уважаемые маэстро, если задаю дурацкий вопрос! Однако, я уже три дня положил на эту систему и никак не могу внять, как настроить следующий процесс и разделение полномочий.

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

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

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

Сделал вначале соответствующие статусы в воркфлоу, но реально работает только одна фаза Resolved, а потом все остается, по сути, в этом "начальном" Resolved -- разработка ФС. Все остальные фазы считаются как единый для всех статус Fixed, что не верно.

Пытался сделать через кастомизируемое поле с радиокнопками для выбора фазы (статуса), тогда получается, что все группы пользователей видят все заявки без возможности выбора фазы (статуса).

Не смог сделать автоматическое "проталкивание" запроса на следующую фазу с назначением ответственного после успешного завершения текущей фазы.

А когда подумал, что еще есть промежуточные задачи типа "Согласование ТЗ", "Повторная доработка ТЗ после согласования", "Утверждение ТЗ", так вообще стало грусно...

Смотрел я и пермишены, и скрины, но не складывается все это в стройную красивую картинку. :( Может быть я слишком многого хочу от систему багтреккинга? Создается впечатление, что я хочу пластмассовым калькулятором гвозди заколачивать. Помогите советом, пожалуйста!