<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="ru">
		<id>https://lib.custis.ru/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Rfs</id>
		<title>CustisWiki - Вклад участника [ru]</title>
		<link rel="self" type="application/atom+xml" href="https://lib.custis.ru/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Rfs"/>
		<link rel="alternate" type="text/html" href="https://lib.custis.ru/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%92%D0%BA%D0%BB%D0%B0%D0%B4/Rfs"/>
		<updated>2026-05-09T10:58:35Z</updated>
		<subtitle>Вклад участника</subtitle>
		<generator>MediaWiki 1.26.4</generator>

	<entry>
		<id>https://lib.custis.ru/index.php?title=Jira&amp;diff=9875</id>
		<title>Jira</title>
		<link rel="alternate" type="text/html" href="https://lib.custis.ru/index.php?title=Jira&amp;diff=9875"/>
				<updated>2008-09-01T14:16:17Z</updated>
		
		<summary type="html">&lt;p&gt;Rfs: минусы JIRA - интерфейс&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Atlassian JIRA (http://www.atlassian.com/software/jira/) — система чуть более широкая, чем только багтрекер, это Issue Tracking system — то есть система учета запросов как таковых. Система имеет веб-интерфейс, очень гибко настраивается под конкретный проект.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Чем оперирует ==&lt;br /&gt;
&lt;br /&gt;
Система выполняет учет типизированных запросов/задач с определённым набором полей. Можно описывать новые типы запросов (Custom Issues), помимо встроенных. Начальный набор типов запросов такой:&lt;br /&gt;
&lt;br /&gt;
{| border=1&lt;br /&gt;
 !Bug&lt;br /&gt;
 |Проблема мешающая функционированию продукта&lt;br /&gt;
 |-&lt;br /&gt;
 !Improvement&lt;br /&gt;
 |Улучшение — не новый функционал, а улучшение старого&lt;br /&gt;
 |-&lt;br /&gt;
 !New Feature&lt;br /&gt;
 |Заказ на новый функционал продукта&lt;br /&gt;
 |-&lt;br /&gt;
 !Task&lt;br /&gt;
 |Задание (дело, задача) которое должно быть выполнено&lt;br /&gt;
 |}&lt;br /&gt;
&lt;br /&gt;
Группируются запросы/задания в первую очередь по «Проектам» (аналог «Продуктов» Bugzilla), затем по компонентам. Есть дополнительный уровень группировки — «Проекты» могут делится по «Категориям».&lt;br /&gt;
&lt;br /&gt;
Атрибутика запроса/задания:&lt;br /&gt;
{| border=1&lt;br /&gt;
 !Информация&lt;br /&gt;
 |Аналог «Bugzilla» «Summary»&lt;br /&gt;
 |-&lt;br /&gt;
 !Тип запроса&lt;br /&gt;
 |Bug,New Feature,Task,Improvement&lt;br /&gt;
 |-&lt;br /&gt;
 !Уровень доступа&lt;br /&gt;
 |-&lt;br /&gt;
 !Приоритет&lt;br /&gt;
 |Аналог «Bugzilla» «Severity» (Blocker,Critical,Major,Minor,Trivial) &lt;br /&gt;
 |-&lt;br /&gt;
 !Срок исполнения&lt;br /&gt;
 |Аналог «Bugzilla» «Deadline»&lt;br /&gt;
 |-&lt;br /&gt;
 !Компоненты&lt;br /&gt;
 |В отличие от «Bugzilla», здесь задание может относится сразу к нескольким компонентам&lt;br /&gt;
 |-&lt;br /&gt;
 !Версии, в которых найдена проблема&lt;br /&gt;
 |Аналог «Bugzilla» «version»&lt;br /&gt;
 |-&lt;br /&gt;
 !Закрыт в версии(-ях)&lt;br /&gt;
 |Аналог «Bugzilla» «Target milestones»&lt;br /&gt;
 |-&lt;br /&gt;
 !Назначен&lt;br /&gt;
 |Аналог «Assignee»&lt;br /&gt;
 |-&lt;br /&gt;
 !Автор&lt;br /&gt;
 |Аналог «Reporter»&lt;br /&gt;
 |-&lt;br /&gt;
 !Окружение&lt;br /&gt;
 |Аналог «Bugzilla» «OS»+&amp;quot;Platforms&amp;quot;, но ненормализованное описание — чистый текст&lt;br /&gt;
 |-&lt;br /&gt;
 !Отслеживание сроков&lt;br /&gt;
 |Аналог «Bugzilla» «Time estimated»&lt;br /&gt;
 |-&lt;br /&gt;
 !Вложение&lt;br /&gt;
 |Аналог «Bugzilla» «Attachements»  &lt;br /&gt;
 |}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Эти атрибуты обязательно существуют в каждом запросе/задании, но есть понятие раскладки полей (Layout Schemes), и в этих раскладках некоторые поля можно делать обязательными или необязательными, прятать и т. п. Каждую раскладку можно связать индивидуально с типом запроса и/или проектом. Можно описывать дополнительные атрибуты (Custom fields), которые отдельны для каждого типа запроса, и также управлять их использованием через раскладки полей. Каждый запрос/задание имеет Статус, аналог состояния в Bugzilla (State).&lt;br /&gt;
&lt;br /&gt;
Начальный набор состояний-статусов (его можно изменять) приведен ниже:&lt;br /&gt;
   &lt;br /&gt;
{| border=1&lt;br /&gt;
 |Open&lt;br /&gt;
 |аналог «NEW»&lt;br /&gt;
 |-&lt;br /&gt;
 |In Progress&lt;br /&gt;
 |аналог «ASSIGNED»&lt;br /&gt;
 |-&lt;br /&gt;
 |Resolved&lt;br /&gt;
 |аналог «Resolved»&lt;br /&gt;
 |-&lt;br /&gt;
 |Reopened&lt;br /&gt;
 |аналог «Reopened»&lt;br /&gt;
 |-&lt;br /&gt;
 |Closed&lt;br /&gt;
 |аналог «Closed»&lt;br /&gt;
 |}&lt;br /&gt;
&lt;br /&gt;
Набор результатов обработки запросов/заданий, или как они названы в русском интерфейсе — резолюций, — также аналогичен багзилльному. Этот набор тоже можно изменять. Начальный набор — следующий:&lt;br /&gt;
&lt;br /&gt;
{|&lt;br /&gt;
 |Fixed: &lt;br /&gt;
 |-&lt;br /&gt;
 |Won't Fix:&lt;br /&gt;
 |-&lt;br /&gt;
 |Duplicate:&lt;br /&gt;
 |-&lt;br /&gt;
 |Incomplete:&lt;br /&gt;
 |Недостаточно информации&lt;br /&gt;
 |-&lt;br /&gt;
 |Cannot Reproduce:&lt;br /&gt;
 |«Works for me»&lt;br /&gt;
 |}&lt;br /&gt;
&lt;br /&gt;
== Схема жизненного цикла (workflow) ==&lt;br /&gt;
&lt;br /&gt;
В отличие от багзильного, схему обработки запросов (workflow scheme) можно настраивать, т. е. создавать альтернативные графы перехода состояний (+можно заводить дополнительные состояния), и заставлять задания в проектах подчиняться этой схеме. Новый схемы обработки привязываются к проектам и к типам запросов для отдельных проектов.&lt;br /&gt;
&lt;br /&gt;
== Пользователи ==&lt;br /&gt;
&lt;br /&gt;
Учетные записи пользователей управляются как администратором, так и самим пользователем. Пользователи могут быть объединены в группы, то есть совершенно привычная структура. При чём как отдельному пользователю так и группе можно запретить/разрешить одно вполне конкретное действие (к примеру такая экзотика, как запрет на удаление приложенных файлов и создание комментариев для менеджеров из других проектов).&lt;br /&gt;
&lt;br /&gt;
== Безопасность ==&lt;br /&gt;
Умеет создавать и вести «схемы безопасности» для каждого из проектов. То есть можем создать группу пользователей на конкретный проект, раздать на этот же проект права, или использовать стандартную схему безопасности на этот проект.&lt;br /&gt;
&lt;br /&gt;
== Оповещение == &lt;br /&gt;
&lt;br /&gt;
Как узнают пользователи о том, что их сообщение было отредактировано, или о том, что им адресовано новое сообщение. По аналогии со «схемами безопасности» каждому проекту может быть создана «схема оповещения», в которой указывается на какое событие как должна реагировать система оповещения, которая рассылает почтовые сообщения. &lt;br /&gt;
В отличие от [[Bugzilla]], где схема оповещения («email settings») — настраивается каждым пользователем для себя индивидуально, здесь схемы оповещения глобальные.&lt;br /&gt;
&lt;br /&gt;
Атрибута «CC:» здесь нет, но каждый пользователь вправе подписаться на оповещения по любому делу, либо вписать кого-то еще. Правда, я ([[Участник:StasFomin|Стас Фомин]]), не нашел, как узнать, кто еще подписан на данное задание.&lt;br /&gt;
&lt;br /&gt;
== Плюсы и минусы относительно Bugzilla ==&lt;br /&gt;
&lt;br /&gt;
=== Плюсы ===&lt;br /&gt;
&lt;br /&gt;
* Возможность заведения своих workflow-схем. Это можно реализовать в bugzilla (поменяв один файл шаблонов), но эти изменения надо будет уже аккуратно синхронизировать с следующими версиями.&lt;br /&gt;
* Настройка видимости полей и дополнительные атрибуты, т. е. по сути настройка атрибутики дела — в Bugzille это решаемо только изменением кода.&lt;br /&gt;
* Всякие красивости (много иллюстрирующих иконок, заготовки для просмотра статистки по отфильтрованым багам и т. д.).  &lt;br /&gt;
* Есть русифицированный интерфейс&lt;br /&gt;
* Комментарии по заданиям можно делить по типу — комментарий или worklog, и регулировать уровень видимости по каждому комментарию.&lt;br /&gt;
* Зависимости между заданиями можно делать разных типов.&lt;br /&gt;
* Есть также иерархия подзаданий, т. е. под каждым заданием, можно создать дерево из ПодЗаданий (SubTask).&lt;br /&gt;
* Есть гибкая настройка схем оповещения: схема определяет, кто получает оповещения на каждое из имеющихся событий, задавая пользователя, группу, или метаадреса (как например: текущий исполнитель, руководитель проекта и т.д). Кроме того, можно оформлять подписки на результат определенного фильтра (аналог поискового запроса в Bugzilla).&lt;br /&gt;
* Возможно задание произвольного количества типов связей между запросами/заданиями. Зависимости и дублирование — лишь частные случаи (типы) связей.&lt;br /&gt;
* Возможна интеграция с CVS. При ведение комментариев на commit определенным образом (теги) — возможен просмотр от запроса (аналога бага) списка файлов в cvs, измененных для его выполнения.&lt;br /&gt;
&lt;br /&gt;
=== Минусы ===&lt;br /&gt;
&lt;br /&gt;
* Нет отображения графов зависимостей в виде диаграммы: зависимости отображаются в виде списка с отступами.&lt;br /&gt;
* Нет ключевых слов и соответствующей функциональности, но это легко добавляется пользовательским полем.&lt;br /&gt;
* Нет флагов и соответствующей функциональности.&lt;br /&gt;
* Уебищный интерфейс (POST-запрос при открытии формы создания бага, куча никому не нужных pop-ups, длинная простыня атрибутов для поиска на пустом экране)&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:Программирование]]&lt;br /&gt;
{{replicate-from-custiswiki-to-lib}}&lt;/div&gt;</summary>
		<author><name>Rfs</name></author>	</entry>

	</feed>