Comments 7
Всё думаю аналогично прикрутить гитхаб — чтобы прямо в UI программы писали отзывы, а оно сразу в бэклог.
Но, группировку и классификации придумывать лень, поэтому всё откладываю.
Но, группировку и классификации придумывать лень, поэтому всё откладываю.
Получение API токена:
Логинимся в id.atlassian.com/manage/api-tokens
… и вот так незаметно вы выкинули за борт то большинство пользователей, у которых Джира своя, on-premise, не связанная с Atlassian ID. Да, конечно, REST API там тоже есть, но там нет токенов в принципе и надо каждый раз логиниться по логину-паролю.
Но вообще, кажется, самое главное в этой статье — блок-схема. Когда решили ограничить сверху число багов числом практик — это сразу на корню решило потенциальную проблему дублирования, решило проблему скептичного отношения к автоматическим багам. Но с другой стороны, добавило усилий для изначального triage — как быть, если в практике две совершенно разные проблемы? С текущим подходом они уйдут в один баг, который живой человек должен прочитать, понять, что вторая проблема не имеет отношения к первой и засабмитить ее отдельно (видимо)?
Да, конечно, REST API там тоже есть, но там нет токенов в принципе и надо каждый раз логиниться по логину-паролю.
Спасибо за замечание. Что мешает так же создать отдельного пользователя для использования его емейла и пароля только для REST API? Используя описанный HTTP basic auth developer.atlassian.com/server/jira/platform/basic-authentication
С текущим подходом они уйдут в один баг, который живой человек должен прочитать, понять, что вторая проблема не имеет отношения к первой и засабмитить ее отдельно (видимо)?
В данном случае, если модератор видит, что проблема не в его зоне ответственности, то он решает те проблемы что может сам (например, грамматические ошибки — добавляя комментарий о решении), и потом переводит на нужного человека. При большом количестве таких случаев можно заводить баги в разных эпиках — свой эпик под каждый вид модератора (но у нас пока такой необходимости нет, все проблемы решаются одной командой).
Что мешает так же создать отдельного пользователя для использования его емейла и пароля только для REST API?
Ну так я это и написал — ходить каждый раз по логину и паролю :) Естественно, персональные credentials в скрипты никто не зашивает, естественно, есть стопка faceless аккаунтов соответствующих.
Чтобы не разбираться с форматами, можно взять готовую обертку для Jira. Например www.npmjs.com/package/jira-connector. Он поддерживает основные API. Из коробки не использует HTTP Keep-Alive и были проблемы с аттачами, но решения быстро гуглятся.
Sign up to leave a comment.
Как мы обрабатываем жалобы пользователей с помощью JIRA (REST API)