0

私がやろうとしていることの高レベルの概要を説明することから始めた方がよいでしょう (念のため、私がこれをひどく間違っている場合に備えて): TFS には、「優先度」フィールドを含む「ストーリー」ワークアイテムがあります。常に 20 ～ 30 の優先度の高いストーリーがあります。例として、完全に優先順位の付けられた 20 のストーリー (1 から 20) があり、新しい最優先事項となる新しいストーリーを作成したいとします。そのため、優先度を 1 に設定し、他のすべてのストーリーの優先度を更新するサーバー側プラグインを用意して、最終的に 1 から 21 になるようにしたいと考えています (1 は新しいストーリーです)。作成したばかりです）。

このために、WorkItemChangedEvent をサブスクライブする TFS 2010 用のサーバー側プラグインを作成しました。優先度が更新されたかどうかを判断するのに十分なほどスマートであるため、この場合は作業項目のみを変更します。私が遭遇する問題は、優先度を変更して WorkItem.Save() を実行すると、WorkItemChangedEvent が再びトリガーされ、優先度が変更されたため、ロジックが true になり、再び更新および保存されることです。

以前、datetime フィールドの 1 つの時刻を 00:00:00 に更新するサーバー側プラグインを作成し (まだ 00:00:00 になっていない場合)、この動作に気付きました。時間がすでに 00:00:00 であるため、2 回目の実行では何も起こらないため、それほど大きな問題ではありませんでした。しかし、一連の作業項目全体の優先度を更新しようとするこの場合、それは取引を破るものです。WorkItem.Save() が WorkItemChangedEvent をトリガーするのを止める方法はありますか? たぶん、これを完全に行う別の方法はありますか？

4

2 に答える 2

0

これを解決する最も簡単な方法は、特定のコメントを追加してから、作業項目のコメント/履歴項目をチェックして、行っている変更の一部として最後に更新したことを確認することです。

また、安定性を維持するためにサービスを作成する方法については、次の投稿を参照してください。

于 2012-04-04T19:16:41.480 に答える
0

チェンジャー ID がサービス ID であるかどうかを確認することで、独自の拡張機能でこの問題を解決しました。そうである場合、ロジックはスキップされます。

これは、データにタグを付けるよりも少し洗練されたソリューションのようです。

var workItemChangedArgs = notificationEventArgs as WorkItemChangedEvent;
var identityService = requestContext.GetService<IdentityService>();
var changerIdentity = identityService.ReadIdentities(
    requestContext,
    new List<IdentityDescriptor> {
        IdentityHelper.CreateDescriptorFromSid(workItemChangedArgs.ChangerSid)
    },
    QueryMembership.Expanded,
    null).Single();
if (!IdentityHelper.IsServiceIdentity(requestContext, changerIdentity)) {
    // Do stuff….
}
于 2014-07-17T13:56:57.810 に答える