JIRA: проблемы с доступам к статусам проблем
#1
Отправлено 22 марта 2005 - 12:30
исходные данные:
- есть группа юзеров
- есть различные статусы проблем типа open, in progress, resolved, verified, closed
нужно:
- чтобы данная группа видела ТОЛЬКО определенные статусы определенного проекта. а именно open, in progress (сместо всех промежуточных) и closed.
Не могу никак настроить. Помогите, пожалуйста!
#2
Отправлено 23 марта 2005 - 06:48
Т.е. для некоторой группы пользователей можно:
1. Определить перечень доступных действий (с помощью Permission Schemes)
2. Перечень запросов, которые доступны данной группе для просмотра (используя Security Schemes и Security Level)
Думаю, с помощью п. 2 можно решить Вашу проблему. Т.е. при переходе запроса в необходимый статус, менять ему Security Level.
Сам не пробовал, но вряд ли есть другая возможность решить Вашу проблему.
#3
Отправлено 23 марта 2005 - 09:20
Пример:
Заведена проблемой некой группой юзеров (Customers).
Необходимо после того, как она сохранена, проклонировать её автоматически. И также автоматически продвинуть до определенного статуса, после того, как клонированная проблема переведена в определенный статус.
Т.е. есть Bug#1 и Клон Bug#1.
После того, как Клон Bug#1 перешел в статус (Assigened, Resolved,Verified) необходимо перевести Bug#1 в статус InProgress. А после перевода Клон Bug#1 в статус closed перевести автоматически Bug#1 в этот же статус.
#4
Отправлено 23 марта 2005 - 13:37
Я так понимаю, что вам нужно сменить список стандартных статусов на свой собственный для конкретного проекта. Поскольку статусы и их порядок определяет workflow то вам надо просто составить свою собственную workflow схему для вашего проекта. Ето возможно только для Jira не ниже v.3.0 Professional или Enterprise edition.нужно:
- чтобы данная группа видела ТОЛЬКО определенные статусы определенного проекта. а именно open, in progress (сместо всех промежуточных) и closed.
Нет, вы ошиблись. С помощью Security Schemes и Security Level возможно только контролировать доступ к (возможность просматривать) issue для группы/отдельного пользователя.Думаю, с помощью п. 2 можно решить Вашу проблему. Т.е. при переходе запроса в необходимый статус, менять ему Security Level.
P.S. Посмотрите на коротенькую справку вверху страницы где есть список всех Issue Security Schemes.
Очень знакомая проблема, надеюсь, вы не имеете никакого отношения к JForce. Я так понимаю, что Клон Bug#1 предназначаться для разработчиков действия которых должны быть не видимы для Customers. Если я угадал, то я напишу (через личную переписку или на форуме) как это зделать.Заведена проблемой некой группой юзеров (Customers). Необходимо после того, как она сохранена, проклонировать её автоматически. И также автоматически продвинуть до определенного статуса, после того, как клонированная проблема переведена в определенный статус.
#5
Отправлено 23 марта 2005 - 13:56
Нет. Необходимо, чтобы разные пользователи в одном и том же проекте видели одни и те же проблемы но только в определенных статусах.Я так понимаю, что вам нужно сменить список стандартных статусов на свой собственный для конкретного проекта. Поскольку статусы и их порядок определяет workflow то вам надо просто составить свою собственную workflow схему для вашего проекта. Ето возможно только для Jira не ниже v.3.0 Professional или Enterprise edition.
Что-то вроде двух параллельных Workflow для одного проекта.
Например, группа Customers видит только проблемы, которые они сами создали, в статусах Open, In Progress и Сlose, а группа Developers видела бы эти проблемы и все остальные во всех существующих статусах.
#6
Отправлено 23 марта 2005 - 14:10
Например, группа Customers видит только проблемы, которые они сами создали, в статусах Open, In Progress и Сlose, а группа Developers видела бы эти проблемы и все остальные во всех существующих статусах.
Jira не позволяет задавать 2 workflow’a для 1-го проекта, это можно заделать только через редактирование source’ов Jira, а это чревато багами и нестабильной работой последней. Напишете зачем (идею) настолько усложнять стандартный workflow, возможно есть другие способы частично удовлетворить ваш запрос.
#7
Отправлено 23 марта 2005 - 14:28
В проекте есть разные группы юзеров:Напишете зачем (идею) настолько усложнять стандартный workflow, возможно есть другие способы частично удовлетворить ваш запрос.
- программисты
- тестировщики
- клиенты
Клиенты должны иметь доступ только к тем багам, которые создали именно они. К тому же они не должны видеть весь процесс прохождения бага в системе.
Они доkжны видеть баг в первом статусе Open (после его создания), затем, когда им будут заниматься программисты и тестеровщики (менять статусы), клиент должен видеть только то,что баг в статусе InProgress (или даже в Open). И потом после перевода бага нами в статус Closed (последний в Workflow) клиенты должны видеть,что статус изменился.
Нужно для того,чтобы клиенты знали,что есть баг и что он либо открыт, либо закрыт. А что в промежутке - ему знать не нужно.
#8
Отправлено 23 марта 2005 - 14:44
В трекере есть несколько "внутренних" проектов, которые соответствуют проектам разработки, и один "внешний" проект Support. Вся коммуникация с внешними клиентами происходит через проект Support, туда попадают запросы от клиентов, там с ними общаются сотрудники службы поддержки, а разработчикам туда ход закрыт.
Когда от внешнего клиента приходит запрос, который связан с некоторым дефектом, сотрудник службы поддержки заводит ещё один запрос в соответствующем "внутреннем" проекте и ставит от него зависимость. Когда дефект исправлен и выпущен релиз, в который это исправление попало, сотрудник службы поддержки получает об этом оповещение, и сообщает об этом внешнему клиенту.
Соответственно, для разных проектов по разному настроены workflow и права доступа.
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#9
Отправлено 23 марта 2005 - 16:01
Если нет, то тогда надо идти сложным путем (то что предложил barancev). Но тут все будет не автоматизировано и надо будет кому-то менять статусы во внутреннем и внешнем проекте.
Есть еще вариант с модификацией самой Jira. Но тут надо модифицировать сорс (source) Jira. Это чревато багами системы если программер что-то напортачит и проблемами если надо будет перейти на новую версию, возможно еще будут проблемы с лицензией Jira. Мы так делали, нам надо было автоматически синхронизировать статусы багов в 2-х разных проектах.
#10
Отправлено 28 марта 2005 - 07:18
Спасибо.
#12
Отправлено 29 апреля 2005 - 05:39
Заранее спасибо.
#13
Отправлено 05 мая 2005 - 13:54
#14
Отправлено 05 мая 2005 - 13:58
#15
Отправлено 27 июня 2009 - 12:40
создайте секьюрити схему с двумя лейбелами. в одном разрешите просматривать статусы одной группе, во втором - второй.
в воркфло, в постфункции на нужном шаге, меняйте лейбел на нужный. change issue label помоему это называется)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных