К сожалению, «из коробки» в JIRA нет такой возможности. Но подобную функциональность можно получить воспользовавшись сторонним бесплатным плагином для JIRA — Script Runner. Плагин имеет в своем составе ряд уже готовых к использованию JQL выражений, к тому же он позволяет создавать новые JQL на Groovy.
Например, если говорить о вашем примере, то частичный поиск по fixVersion может быть написан следующим образом (имитация begin with с помощью регулярных выражений):
project = "Awesome Graphs for Stash" AND fixVersion in versionMatch("1.*")
По полю Labels можно искать с помощью функции issueFieldMatch и регулярных выражений (в примере ниже будут найдены заявки в проекте AWEGRAPHS, у которых есть лейблы, начинающиеся на ие):
issueFunction in issueFieldMatch("project = AWEGRAPHS", "labels", "ие*")
Стоит отметить, что на мой, конечно же, субъективный взгляд и на отзывы клиентов с производительностью в JIRA 6.x уже стало на порядок лучше (не в пример тому, как было в JIRA 4.х, если проводить аналогии). Но на производительность работы JIRA влияет множество факторов, каждый из которых стоит анализировать и учитывать на каждом конкретном экземпляре JIRA.
Если же отвечать на ваш вопрос, то, как мне кажется, в JIRA 6.2 хуже с производительностью не стало, но и лучше, чем в JIRA 6.x тоже не будет. Все-таки текущий релиз JIRA направлен на добавление нового функционала и баг-фиксы, нежели на покрытие требований по производительности.
К слову, сейчас ребята из Атлассиан активно адаптируют JIRA для работы в кластере — JIRA High Availability and Clustering. Какие-либо сроки выпуска на данный момент еще четко не очерчены, но, скорее всего, это событие случится уже в этом году.
Спасибо за ваше мнение, приятно слышать подобные положительные впечатления от использования JIRA.
Но все-таки отмечу, что непосредственного участия в разработке JIRA автор поста не принимает, занимаясь на постоянной основе разработкой плагинов для JIRA.
Верное замечание. Но за хороший продукт, как и за любую другую хорошую вещь, приходится чем-то жертвовать — в данном случае деньгами :)
Тем не менее на рынке сегодня существует достаточно много иструментов, которые можно использовать в качестве баг-трекера. Например, YouTrack от ребят из JetBrains, как мне кажется, является отличной альтернативой JIRA, но по более дружелюбной цене.
Например, если говорить о вашем примере, то частичный поиск по fixVersion может быть написан следующим образом (имитация begin with с помощью регулярных выражений):
project = "Awesome Graphs for Stash" AND fixVersion in versionMatch("1.*")По полю Labels можно искать с помощью функции issueFieldMatch и регулярных выражений (в примере ниже будут найдены заявки в проекте AWEGRAPHS, у которых есть лейблы, начинающиеся на ие):
issueFunction in issueFieldMatch("project = AWEGRAPHS", "labels", "ие*")Стоит отметить, что на мой, конечно же, субъективный взгляд и на отзывы клиентов с производительностью в JIRA 6.x уже стало на порядок лучше (не в пример тому, как было в JIRA 4.х, если проводить аналогии). Но на производительность работы JIRA влияет множество факторов, каждый из которых стоит анализировать и учитывать на каждом конкретном экземпляре JIRA.
Если же отвечать на ваш вопрос, то, как мне кажется, в JIRA 6.2 хуже с производительностью не стало, но и лучше, чем в JIRA 6.x тоже не будет. Все-таки текущий релиз JIRA направлен на добавление нового функционала и баг-фиксы, нежели на покрытие требований по производительности.
К слову, сейчас ребята из Атлассиан активно адаптируют JIRA для работы в кластере — JIRA High Availability and Clustering. Какие-либо сроки выпуска на данный момент еще четко не очерчены, но, скорее всего, это событие случится уже в этом году.
Но все-таки отмечу, что непосредственного участия в разработке JIRA автор поста не принимает, занимаясь на постоянной основе разработкой плагинов для JIRA.
Тем не менее на рынке сегодня существует достаточно много иструментов, которые можно использовать в качестве баг-трекера. Например, YouTrack от ребят из JetBrains, как мне кажется, является отличной альтернативой JIRA, но по более дружелюбной цене.