VSTS — BoardColumn не работает в запросах

В VSTS Online использование BoardColumn в качестве критерия запроса или его использование в качестве столбца в результатах запроса не работает.

Например, у нас есть настраиваемые столбцы, начиная с Committed и заканчивая дополнительными состояниями. Кажется, что система позволяет нам запрашивать только стандартные имена столбцов, которые соответствуют значениям состояния.

Если я запрашиваю BoardColumn = Committed, запрос возвращает рабочие элементы, которые находятся в зафиксированном столбце или любом из последующих столбцов, а отображаемое значение для BoardColumn в результатах запроса просто говорит «Committed», потому что это значение состояния на эти рабочие элементы.

Кроме того, использование одного из настраиваемых столбцов, например «В контроле качества», в качестве значения критерия для столбца доски возвращает нулевые результаты, даже если в этом столбце есть рабочие элементы.

Это не имеет смысла. Почему функциональность запроса на самом деле не смотрит на значение BoardColumn при запросе? Почему в результате запроса отображается состояние, а не BoardColumn?


azure-devops agile kanban scrum
person Pittsburgh DBA    schedule 05.03.2016    source источник
comment
Вероятно, проблема связана с вашим запросом, так как я постоянно запрашиваю пользовательские столбцы доски, и все работает нормально.   -  person Daniel Mann    schedule 05.03.2016
comment
@DanielMann Я попробовал это с BoardColumn в качестве единственного критерия, и поведение такое же.   -  person Pittsburgh DBA    schedule 05.03.2016
comment
Обновите свой вопрос, указав выполняемый вами запрос рабочего элемента, который не дает результатов.   -  person Daniel Mann    schedule 06.03.2016
comment
Это VSTS Online. Это визуальный редактор критериев. Это не окно кода. Единственным критерием является столбец доски = In QA   -  person Pittsburgh DBA    schedule 06.03.2016
comment
Тогда я не знаю, что вам сказать - я смотрю на свой экземпляр VSTS, в котором у меня есть запрос, который включает предложение столбца доски, и он работает нормально.   -  person Daniel Mann    schedule 06.03.2016
comment
В яблочко. Вот почему я опубликовал это. Я надеюсь, что это случилось с другими, или, возможно, уже где-то задокументировано. Мои поиски ни к чему не привели.   -  person Pittsburgh DBA    schedule 06.03.2016
comment
Я не могу воспроизвести эту проблему. Результат запроса с пользовательскими столбцами правильный. Можете ли вы поделиться скриншотом настроек ваших столбцов и настроек запроса?   -  person Eddie Chen - MSFT    schedule 07.03.2016
comment
@PittsburghDBA Можете ли вы сделать мне одолжение и добавить [Столбец доски] в запрос (который фиксирует ваши пользовательские истории), используя параметры столбца, а затем запустить запрос и поделиться значением поля [Столбец доски] в списке? Как и в случае с другими комментариями, это работает для меня, но есть некоторые интересные особенности поведения, связанные с тем, какая доска владеет рабочим элементом и может устанавливать значение.   -  person Dave White    schedule 07.03.2016

Ответы (2)


arrow_upward
1
arrow_downward

Несколько недель назад столкнулся с похожей проблемой. Наша команда была разделена на две части, и одна из новых команд использовала доску Канбан. Для разделения мы использовали информацию на Visualstudio.com

Мы заметили, что хотя элементы располагались в правильном столбце доски, любые запросы возвращали старое состояние (т. е. зафиксированы).

Намек на проблему был найден на visualstudio.uservoice.com, где они обсуждали, какие команды владеют элементом. В конце концов я понял, что хотя у наших двух новых команд была своя собственная итерация невыполненной работы, то же самое было и у старой «корневой» команды. Изменение пути Backlog Iteration старой команды на некоторую подитерацию решило проблему для нас. Кажется, старая команда все еще считалась владельцем.

Возникает вопрос: виден ли ваш рабочий элемент на другой доске? Тогда это может быть решением.

Это все локальная версия TFS 2017.

person Kim van Winden    schedule 02.02.2017
comment
Я тоже вижу такое поведение: если команда, которой принадлежит рабочий элемент (т. е. поле команды в нашем случае), перемещает рабочий элемент по столбцам, значение столбца доски изменяется. В противном случае он отражает только исходные состояния в измерении столбца доски. Если поле команды не используется, скорее всего, это будет путь к области, определяющий право собственности на рабочий элемент. - person llykke; 03.08.2017

arrow_upward
0
arrow_downward

Похоже, что VSTS сохранит информацию столбца доски для команды, которая «владеет» элементом. Элемент можно перемещать по разным доскам на разных уровнях команды, но результат запроса отражает команду, которой принадлежит элемент. Например, если элемент принадлежит области Команды, то его размещение на доске будет отражено в запросе. Место родительской Команды на доске не будет отражено. Это верно, если у вас также есть вложенные группы/области.

person Sean    schedule 05.11.2017