Если при обращении к JIRA API возвращается код состояния HTTP 403 - дело в капче

Если при обращении к JIRA API возвращается код состояния HTTP 403, скорее всего, причина в капче. Такая ситуация чаще всего случается в период смены пароля, например, когда истек срок его действия: если в этот период вовремя не скорректировать данные для авторизации микросервиса, который обращается к JIRA API по паре логин-пароль, тогда JIRA для учетной записи с таким логином включает режим требования ввода капчи (это можно увидеть, если вручную более трёх раз ввести некорректно пароль в интернет-браузере). В таком режиме микросервис не может подключиться, так как JIRA API будет возвращать код состояния HTTP:

HTTP 403 Forbidden

Дополнительную информацию можно также увидеть в какой-либо среде разработки, например, SoapUi или Postman:

Решение:
- ввести капчу вручную (режим требования ввода капчи JIRA отключает после первого же успешного ее (капчи) ввода);
- перевести микросервис на другой тип авторизации, например, по токену.

Записи Jira, связанные с другими ресурсами

issueFunction in linkedIssuesOfRemote("AT-*")

JQL: L2, get it!

Фильтры для JSD: 4 вспомогательных и 1 основной для email-уведомлений.

== (вспомогател) Киреевцы ==
filter = 16412
JQL:
«
"Ответственный L2" in (u.belokonenko, a.borzov, e.gorbel, e.zharova, o.dikareva, v.barakovskaya, v.rakityanskiy, e.kireev, D.Aryshtaev, a.kireeva)
».
== (вспомогател) НОВАЯ для L2 ==
filter = 16413
JQL:
«
project = SP
AND "Служебная линия обработки" = L2
AND status = Новая
AND "Ответственный L2" is EMPTY
».
== (вспомогател) ПОЛУЧЕНА ИНФОРМАЦИЯ для L2 от L1 или КЛИЕНТА ==
filter = 16414
JQL:
«
project = SP
AND "Служебная линия обработки" = L2
AND status = "Получена информация"
AND filter = 16412
».
== (вспомогател) ЗАПРОС ИНФОРМАЦИИ от L3 у L2 ==
filter = 16415
JQL:
«
project = SP
AND "Служебная линия обработки" = L2
AND "Линия OLA" = 3
AND status = "Запрос информации внутр"
AND filter = 16412
».
== (email) L2, в работу! (Киреевцы) ==
filter = 15427
JQL:
«
filter in (16413, 16414, 16415)
».

Jira: Ошибка "Unexpected server error" в "Rich Filter Controller" при открытии рабочего стола

Описание проблемы:
у некоторых пользователей при открытии рабочего стола Jira видна ошибка "Unexpected server error.", кнопка "Show details" открывает подробности:

REQUEST URL:
/rest/qoti-rich-filters/latest/gadgets/controller/load-quick-filters
REQUEST TYPE:
POST
REQUEST DATA:
{"richFilterId":8,"wantedFilters":"20-26-s25-d168-d105-d107-d111-d110-d123-d125-d126-d127-d128-d121-d167","activeFilters":{"dynamic":{"customfield_26713":["34920"]}}}
STATUS CODE:
500
STACK TRACE:
java.lang.NullPointerException
at java.util.LinkedHashSet.(LinkedHashSet.java:168)
at com.google.common.collect.Maps$7.transformEntry(Maps.java:1812)
at com.google.common.collect.Maps$10.getValue(Maps.java:1857)
at com.google.common.collect.ImmutableMap.copyOf(ImmutableMap.java:292)
...

Причина:
В структуре метаданных задач кто-то изменил поле, идентификатор которого виден в стеке ошибки (выделено красным), в данном случае было изменено наименование поля: было "Продукт (РЕО)" стало "Продукт (РЕО) old".
Увидев приписку "old" я удалил поле из списка "Dynamic Filters" (динамических фильтров) рич-фильтра проблемного рабочего стола.
Но т.к. по этому динам.фильтру у некоторых пользователей была включена фильтрация, то сервер для таких пользователей выдал указанную ошибку.

Как идентифицировать проблемное поле:
Определить поле можно либо, спросив у поддержки, либо использовать его идентификатор в поле для JQL-запросов, обращение к полю указывать в таком виде:

cf[26713] = ...

по выпадающим значениям после знака "=" можно понять, что за поле скрывается под идентификатором 26713.
После идентификации вернул поле в список "Dynamic Filters" рич-фильтра.

Что делать, чтобы избежать повторения:
Пока что решил вместо изменения старого рабочего стола создавать копию и в ее актуализировать, а старую версию удалять спустя какое-то время.

