Comments 11
Могли просто получить все тикеты с конкретного спринта прямо в эксель, потыкать несколько кнопочек в UI, и получить нужную табличку.
Да, можно и с борда. Оттуда менеджеры и пытались сначала грузить в excel. И не устраивало по полной.
Если доска настроена.
Если спринты ведутся как надо.
Если все задачи в спринте ровно по тем проектам, что надо.
Если точно ясна методика разнесения часов.
Если ясно, что делать с перетекающими из спринта в спринт задачами.
Если...
Что от проектов, что от доски -- почти одинаково и никак не влияет на суть. Не воспринимайте это как мега задачу. Это просто иллюстрация подхода. Была бы не джира, а что-то другое... без разницы.
Может объясните, почему постоянно так получается? Вцепились в частность, которая вообще даже не на заднем плане.
Текст -- иллюстрация по решению подобных задачек. Просто почитайте от начала до конца.
Да, Ваш ендпойнт хороший, но тут пошли сначала от проектов. В спринте много проектов, интересовали конкретные. Менеджеру удобно так думать -- прекрасно.
Прям спор как сумму в квадратной таблице считать. То ли по горизонтали, то ли по вертикали сначала.
Это АБСОЛЮТНО безразлично.
Потянули с одной нитки -- ну ладно. Потянули с другой -- пожалуйста. Главное до конца дотянуть. Ворклоги все равно остаются. Цифровой шлак никуда не делся.
Взята Jira, а мог быть наумен, гитлаб, битрикс, и прочее имя чему Легион.
Просто скажите, какую мысль хотите донести. С Вами согласился же, можно было пробовать с доски. Но EDA запустили-по другому. Третий раз отвечать на второстепенный вопрос будет уже скучно и неинтересно.
Наверное, Вы архитектор и тогда это многое объясняет.
Но непонятно, почему тогда Вы не читаете весь текст? Почти через абзац идет упоминание про документацию API. Про "магические преобразования", коими являются регулярки для json, похоже, Вы тоже не поняли. Почитайте про jq парсер, благо ссылки по тексту есть.
Поясняю еще раз, задачи подобного класса являются проходным мусором и представляют собой определенный вид инженерной/аналитической деятельности. Подключиться к чему угодно, содрать то, что надо, чтобы на выходе получить то, что требуется.
Выход = f(вход). И все части являются переменными, включая передаточную функцию. Просто посмотрите на множество различных групп. С подобными вопросами мучается каждый второй начинающий.
В таких условиях глубокое чтение API не только бессмысленно, но и просто вредно. Время = деньги. Если задача решена быстро, считается правильно, код простой и ясный -- задача закрыта, можно переходить к следующей. Главное, что решение через доску все равно приводит к работе с ворклогом.
Вам цель непонятна -- это не страшно. Вы пытаетесь аргументировать в терминах ценностей, которые многим ценны, как фантик от бумажки. Так не работает.
Конкретно Jira после закрытия on-premise ветки и высказыванием всяких позиций вообще неинтересна. Разбираться до винтиков в ее API -- бездарно и бессмысленно тратить время.
Дайте свой пример рабочего кода. Это будет хорошей аргументацией и демонстрацией. Просто комментарии "мне непонятно" писать -- дело нехитрое.
Конкретно Jira после закрытия on-premise веткиНичего они не закрывали, просто смерджили DC и Server.
Дайте свой пример рабочего кода.Сперва добейся, ага.
Я использую Java API, поэтому у меня нет необходимости корячить авторизации и парсинг JSON. Быстрый и простой код, возвращающий мапу с тикетами и ворклогами:
import com.atlassian.jira.bc.issue.search.SearchService
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.jql.parser.JqlQueryParser
import com.atlassian.jira.web.bean.PagerFilter
def projectKey = "Project Key"
def sprintName = "\"Sprint Name\""
def user = ComponentAccessor.jiraAuthenticationContext.loggedInUser
def stringQuery = "project = ${projectKey} and sprint = ${sprintName}"
def query = ComponentAccessor.getComponent(JqlQueryParser).parseQuery(stringQuery)
def searchService = ComponentAccessor.getComponent(SearchService)
def worklogManager = ComponentAccessor.worklogManager
def data = searchService.searchOverrideSecurity(user, query, PagerFilter.getUnlimitedFilter()).results.collectEntries { issue ->
[issue,
worklogManager.getByIssue(issue).groupBy {it.authorObject.displayName}.collectEntries { k, v ->
[k, v.collect{it.timeSpent}.sum() / 60 / 60]
}]
}.findAll{!it.value.isEmpty()}
А саму мапу можно уже обрабатывать как угодно, выбирая необходимые значения. Например, вернуть такую же табличку, как у вас.
Кстати, обратите внимание, я не использую апи досок и спринтов, а просто все получаю через поиск. Это можно реализовать и в вашем коде, чтобы не получать все проекты и не парсить кастомфилды.
PS Не знаю R, поэтому просто хочу спросить. Выглядит так, что ваш код не будет корректно обрабатывать, если тикет входит сразу в несколько спринтов.
Спасибо, хороший ответ.
1. Про авторизацию не совсем понял, ну есть она и есть. Проблем не доставляет.
Да, в исходном коде тоже есть jql. Проекты ищутся просто для проверки. Но он не один. Их список известен, можно и вектором задать. Но всегда бывают нюансы, пусть уж будут в том виде, как они в системе хранятся.
А еще иногда консультанты так штатные модели данных раскорячат, что сразу и не поймешь что где лежит.
Как я сразу отметил, вопрос учета -- внешний вопрос. Куда и по каким правилам соотносить затраты. Ответ сошелся -- замечательно. Не сошелся -- смотрим косяки. Народ в джиру тоже не просто так пишет, а с подвыподвертом. Как только кто-то подумает, что так нельзя по процессу, так тут же найдется кейс с нарушителем.
Вы Jira, видимо, знаете неплохо, все под руками и в горячем доступе. Но джава -- редкий случай. Есть интерфейсы и все в контуре. Для других систем (особенно живущих в облаке) REST чаще всего будет выступать общим знаменателем. Ну вот джира подвернулась под руку. Это не специально.
Может будет а может не будет. Не знаю. Вопрос пользователям. Надо ассерты ставить и изучать нарушения. Потому что это потянет за собой двойной учет -- проблема более высокого порядка чем код. Для "задачи-пятиминутки" вопрос этот выходит за рамки.
В кои то веки собрался оставить коммент на хабре: это можно (и это проще) делать запросом SQL прямо в базе. Не так уж там много взаимосвязей между таблицами. Главное сначала думать, потом делать и лучше на реплике.
Jira, Jirа! Повернись к лесу задом, ко мне передом