Это нормально!

Во-первых, под словом «Workflow» в Mantis подразумевается «Переходы состояний процесса». Но мне проще сказать «воркфлоу», нежели «переходы состояний».

Во-вторых, у нас Mantis говорит на английском языке, поэтому все дальнейшие указания я буду делать по английской версии.

Хотя там есть даже язык «волапюк»…

В третьих, нужно покопаться в коде приложения.

Залогинившись под административным аккаунтом, переходим на страницу «manage > Manage Configuration > Workflow Transitions»

По-русски: «управление > Управление конфигурацией > Переходы состояний процесса«.

По-простому: http://вашMantis/manage_config_workflow_page.php

По-умолчанию в Mantis присутствуют следующие статусы:

• new
• feedback
• acknowledged
• confirmed
• assigned
• resolved
• closed

Есть еще связанный статус ‘reopened’, но рассматривать его пока незачем.

Логика связей между статусами очень грамотная и продуманная, но подходит не всем и не всегда.

В частности, в нашем офисе разработчикам понадобился новый статус задач ‘Active’, для того, чтобы быстро узнавать, кто и чем у них занят прямо сейчас.

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

Но добавить новый статус и дальновиднее, и интереснее 🙂

По причинам удобства, хотелось, чтобы статус ‘active’ можно было устанавливать наиболее быстро и просто, без постоянного развертывания выпадающего списка статусов…

Блин, это сделать даже быстрее, чем разъяснить.

Также встал вопрос про статусы ‘acknowledged’ и ‘confirmed’. Вопрос встал такой — нафига нам эти статусы? Мы ими не пользуемся. Надо бы их прибить.

Понеслось!

Как добавить новый статус

Документацией задокументироваться (чем больше, тем лучше):

• http://www.mantisbt.org/forums/viewtopic.php?f=11&t=11873
• http://linuxsysadminblog.com/2009/03/adding-custom-mantis-bug-status/
• http://wiki.colar.net/adding_custom_bug_status_in_mantis
• http://www.mantisbt.org/forums/viewtopic.php?f=3&t=6351
• http://manual.mantisbt.org/manual.customizing.mantis.customizing.status.values.php

В файле ‘config_inc.php‘ указать (там все в одну строку, я тут перенес после запятых, чтобы верстку не ломать):

/*************************
* MantisBT Enum Strings *
 *************************/
$g_status_enum_string =
     '5:active,
     10:new,
     20:feedback,
     30:acknowledged,
     40:confirmed,
     50:assigned,
     80:resolved,
     90:closed';

В файле ‘custom_constant_inc.php‘ указать

<?php
 define ( 'ACTIVE', 5 );
 ?>

В файле ‘custom_strings_inc.php‘ указать

<?php
 if ( lang_get_current() == 'english' )
 {
 $s_status_enum_string =
     '5:active,
     10:new,
     20:feedback,
     30:acknowledged,
     40:confirmed,
     50:assigned,
     80:resolved,
     90:closed';
 $s_active_bug_button = "active";
 $s_active_bug_title = "Set Issue active";
 $s_email_notification_title_for_status_bug_active = "The following issue is active.";
 }
 ?>

Теперь давайте настраивать очередность переходов issue между статусами. Это можно сделать и руками в конфигурационном файле, но проще и нагляднее (а значит, более предсказуемо) сделать это через веб-интерфейс, на странице Workflow Transitions.

Картинка для привлечения нашего наипристальнейшего внимания:

Таблица читается следующим образом:

1. первая колонка слева — существующие статусы.
2. последняя колонка справа — следующий статус, который будет отображаться после установки статуса из левой колонки.
3. между левой и правой колонкой — статусы, переходы на которые будут возможны. Есть галочка — будет возможность перехода. Нет галочки — нет возможности перехода.

Итак, судя по галочкам из моей таблицы, если какое-нибудь issue будет лениво пребывать в статусе ‘active’, тогда:

• по-умолчанию в выпадающем списке следующий статус будет ‘resolved’. Это указано в крайней правой колонке.

• а возможные пееходы из статуса ‘active’ будут:
  • feedback,
  • assigned,
  • resolved,
  • closed.

Перепрыгнем ниже.

Если issue будет пребывать в статусе ‘assigned’, то:

• по-умолчанию в выпадающем списке следующий статус будет ‘active’.
• а следующими переходами будут
  • active,
  • feedback,
  • assigned,
  • resolved,
  • closed.

Логика понятна?

Таким образом можно установить точный и предсказуемый переход между наличными статусами. А подстановка «следующего статуса» позволяет перевести issue в следующий статус максимально быстро, избегнув двух кликов, которые нужны для раскрытия выпадающего списка и выбора нужного статуса.

Судя по галочкам в моей таблице, отсутствие галочек в колонках ‘acknowledged’ и ‘confirmed’ означает, что переходов в эти статусы не будет нигде и никогда.

Поэтому на той же странице настройки в разделе «Workflow Validation» будет указано малиновым цветом, что для статусов ‘acknowledged’ и ‘confirmed’

You cannot move an issue into this status.
You cannot move an issue out of this status.

Это нормальное явление. Пусть висит.

Когда-то случалось работать с Mantis с добавленными статусами ‘In testing’ и ‘Tested’, но в нынешнем офисе считается, что задача готова к тестированию в моменту перехода в статус ‘Resolved’. Тоже нормальное явление.

Мелкая мелочь — как в Mantis версии 1.2.2 удалить перечёркнутость с номера issue со статусом ‘resolved’:

скопировать default.css в свой файл mycss.css (находится в каталоге /css/), и заменить в этом файле line 20

a.resolved { text-decoration: line-through underline; 

на

a.resolved { text-decoration:  underline; }

и в файле config_inc.php указать:

$g_css_include_file = 'css/mycss.css';