JIRA: Отображение поля на основе параметров другого поля

Типичная задача, которой нет в базовом варианте JIRA. 

Существуют некоторые обходные пути, посредством работы JS. Скрипт вставляется в описание необходимого поля. 

Существует описанный пример вот тут и тут Но данный пример осуществляет не совсем то, что необходимо на практике. Разберем пример: 

<script type="text/javascript"> priority = document.getElementById('priority'); if (priority) { target = document.getElementById('customfield_10000'); // Hide the target field if priority isn't critical if (priority.value != 2) target.style.display='none'; priority.onchange=function() { if (this.value == 2) { target.style.display = ''; target.value="enter message here"; } else { target.style.display='none'; } } } </script>

JIRA: Сбросить счетчик задач, после их удаления

Во время настройки нового проекта, создается много тестовых задач, при этом счетчик (нумерация) этих задач не обнуляется и не переиндексируется, после удаления тестовых issue. 

Чтобы обнулить этот счетчик - существует workround описанный здесь: 

А - необходимо изменить на код своего проекта. 

Выполнить команды ниже на вашем сервере MSSQL (или другой БД которая используется JIRA)

1 команда

UPDATE project SET pcounter=0 WHERE pkey='A';

2 команда

DELETE FROM moved_issue_key WHERE old_issue_key like 'A-%';

Для того, чтобы провести ревизию лицензий - использовались различные инструменты из маркета Atlassian (аддоны) и скрипт PS, для удаления неактивных пользователей. Список неактивных пользователей формировался из установленных аддонов.

Используемые плагины для JIRA

Admin Tools for JIRA

Используемые плагины для Confluence

User Management for Confluence

Gitlab: 403 Forbidden ошибка

В Gitlab используется механизм защиты, похожий на отражение DDOS атак. Именуется rack_attack. 

Было замечено, что открытая вкладка в браузере Chrome - может опрашивать страницу постоянно, для получения новых данных. Таким образом rack_attack активируется и на стартовой странице появляется сообщение Forbidden. 

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

на сервере gitlab: /etc/gitlab/gitlab.ru

gitlab_rails['rack_attack_git_basic_auth'] = { 'enabled' => false, 'ip_whitelist' => ["127.0.0.1","10.2.0.0/16"], 'maxretry' => 10, 'findtime' => 60, 'bantime' => 3600 }

Если блок закомментирован - rack_attack все равно работает. Необходимо раскомментировать и прописать false для поля enabled. 

Gitlab: отправка mail notifications с помощью SMTP

В официальной документации говорится о том, что Exim (который по умолчанию установлен в нашем шаблоне debian) - не поддерживается gitlab. А точнее работает, но слегка кривовато (то отправляет, то не отправляет). 

Поэтому было принято решение использовать стандартный SMTP сервер. 

Необходимые действия

sudo nano /etc/gitlab/gitlab.rb

Находим блок 

gitlab_rails['smtp_enable'] = true gitlab_rails['smtp_address'] = "smtp.server" gitlab_rails['smtp_port'] = 465 gitlab_rails['smtp_user_name'] = "smtp user" gitlab_rails['smtp_password'] = "smtp password" gitlab_rails['smtp_domain'] = "example.com" gitlab_rails['smtp_authentication'] = "login" gitlab_rails['smtp_enable_starttls_auto'] = true gitlab_rails['smtp_openssl_verify_mode'] = 'peer'

Расскоментируем и исправим всего несколько параметров (для нашего случая)

Используемый сервер SMTP не требует авторизации, внутри нашей сети. 

gitlab_rails['smtp_address'] = "post21v.corp.loc" gitlab_rails['smtp_port'] = 25

Строчку 

gitlab_rails['gitlab_email_from'] = 'gitlab@rb.myserver.ru'

Необходимо найти выше 

После редактирования конфигурации - необходимо "пересобрать" gitlab:

sudo gitlab-ctl reconfigure

Теперь уведомления будут корректно приходить.