JiraSD: поиск подстроки в поле, для которого не работает тильда

Для некоторых полей не поддерживается оператор тильда "~" (CONTAINS), выражается это в появлении сообщения при попытке выполнения JQL:

Оператор '~' не поддерживается 'Бюджет проекта ПУ' полем.

или

The operator '~' is not supported by the 'Бюджет проекта ПУ' field.

Решение:
Пример поиска подстроки "Сопр" (с игнорированием регистра букв) в поле, которое не поддерживает оператор тильда "~" (CONTAINS):

issueFunction in issueFieldMatch("project = FIN AND issuetype in (Доработка) AND statusCategory != Done AND status not in (Сделан) AND \"Бюджет проекта ПУ\" is not null and statusCategory != Done", "Бюджет проекта ПУ", "(?i)Сопр")

Примечание:
возможно, для таких полей можно включить поддержку оператора тильда "~" (CONTAINS) - уверен, выяснится со временем, "сейчас для этого нет ресурса".

JiraSD: регулярные выражения

Поставлена такая задача:
отфильтровать записи в JiraSD, у которых в текстовом поле (к которому допустимо применять оператор "~") стоит одно значение "+" из трёх допустимых ("+", "-" или "null" (когда поле не задано)).

Найденное решение:
регулярные выражения и функция, которая позволяет их применять:
issueFieldMatch(subQuery, fieldname, regexp)

где, fieldname = "Зафиксирован срок выдачи".

Но эта функция очень ресурсозатратная, чем меньше количество записей, которое возвращает подзапрос "subQuery", тем быстрее отрабатывает весь JQL-запрос.

issueFunction in issueFieldMatch("project = FIN AND issuetype in (Доработка) AND statusCategory != Done AND status not in (Сделан)", "Зафиксирован срок выдачи", "^\\u002b$")

Самым быстрым вариантом оказался с проверкой наличия поля (is not null):

issueFunction in issueFieldMatch("project = FIN AND issuetype in (Доработка) AND statusCategory != Done AND status not in (Сделан) AND \"Зафиксирован срок выдачи\" is not null", "Зафиксирован срок выдачи", "^\\u002b$")

Примечание:
"быстрым" его можно назвать, лишь, относительно: 850 записей он обрабатывает за ~3,5 секунды :-(

JiraSD: еще про JQL

Выражение

labels not in (Ошибка_БЛ)

то же самое что и

labels != Ошибка_БЛ

Вместо

labels != Ошибка_БЛ

нужно применять

(labels != Ошибка_БЛ or labels is null)

JiraSD: выявление задач без трудозатрат

Задачи проекта "SP", у которых:
- "Ответственный L2" = текущий пользователь
- дата создания в текущем месяце
- в журнале работ по текущему пользователю ни одной записи:

project = SP AND "Ответственный L2" = currentUser() AND created >= startOfMonth() AND created < endOfMonth() AND issueFunction not in worklogged("after startOfMonth() before endOfMonth() by currentUser()")

JiraSD: значения смарт-фильтра "Типовая ситуация (L2)"

Значения-маркеры:
(все описанные ниже задачи имеют значение "L2" в поле "Служебная линия обработки")

1 (красный)
Описание:
Задачи, которые поступили в работу на L2 или к ответственному на L2.
JQL-выражение:
Редакция №1:

"Служебная линия обработки" = L2 and (status = Новая or (status = "Получена информация" and "Ответственный L2" = currentUser()))

Редакция №2:

("Служебная линия обработки" = L2 and status = Новая)
or
("Служебная линия обработки" = L2 and status = "Получена информация" and "Ответственный L2" = currentUser())
or
("Служебная линия обработки" = L2 and status = "Запрос информации внутр" and "Ответственный L2" = currentUser() and "Линия OLA" = 3)

2 (белый)
Описание:
JQL-выражение:

"Служебная линия обработки" = L2 and status = "В работе" and "Ответственный L2" = currentUser()

3 (черный)
Исключение:
тут в поле "Служебная линия обработки" значение "L3".
Описание:
доработки, переданные на L3, по которым нужно отслеживать изменения вручную.
JQL-выражение:

"Служебная линия обработки" = L3 and "Ответственный L3" = currentUser()

УРВ в Jira

В Jira трудозатраты по задачам можно увидеть с помощью отчетов в пунктах меню:
1) Timetracker —> Reporting:

2) Tempo —> Расписания:

Ссылки в Jira

Чтобы в Jira сделать вот такую ссылку:

Текст ссылки

нужно написать вот так:

[Текст ссылки|https://mail.ru]