Перейти к содержимому

Фотография

JIRA: проблемы с доступам к статусам проблем


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 14

#1 OSD

OSD

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 22 марта 2005 - 12:30

JIRA: проблемы с доступом к статусам проблем

исходные данные:
- есть группа юзеров
- есть различные статусы проблем типа open, in progress, resolved, verified, closed

нужно:
- чтобы данная группа видела ТОЛЬКО определенные статусы определенного проекта. а именно open, in progress (сместо всех промежуточных) и closed.


Не могу никак настроить. Помогите, пожалуйста!
  • 0

#2 van

van

    Опытный участник

  • Members
  • PipPipPipPip
  • 475 сообщений
  • ФИО:Ваулин Артем Николаевич
  • Город:Россия, Санкт - Петербург

Отправлено 23 марта 2005 - 06:48

В стандартной функциональности JIRA есть возможность разграничить доступ только на уровне запросов и действий.
Т.е. для некоторой группы пользователей можно:
1. Определить перечень доступных действий (с помощью Permission Schemes)
2. Перечень запросов, которые доступны данной группе для просмотра (используя Security Schemes и Security Level)

Думаю, с помощью п. 2 можно решить Вашу проблему. Т.е. при переходе запроса в необходимый статус, менять ему Security Level.

Сам не пробовал, но вряд ли есть другая возможность решить Вашу проблему.
  • 0
Ваулин Артем
КОРУС Консалтинг
Руководитель отдела тестирования

Мой дневник

#3 OSD

OSD

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 23 марта 2005 - 09:20

Вы не могли бы подсказать также, есть ли возможность создания триггеров?

Пример:

Заведена проблемой некой группой юзеров (Customers).
Необходимо после того, как она сохранена, проклонировать её автоматически. И также автоматически продвинуть до определенного статуса, после того, как клонированная проблема переведена в определенный статус.

Т.е. есть Bug#1 и Клон Bug#1.
После того, как Клон Bug#1 перешел в статус (Assigened, Resolved,Verified) необходимо перевести Bug#1 в статус InProgress. А после перевода Клон Bug#1 в статус closed перевести автоматически Bug#1 в этот же статус.
  • 0

#4 romanl

romanl

    Активный участник

  • Members
  • PipPip
  • 129 сообщений
  • ФИО:Роман Любунь
  • Город:Львов

Отправлено 23 марта 2005 - 13:37

нужно:
- чтобы данная группа видела ТОЛЬКО определенные статусы определенного проекта. а именно open, in  progress (сместо всех промежуточных) и closed.

Я так понимаю, что вам нужно сменить список стандартных статусов на свой собственный для конкретного проекта. Поскольку статусы и их порядок определяет workflow то вам надо просто составить свою собственную workflow схему для вашего проекта. Ето возможно только для Jira не ниже v.3.0 Professional или Enterprise edition.

Думаю, с помощью п. 2 можно решить Вашу проблему. Т.е. при переходе запроса в необходимый статус, менять ему Security Level.

Нет, вы ошиблись. С помощью Security Schemes и Security Level возможно только контролировать доступ к (возможность просматривать) issue для группы/отдельного пользователя.
P.S. Посмотрите на коротенькую справку вверху страницы где есть список всех Issue Security Schemes.

Заведена проблемой некой группой юзеров (Customers).   Необходимо после того, как она сохранена, проклонировать её автоматически. И также автоматически продвинуть до определенного статуса, после того, как клонированная проблема переведена в определенный статус.

Очень знакомая проблема, надеюсь, вы не имеете никакого отношения к JForce. Я так понимаю, что Клон Bug#1 предназначаться для разработчиков действия которых должны быть не видимы для Customers. Если я угадал, то я напишу (через личную переписку или на форуме) как это зделать.
  • 0

#5 OSD

OSD

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 23 марта 2005 - 13:56

Я так понимаю, что вам нужно сменить список стандартных статусов на свой собственный для конкретного проекта. Поскольку статусы и их порядок определяет workflow то вам надо просто составить свою собственную workflow схему для вашего проекта. Ето возможно только для Jira не ниже v.3.0 Professional или Enterprise edition.

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

Например, группа Customers видит только проблемы, которые они сами создали, в статусах Open, In Progress и Сlose, а группа Developers видела бы эти проблемы и все остальные во всех существующих статусах.
  • 0

#6 romanl

