Принудительная ссылка в рабочем элементе ошибки сервера Team Foundation для дубликатов

Мы только начали работу с Team Foundation Server 2008/Visual Studio Team System, и мы рады узнать, как мы можем экспортировать и изменять рабочие элементы в соответствии с нашими потребностями. Однако эта последняя вещь, которая сделала бы настройку идеальной для нас, оказалась несколько сложной:

Мы экспортировали тип рабочего элемента Ошибка и внесли в него изменения, чтобы он по-разному отображался для разных групп пользователей. Однако мы видим потенциальную проблему в том, что не разработчики сообщают об ошибках, которые оказываются дубликатами. Мы хотели бы, чтобы пользователи, которые закрывают заявку с разрешенной причиной: дубликат, также создавали ссылку на ошибку, которая воспринималась как первое сообщение об ошибке.

Я просмотрел System.RelatedLinkCount и поместил правило

  <FIELD type="Integer" name="RelatedLinkCount" refname="System.RelatedLinkCount">
    <WHEN field="Microsoft.VSTS.Common.ResolvedReason" value="duplicate">
      <PROHIBITEDVALUES>
        <LISTITEM value="0" />
      </PROHIBITEDVALUES>
    </WHEN>
  </FIELD>

Однако, когда я пытаюсь поместить что-либо в эту область, импортер сообщает мне, что System.RelatedLinkCount не принимает правило, независимо от того, что я добавляю, но правило выше показывает, что я пытаюсь сделать (хотя наиболее предпочтительное правило также проверил бы, что ошибка, на которую я ссылаюсь, также не является дубликатом, хотя это излишне: P)

Кто-нибудь еще пытался применять такие правила в рабочих элементах? Есть ли другой подход к решению той же проблемы? Я благодарен за любые мысли по этому вопросу.


tfs tfs-process-template tfs-workitem
person Tewr    schedule 20.05.2009    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Делать именно то, что вы хотите, довольно сложно в текущих версиях TFS. (Расширенное связывание 2010 года упрощает задачу.) Я считаю, что вам нужно будет написать как минимум свой собственный тип ссылки и, возможно, также настраиваемый элемент управления полем. Эти интерфейсы не очень хорошо задокументированы в MSDN, хотя есть примеры в сторонних блогах.

Лучшее компромиссное решение IMO — создать новое целочисленное поле под названием «идентификатор повторяющейся ошибки». Когда ошибка переходит в состояние «Решено», а поле «Решение» является «дубликатом», это поле становится обязательным. Во всех остальных случаях он доступен только для чтения (и пуст по умолчанию). Таким образом, вся необходимая информация фиксируется. Недостатки:

  • «ссылка» не является двунаправленной; невозможно увидеть из оригинальной ошибки, что более поздняя ошибка была обманута против нее
  • для перехода к исходной ошибке из дубликата требуется CTRL+G вместо двойного щелчка

Я думаю, что они незначительны для быстрого решения, которое удовлетворяет 90% остальных требований.

person Richard Berg    schedule 28.08.2009

arrow_upward
1
arrow_downward

Я не уверен, что можно предотвратить это непосредственно при устранении ошибки как дубликата. Даже с идеей, над которой вы работаете, нет подтверждения того, что ссылка ведет на реальную ошибку.

Вместо этого вы можете попробовать написать отчет, который подтверждает, что любой дубликат с исправленной ошибкой имеет связанную ссылку, которая ведет к другой ошибке. Пусть ответственные члены команды просматривают этот отчет примерно раз в неделю. Немного добродушного «обвинения и стыда» имеет большое значение для поддержания чистоты проекта. ;)

person Rob McCready    schedule 28.08.2009

arrow_upward
0
arrow_downward

Этого можно добиться, создав строковое поле «приятель», которое задает свое значение в соответствии с RelatedLinkCount, а затем применяет правила к полю приятеля в соответствии с устраненной причиной.

person Aidan Ryan    schedule 08.09.2010