TFS 2010: WorkItem.Save löst wieder WorkItemChangedEvent aus

Question

Ich beginne besser damit, einen Überblick über das, was ich versuche, zu erklären (nur für den Fall, dass ich das schrecklich falsch mache): In TFS haben wir eine Arbeitselement "Story", das ein Feld "Priorität" enthält. Zu jeder Zeit haben wir vielleicht 20-30 Geschichten, die Priorität haben. Als ein Beispiel könnten wir 20 perfekt priorisierte Geschichten haben (1 bis 20) und dann eine neue Geschichte erstellen, die unsere neue oberste Priorität sein sollte. Also, ich möchte in der Lage sein, ihm eine Priorität von 1 zu geben, und dann ein serverseitiges Plugin, das die Priorität auf allen anderen Geschichten aktualisiert, so dass ich am Ende mit 1 bis 21 (1 ist die neue Geschichte wir gerade erstellt).

Zu diesem Zweck habe ich ein serverseitiges Plugin für TFS 2010 erstellt, das WorkItemChangedEvent abonniert. Es ist schlau genug, um herauszufinden, ob die Priorität aktualisiert wurde, sodass in diesem Fall nur Arbeitselemente geändert werden. Das Problem ist, dass wenn ich die Priorität ändern und WorkItem.Save() ausführen, löst es erneut WorkItemChangedEvent aus, und die Priorität hat sich geändert, so dass die Logik wahr ist, und es aktualisiert und erneut speichert.

Früher hatte ich ein serverseitiges Plugin erstellt, das die Uhrzeit eines der datetime-Felder auf 00:00:00 änderte (für den Fall, dass es nicht schon 00:00:00 war) und dieses Verhalten bemerkte . Es war kein großes Problem, denn beim zweiten Durchlauf würde nichts passieren, weil die Zeit schon 00:00:00 wäre. Aber in diesem Fall, in dem versucht wird, die Prioritäten für eine ganze Reihe von Workitems zu aktualisieren, ist dies ein Deal-Breaker. Gibt es eine Möglichkeit, WorkItem.Save() davon abzuhalten, ein WorkItemChangedEvent auszulösen? Vielleicht eine andere Möglichkeit, dies alles zusammen zu tun?

Answer 1

Der einfachste Weg, den ich weiß, würde dies lösen, ist einen bestimmten Kommentar hinzufügen und dann zu überprüfen, den Kommentar/history Element des Arbeitselements zu sehen, dass Sie zuletzt als Teil der Änderung, die Sie tun.

Überprüfen Sie auch die folgenden post for pointers on how to create your service so that it remains stable.

Answer 2

Ich habe dieses Problem in meiner eigenen Erweiterung gelöst, indem ich überprüft habe, ob die Wechsler-Identität die Service-Identität ist. Wenn es dann ist, wird die Logik übersprungen.

Dies scheint eine etwas elegantere Lösung als das Markieren der Daten.

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…. 
}