romanl

    Активный участник

  • Members
  • PipPip
  • 129 сообщений
  • ФИО:Роман Любунь
  • Город:Львов

Отправлено 23 марта 2005 - 14:10

Например, группа Customers видит только проблемы, которые они сами создали, в статусах Open, In Progress и Сlose, а группа Developers видела бы эти проблемы и все остальные во всех существующих статусах.


Jira не позволяет задавать 2 workflow’a для 1-го проекта, это можно заделать только через редактирование source’ов Jira, а это чревато багами и нестабильной работой последней. Напишете зачем (идею) настолько усложнять стандартный workflow, возможно есть другие способы частично удовлетворить ваш запрос.
  • 0

#7 OSD

OSD

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 23 марта 2005 - 14:28

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

В проекте есть разные группы юзеров:
- программисты
- тестировщики
- клиенты

Клиенты должны иметь доступ только к тем багам, которые создали именно они. К тому же они не должны видеть весь процесс прохождения бага в системе.
Они доkжны видеть баг в первом статусе Open (после его создания), затем, когда им будут заниматься программисты и тестеровщики (менять статусы), клиент должен видеть только то,что баг в статусе InProgress (или даже в Open). И потом после перевода бага нами в статус Closed (последний в Workflow) клиенты должны видеть,что статус изменился.

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

#8 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 23 марта 2005 - 14:44

У нас это организовано следующим образом (правда, на TrackStudio, а не на JIRA, но в данном контексте это непринципиально).

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

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

Соответственно, для разных проектов по разному настроены workflow и права доступа.
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#9 romanl

romanl

    Активный участник

  • Members
  • PipPip
  • 129 сообщений
  • ФИО:Роман Любунь
  • Город:Львов

Отправлено 23 марта 2005 - 16:01

Если допускается что в процессе исправления баг для customer будет закрыт (он не будет иметь доступ к нему), а перед тем как переводить баг в статус in progress и прятать его к customer’у будет приходить e-mail что и будет свидетельствовать (для customer) что баг исправляется.
Если нет, то тогда надо идти сложным путем (то что предложил barancev). Но тут все будет не автоматизировано и надо будет кому-то менять статусы во внутреннем и внешнем проекте.
Есть еще вариант с модификацией самой Jira. Но тут надо модифицировать сорс (source) Jira. Это чревато багами системы если программер что-то напортачит и проблемами если надо будет перейти на новую версию, возможно еще будут проблемы с лицензией Jira. Мы так делали, нам надо было автоматически синхронизировать статусы багов в 2-х разных проектах.
  • 0

#10 OSD

OSD

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 28 марта 2005 - 07:18

Не могли бы подсказать, как избавиться от сообщений: Velocity template generation failed. при добавлении комментария.
Спасибо.
  • 0

#11 romanl

romanl

    Активный участник

  • Members
  • PipPip
  • 129 сообщений
  • ФИО:Роман Любунь
  • Город:Львов

Отправлено 28 марта 2005 - 08:20

Это баг Jira, надо ждать на update, либо связаться с support и попросить помощи, они иногда говорят как можно самому пофиксать баг. Рекомендую за регистрироваться тут и если возникают какие-то баги то посмотреть не возникало ли у кого-то подобных багав.
  • 0

#12 OSD

OSD

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 29 апреля 2005 - 05:39

Не могли бы подсказать, как сделать, что бы при переходе в новый статус в форме перехода помимо полей с новый назначением появлялось поле, в котором будет указана версия ПО, в которой ошибка была исправлена?
Заранее спасибо.
  • 0

#13 romanl

romanl

    Активный участник

  • Members
  • PipPip
  • 129 сообщений
  • ФИО:Роман Любунь
  • Город:Львов

Отправлено 05 мая 2005 - 13:54

Я не совсем вас понял, вам надо добавить поле “Fix version” на страницу “Create Issue” или “Resolve Issue”?
  • 0

#14 OSD

OSD

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 05 мая 2005 - 13:58

В Resolve форме. Как добавить в Create и так понятно:)
  • 0

#15 bionee

bionee

    Новый участник

  • Members
  • Pip
  • 7 сообщений

Отправлено 27 июня 2009 - 12:40

привет!

создайте секьюрити схему с двумя лейбелами. в одном разрешите просматривать статусы одной группе, во втором - второй.
в воркфло, в постфункции на нужном шаге, меняйте лейбел на нужный. change issue label помоему это называется)
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных