Regeln und Regelauswetrung

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

Regeln werden verwendet, um Wertzuweisungen auf ein Arbeitselementfeld festzulegen oder einzuschränken. Es gibt zwei Haupttypen von Regeln, automatisch generierten Regeln und benutzerdefinierte Regeln, die für einen Prozess oder ein Projekt definiert sind. Automatisch generierte Regeln minimieren die Notwendigkeit, benutzerdefinierte Regeln für Bereiche hinzuzufügen, die standardmäßig funktionieren sollten.

Sie definieren benutzerdefinierte Regeln, um Ihre Geschäftsverwendungsfälle zu unterstützen. Je nach Datentyp eines Felds können Sie verschiedene Einschränkungen festlegen, welche Daten in dieses Feld eingegeben werden können. Sie können Werte für Auswahllisten angeben (Dropdownmenü), Standardwerte vergeben, Einträge löschen oder Änderungen einschränken. Mit bedingten Regeln können Sie Regeln auf ein Feld anwenden, das auf Abhängigkeiten zwischen den Werten verschiedener Felder basiert. Außerdem können Sie einschränken, wer ein Feld bearbeiten darf oder Regeln nur für bestimmte Gruppen anwenden.

Lesen Sie diesen Artikel, um folgendes zu verstehen:

  • Wie das System automatisch generierte Regeln anwendet
  • Einschränkungen für die Definition benutzerdefinierter Regeln auf Systemfeldern
  • Die verschiedenen Arten von benutzerdefinierten Regeln, die Sie anwenden können
  • So werden Regeln ausgewertet
  • Unterschied zwischen Regeln, die für einen Vererbungsprozess definiert sind, im Vergleich zu einem lokalen XML-Prozess
  • Warum Sie die Anzahl der benutzerdefinierten Regeln minimieren sollten, die Sie definieren

Bevor Sie benutzerdefinierte Regeln definieren, lesen Sie Azure Boards konfigurieren und anpassen, um ein umfassendes Verständnis dafür zu erhalten, wie Sie Azure Boards ihren Geschäftlichen Anforderungen anpassen können.

Tipp

Minimieren Sie die Anzahl der Regeln, die Sie für ein WIT definieren. Während Sie mehrere Regeln für ein WIT erstellen können, können zusätzliche Regeln die Leistung negativ beeinflussen, wenn ein Benutzer Arbeitselemente hinzufügt und ändert. Wenn Benutzer Arbeitselemente speichern, überprüft das System alle Regeln, die den Feldern für den Arbeitselementtyp zugeordnet sind. Unter bestimmten Bedingungen ist der Regelüberprüfungsausdruck zu komplex, damit SQL ausgewertet werden kann.

Automatisch generierte Regeln

Automatisch generierte Regeln minimieren die Notwendigkeit, benutzerdefinierte Regeln für Bereiche hinzuzufügen, die standardmäßig funktionieren sollten.

Statusübergangsregeln

Geerbte Prozesse generieren die gesamte Gruppe von beliebigen Statusübergängen regeln dynamisch für jeden benutzerdefinierten Arbeitselementtyp und den benutzerdefinierten Zustand, der einem Workflow hinzugefügt wurde. Ein Übergang von jedem Zustand zu einem beliebigen Zustand ist gültig.

Für lokale XML-Prozesse müssen Sie die gültigen Übergänge innerhalb WORKFLOW des Abschnitts der Arbeitselementtypdefinition angeben.

Statusübergänge und Nach-/Datum-Feldregeln

Nach/Datumsfelder entsprechen "Erstellt nach/Datum", aktiviert nach/Datum, Aufgelöst nach /Datum und Geschlossen nach/Datum.

Bei geerbten Prozessen werden diese Felder automatisch festgelegt oder gelöscht, wenn Sie ein Arbeitselement von einem Zustand zu einem anderen wechseln. Die Felder "Geändert nach/Datum" sind nicht enthalten, da sie mit jedem Arbeitselementspeicher aktualisiert werden und nicht mit Zustandsübergängen verknüpft sind.

Standardregeln und Verhaltensweisen, die diese Felder steuern, umfassen:

  1. Der Geschlossene Zustand ist immer in der Kategorie "Abgeschlossener Zustand" enthalten.
  2. Die Kategorie "Abgeschlossener Zustand" ist nicht konfigurierbar und ist nur einem Zustand zugeordnet.
  3. Dieser geschlossene Zustand ist immer für Agile- und CMMI-Prozesse geschlossen und immer für Scrum- und Basic-Prozesse erledigt.
  4. Die automatische Generierung dieser Regeln ist durch gebietsschema betroffen, da die Regelbedingung den Statusnamen enthält, der lokalisiert ist. Das System generiert unterschiedliche Regeln für verschiedene Gebietsschemas.
  5. Automatisch generierte Regeln für diese Felder werden nur für Arbeitselementtypen angegeben, die diese Felder enthalten. Es ist möglich, dass ein Arbeitselementtyp keine oder mehrere dieser Felder enthält.
  6. Diese Regeln sind erforderlich, wenn ein Arbeitselementtyp benutzerdefinierte Zustände aufweist, oder der Arbeitselementtyp ein benutzerdefinierter Arbeitselementtyp ist.
  7. Diese Regeln gelten nur für geerbte Prozesse; sie werden nie für die gehosteten XML- oder lokalen XML-Prozesse generiert.

Workflowzustände sind mit Statuskategorien verknüpft, um den Workflow auf Kanban-Boards zu unterstützen. Weitere Informationen finden Sie in Backlogs und Boards, wie Workflowzustände und Statuskategorien verwendet werden.

Statusänderungsfeldregeln

Diese Regeln sind technisch viel einfacher als "Closed By/Closed Date"-Regeln, da sie nicht von einem bestimmten Zustand abhängig sind. Für jeden Arbeitselementtyp funktionieren dieselben Regeln immer. Sie müssen automatisch generiert werden, da einige OOB-Arbeitselementtypen nicht das Feld "Statusänderungsdatum" enthalten. Wenn der Benutzer dieses Feld einem benutzerdefinierten Arbeitselementtyp hinzufügt, müssen diese Regeln auch automatisch generiert werden. Die gleichen Prinzipien für Geschlossenes Datum gelten auch hier.

Benutzerdefinierte Regeln

Alle benutzerdefinierten Regeln sind optional. Für einen geerbten Prozess geben Sie eine Regel an, die aus einer Bedingung plus-Aktion besteht. Für einen lokalen XML-Prozess geben Sie Regeln für ein Feld oder innerhalb des Workflows an.

Es gibt keine 1-1-Zuordnung zwischen den beiden Prozessen. In einigen Fällen wird die XML-Elementregel im Dialogfeld "Feld bearbeiten " für den geerbten Prozess definiert und nicht als Regel. Andere XML-Elemente, zFROZEN. B. , MATCHNOTSAMEASwerden im geerbten Prozess nicht unterstützt.

Beachten Sie Folgendes:

  • Regeln werden immer erzwungen, nicht nur, wenn Sie mit dem Formular interagieren, sondern auch beim Interfacieren durch andere Tools. Das Festlegen eines Felds als schreibgeschützt gilt beispielsweise nicht nur für die Regel im Arbeitselementformular, sondern auch über die API und Excel Azure DevOps Server Add-In.
  • Geerbte Prozesseinträge geben Bedingungen und Aktionen an, um eine vollständige Regel zu erstellen. XML-Elemente machen diese Unterschiede nicht.
  • Feldregeln unterstützen nicht das Zuweisen von Werten, die die Summe von zwei anderen Feldern sind oder andere mathematische Berechnungen ausführen. Sie können jedoch eine Lösung finden, die Ihren Anforderungen über die TFS-Aggregator-Erweiterung (Web Service) Marketplace entspricht. Siehe auch Das Rollup von Arbeit und anderen Feldern.
  • Möglicherweise finden Sie weitere Lösungen zum Anwenden von benutzerdefinierten Regeln auf Felder mithilfe einer Marketplace-Erweiterungen, z. B. die Erweiterung der Bibliothek für Arbeitselemente.

Regelkomposition

Für einen geerbten Prozess besteht jede Regel aus zwei Teilen: Bedingungen und Aktionen. Bedingungen definieren die Umstände, die erfüllt werden müssen, damit die Regel angewendet werden kann. Aktionen definieren die vorgänge, die ausgeführt werden sollen. Für die meisten Regeln können Sie maximal zwei Bedingungen und 10 Aktionen pro Regel angeben. Alle benutzerdefinierten Regeln erfordern alle Bedingungen, die erfüllt werden müssen, um ausgeführt werden zu können.

Als Beispiel können Sie ein Feld basierend auf dem wert, der dem Zustand und einem anderen Feld zugewiesen ist, erforderlich machen. Zum Beispiel:

   (Condition) When a work item State isAktiv
   (Condition) And when the value ofWertbereich = Business
   (Action) Then make requiredStory Points

Hinweis

Derzeit wird nur eine Bedingung für Zustandsübergänge unterstützt. Wenn Sie Regeln basierend auf dem Status anwenden, finden Sie unter Anwenden von Regeln auf Workflowzustände.

In der folgenden Tabelle werden die Aktionen zusammengefasst, die mit den ausgewählten Bedingungen verfügbar sind.

Condition

Unterstützte Aktionen

Festlegen des Feldwerts oder festlegen, erforderlich oder schreibgeschützt

Bedingungen, Arbeitselement wird erstellt

Aktionen, Arbeitselement wird erstellt.

Einschränken eines Übergangs basierend auf dem Zustand

Bedingung, Arbeitselement wird verschoben

Aktionen, beschränken Sie eine Transaktion basierend auf dem Zustand.

Feld ausblenden oder schreibgeschützt oder erforderlich, basierend auf Status und Benutzer oder Gruppenmitgliedschaft

Bedingung, Benutzergruppenmitgliedschaft

Aktionen, beschränken Sie eine Transaktion basierend auf dem Staat und der Mitgliedschaft.

Basierend auf und Benutzer- oder Gruppenmitgliedschaft legen Sie Feldattribute fest oder beschränken sie einen Statusübergang.

Bedingung, Benutzergruppenmitgliedschaft

Aktionen, beschränken Sie eine Transaktion basierend auf dem Staat und der Mitgliedschaft.

Was geschieht, wenn zu viele Regeln definiert sind

Ein einzelner SQL-Ausdruck wird pro Projekt definiert, um Arbeitselemente zu überprüfen, wenn sie erstellt oder aktualisiert werden. Dieser Ausdruck wächst mit der Anzahl der Regeln, die Sie für alle für das Projekt definierten Arbeitselementtypen angeben. Jeder für ein Feld angegebene Verhaltensqualifizierer führt zu einer Erhöhung der Anzahl von Unterausdrücken. Geschachtelte Regeln, Regeln, die nur für einen Übergang oder eine Bedingung für den Wert eines anderen Felds gelten, verursachen mehr Bedingungen, die einer IF Anweisung hinzugefügt werden. Sobald der Ausdruck eine bestimmte Größe oder Komplexität erreicht, kann SQL es nicht mehr auswerten und generiert einen Fehler. Wenn Sie einige WITs entfernen oder einige Regeln beseitigen, kann der Fehler behoben werden.

Sie können Werte für Auswahllisten angeben (Dropdownmenü), Standardwerte vergeben, Einträge löschen oder Änderungen einschränken. Mit bedingten Regeln können Sie Regeln auf ein Feld anwenden, das auf Abhängigkeiten zwischen den Werten verschiedener Felder basiert. Außerdem können Sie einschränken, wer ein Feld bearbeiten darf oder Regeln nur für bestimmte Gruppen anwenden.

Arbeitselementregeln sind nicht als einzelne Auflistung vorhanden. Die Regeln werden tatsächlich dynamisch generiert und aus verschiedenen Datenquellen zusammengeführt. Die Zusammenführungslogik ist eine einfache, konsolidieren identische Regeln, aber kürzen Sie keine widersprüchlichen Regeln.

Umgehen von Regeln

Im Allgemeinen werden alle Arbeitselemente vom Regelmodul überprüft, wenn Benutzer die Arbeitsaufgabe ändern. Um bestimmte Szenarien zu unterstützen, können Benutzer jedoch die Umgehungsregeln für Arbeitsaufgabenaktualisierungen auf Projektebene verwalten, ohne dass Regeln ausgewertet werden.

Regeln können auf eine von zwei Arten umgangen werden. Der erste Vorgang erfolgt über die Arbeitselemente – AKTUALISIEREN DER REST-API und Festlegen des bypassRules Parameters auf true. Die zweite ist über das Clientobjektmodell, indem sie im Umgehungsmodus initialisiert wird (initialisieren WorkItemStore mit WorkItemStoreFlags.BypassRules).

Systemfelder und benutzerdefinierte Regeln

Systemfelder verfügen über System. Namenreferenznamen , z. B. System.Title und System.State.

Die folgenden Systemfelder müssen einen Wert aufweisen: Bereichs-ID, Geändertes Datum, Erstellungsdatum, Erstellt von, Zustand und Grund.

Das Regelmodul beschränkt die Einstellungsbedingungen oder Aktionen auf Systemfelder, außer wie folgt:

  • Sie können Status - und Grundfelder schreibgeschützt erstellen.
  • Sie können die meisten Regeln auf die Felder "Titel", " Zugewiesen an", " Beschreibung" und "Geändert nach" anwenden.

Wenn im Dropdownmenü der Regelbenutzeroberfläche für den Vererbungsprozess kein Feld angezeigt wird, ist dies der Grund. Wenn Sie beispielsweise versuchen, den Bereichspfad (System.AreaPath) schreibgeschützt zu machen, basierend auf einer Bedingung, ist das Feld "Bereichspfad" für die Auswahl nicht verfügbar. Auch wenn Sie ein Systemfeld angeben können, kann das Regelmodul Sie daran hindern, die Regel zu speichern.

Standard- und Kopierregeln

Standard- und Kopierregeln ändern die Werte von Arbeitselementfeldern. Sie definieren Laufzeitverhalten und Einschränkungen, z. B. Angeben von Standardwerten, Löschen von Feldern, Definieren von Feldern und vieles mehr.

Sie können die Anwendung dieser Regeln auf der Grundlage der Gruppenmitgliedschaft des aktuellen Benutzers einschränken, wie in den Einschränkungen der Benutzer- oder Gruppenmitgliedschaftsregel beschrieben.

Die meisten dieser Regelaktionen können mit der Auswahl einer beliebigen Bedingung angewendet werden.

Geerbte Prozessaktion

Beschreibung

Copy the value from...

Gibt ein anderes Feld mit einem Wert an, der in das aktuelle Feld kopiert werden soll.

Clear the value of...

Löscht alle vorhandenen Werte eines Felds.

Use the current time to set the value of ...

Legt die Zeit für ein Feld basierend auf der Zeiteinstellung des aktuellen Benutzers fest.

Einschränkungsregeln

Einschränkungsregeln beschränken das Ändern des Werts eines Felds. Sie definieren die gültigen Zustände für ein Arbeitselement. Jede Einschränkung wird für ein einzelnes Feld ausgeführt. Einschränkungen werden auf dem Server zum Speichern von Arbeitselementen ausgewertet, und wenn eine Einschränkung verletzt wird, wird der Speichervorgang abgelehnt.

Sie können die Anwendung dieser Regeln auf der Grundlage der Gruppenmitgliedschaft des aktuellen Benutzers einschränken, wie in den Einschränkungen der Benutzer- oder Gruppenmitgliedschaftsregel beschrieben.

Die meisten dieser Regelaktionen können mit der Auswahl einer beliebigen Bedingung angewendet werden.

Geerbte Prozessaktion

Beschreibung

Hide the field...
Nur verfügbar, wenn eine Gruppenmitgliedschaftsbedingung ausgewählt ist.

Gibt an, dass das Feld im Arbeitselementformular nicht angezeigt wird, wobei im Wesentlichen die Möglichkeit für den aktuellen Benutzer entfernt wird, den Wert des Felds zu ändern.

Make read-only

Verhindert, dass ein Feld verändert werden kann. Sie möchten diese Regel möglicherweise unter bestimmten Bedingungen anwenden. Beispielsweise möchten Sie möglicherweise, nachdem ein Arbeitselement geschlossen wurde, dafür sorgen, dass ein Feld schreibgeschützt ist, um die Daten für Berichterstellungszwecke beizubehalten.
Um den Standardwert für das Feld anzugeben, ist schreibgeschützt, geben Sie im Dialogfeld "Feld bearbeiten" die Registerkarte "Optionen " an.

Make required

Gibt an, dass Benutzer einen Wert in dieses Feld eingeben müssen. Benutzer können das Arbeitselement erst speichern, nachdem alle Pflichtfelder ausgefüllt wurden.
Wenn Sie die Feldstandardeinstellung angeben möchten, geben Sie im Dialogfeld "Feld bearbeiten" die Registerkarte "Optionen " an.

Listen auswählen

Auswahllisten definieren die Werte, die ein Benutzer für ein Zeichenfolgen- oder Ganzzahlfeld auswählen kann oder nicht. Die Werte einer Auswahlliste werden in einem Arbeitselementformular und im Abfrage-Editor angezeigt.

Für einen geerbten Prozess werden Auswahllisten über das Dialogfeld "Feld bearbeiten" definiert.

Dialogfeld 'Feld bearbeiten'

Beschreibung

Definitionsregisterkarte für ein Auswahllistenfeld

Definiert eine Liste zulässiger Werte für das Feld. Zulässige Werte sind Werte, die in einer Feldliste in Arbeitselementformularen und im Abfrage-Generator zur Auswahl stehen. Sie müssen einen dieser Werte auswählen.

Überprüfen Sie, ob Benutzer ihre eigenen Werte in die Registerkarte "Optionen " eingeben können, damit Benutzer ihre eigenen Einträge angeben können.

Definiert eine Liste mit vorgeschlagenen Werten für das Feld. Vorgeschlagene Werte sind Werte, die in einer Feldliste in Arbeitselementformularen und im Abfrage-Generator zur Auswahl stehen. Neben den Werten in der Liste können Sie zusätzliche Werte eingeben.

Bedingte Feldwerte oder Änderungen

Bedingte Regeln geben eine Aktion basierend auf dem Wert eines Felds an, das einem bestimmten Wert entspricht oder nicht dem Wert eines bestimmten Felds entspricht, oder wenn eine Änderung nicht an den Wert eines bestimmten Felds vorgenommen wurde. Im Allgemeinen werden bedingte Regeln zuerst über bedingungslose Regeln angewendet. Wenn mehrere bedingte Regeln auf "true" ausgewertet werden, lautet die Ausführungsreihenfolge: WhenNot, WhenChanged, WhenNotChanged.

Sie können mehrere bedingte Regeln pro Feld angeben. Sie können jedoch nur ein Steuerfeld pro bedingte Regel angeben.

Geerbte Bedingung

Beschreibung

The value of ... (equals) [Wann]

Legt mindestens eine Regel fest, die auf das aktuelle Feld angewendet wird, wenn ein anderes Feld einen bestimmten Wert enthält.

A change was made to the value of ... [WhenChanged]

Wendet mindestens eine Regel auf das aktuelle Feld an, wenn der Wert eines bestimmten Felds geändert wird.

The value of ... (not equals) [WhenNot]

Wendet mindestens eine Regel auf das aktuelle Feld an, wenn ein anderes Feld nicht einen bestimmten Wert enthält.

No change was made to the value of ... [WhenNotChanged]

Wendet mindestens eine Regel auf das aktuelle Feld an, wenn der Wert eines bestimmten Felds nicht geändert wird.


Geerbte Aktion

Beschreibung

Clear the value of ...
Copy the value from ...
Make read-only ...
Make required ...
Set the value of ...
Use the current time to set the value of ...
Use the current user to set the value of ...

Gibt die Aktion an, die auf einem bestimmten Feld ausgeführt werden soll.

Einschränkungen für Benutzer- oder Gruppenmitgliedschaft

Sie können die Anwendung einer Regel auf der Grundlage der Mitgliedschaft des aktuellen Benutzers einschränken. Es wird empfohlen, die Regel auf eine Azure DevOps-Sicherheitsgruppe und nicht auf einen einzelnen Benutzer zu beschränken, obwohl Sie letztere angeben können. Damit die Regel auf mehrere Gruppen festgelegt ist, müssen Sie eine übergeordnete Azure DevOps-Gruppe erstellen, die den Satz von Gruppen enthält, die Sie verwenden möchten.

Prozessimplementierung

Tipp

Um Regelauswertungsprobleme zu vermeiden, die auftreten können, geben Sie Azure DevOps-Sicherheitsgruppen und nicht Azure Active Directory- oder Active Directory-Sicherheitsgruppen an. Weitere Informationen finden Sie unter "Standardregeln" und "Regelmodul".

Wie in der folgenden Tabelle angegeben, geben Sie zum Einschränken einer Regel basierend auf der Mitgliedschaft des aktuellen Benutzers eine von zwei Bedingungen für einen geerbten Prozess an. Diese Regeln sind für Azure DevOps 2020 und höhere Versionen aktiv.

Zielgruppe

Regel

Bedingung

Current user is a member of group ...
Current user is not member of group ...

Aktion

Hide the field ...
Make read-only ...
Make required ...
Restrict the transition to state ...

Verwenden von Token zum Verweisen auf Benutzer oder Gruppen

Identitäts- oder Personenauswahlfelder können Werte akzeptieren, die sowohl auf Benutzer als auch auf Gruppen verweisen. Wenn Sie eine Regel auf eine Gruppe beschränken, geben Sie die Domäne oder den Bereich der Gruppe an. Für manche Werte können Sie Token verwenden.

Beispiele für Token sind die folgenden:

  • [ProjectName], z. B. [Fabrikam], [FabrikamFiber], [MyProject]
  • [OrganizationName], z. B. [fabrikam], [myorganization]
  • [CollectionName], z. B. [fabrikam], [myorganization]

Wenn Sie mehr über die bereiche erfahren möchten, die für Ihr Projekt oder Ihre Organisation verfügbar sind, wechseln Sie zur Seite "Berechtigungensgruppen für Projekteinstellungen" oder zur Seite "Organisationseinstellungen>>>">, können Sie die Liste nach Bedarf filtern. Die folgende Abbildung zeigt beispielsweise die ersten vier Einträge einer gefilterten Liste basierend auf Azure DevOps. Weitere Informationen finden Sie unter Ändern von Berechtigungen auf Projektebene oder Ändern von Berechtigungen auf Projektsammlungsebene.

Screenshot der Liste gefilterter Berechtigungsgruppen.

Weitere Informationen zu Standardsicherheitsgruppen finden Sie unter Berechtigungen und Gruppen

Regelauswertung

Regeln, die eine Bedingung basierend auf der Benutzer- oder Gruppenmitgliedschaft des Benutzers angeben, der ein Arbeitselement ändert, werden auf zwei Arten ausgewertet. Wenn die Regel ausgewertet wird, muss die Anwendung ermitteln, ob die Regel für den aktuellen Benutzer gilt, indem Sie überprüfen, ob dieser Benutzer mitglied der angegebenen Gruppe ist oder nicht.

  • Wenn Sie das Arbeitselement über das Webportal, die REST-API oder den Azure-Boards-Befehl ändern, wird eine Anforderung an das Azure Active Directory oder Active Directory vorgenommen. Für diesen Vorgang treten keine Probleme auf.
  • Beim Ändern der Arbeitsaufgabe aus Visual Studio, Team Explorer Everywhere, Excel oder einem anderen benutzerdefinierten Tool mithilfe des WIT-Clientobjektmodells basiert die Anforderung zum Auswerten der Mitgliedschaft auf einem Clientcache. Der Clientcache ist nicht über Active Directory-Gruppen informiert.

Hinweis

Visual Studio 2019 Team Explorer für Projekte mit GIT wurde erneut geschrieben, um REST-APIs zu verwenden.

Um Probleme beim Aktualisieren von Arbeitselementen von verschiedenen Clients zu vermeiden, geben Sie Azure DevOps-Sicherheitsgruppen anstelle von Active Directory-Gruppen an. Sie können ganz einfach eine Azure DevOps-Sicherheitsgruppe erstellen, die einer Active Directory-Gruppe entspricht. Informationen dazu finden Sie unter Hinzufügen oder Entfernen von Benutzern oder Gruppen, Verwalten von Sicherheitsgruppen.

Hinweis

Das WIT-Client-OM ist veraltet. Ab dem 1. Januar 2020 wird sie nicht mehr unterstützt, wenn sie an Azure DevOps Services und Azure DevOps Server 2020 arbeitet.

Reihenfolge, in der Regeln ausgewertet werden

Die Regeln werden normalerweise in der Reihenfolge verarbeitet, in der sie aufgelistet sind. Die vollständige Abfolge für die Auswertung aller Regeln ist jedoch nicht vollständig deterministisch.

In diesem Abschnitt werden das erwartete Verhalten und die Interaktionen beschrieben, wenn Sie bedingte, kopieren und Standardregeln anwenden.

Die folgenden Schritte zeigen in der richtigen Reihenfolge die Interaktionen, die Azure DevOps ausführt, und vom Benutzer eines Arbeitselementformulars. Nur die Schritte 1, 8 und 13 werden vom Benutzer ausgeführt.

  1. Von einem Azure DevOps-Client wie dem Webportal, Visual Studio/Team Explorer oder Team Explorer Everywhere erstellt ein Benutzer ein neues Arbeitselement oder bearbeitet ein vorhandenes Arbeitselement.

  2. Standardwerte ausfüllen. Wenden Sie für alle Felder alle Standardwerte an, die dem Feld zugewiesen sind, das nicht Teil einer bedingten Klausel ist.

  3. Kopieren oder Festlegen von Feldwerten Wenden Sie für alle Felder alle Regeln an, um einen Wert zu kopieren oder den Wert eines Felds festzulegen, das nicht Teil einer bedingten Klausel ist.

  4. Wenden Sie für alle Felder mit einer Bedingungsregel, die übereinstimmungt, Regeln zum Festlegen oder Kopieren eines Feldwerts an.

  5. Wenden Sie für alle Felder mit einer Wenn nicht bedingten Regel, die übereinstimmungt, Regeln zum Festlegen oder Kopieren eines Feldwerts an.

    Das System verarbeitet immer Wann Regeln vor "Nicht "-Regeln.

  6. Für alle Felder, die ihre Werte seit Schritt 1 geändert haben und die Regeln enthalten, wenden Sie Regeln an, um einen Feldwert festzulegen oder zu kopieren.

  7. Benutzer darf nun mit der Bearbeitung beginnen.

  8. Benutzer ändert einen Feldwert und das Feld verliert den Fokus.

  9. Verarbeiten Sie alle Regeln für dieses Feld, die dem neuen Wert entsprechen.

  10. Verarbeiten Sie keine Regeln für dieses Feld, das dem neuen Wert entspricht.

  11. Verarbeiten Sie alle Bei geänderten Regeln für dieses Feld, die dem neuen Wert entsprechen.

  12. Benutzer darf das Feld wieder bearbeiten.

  13. Der Benutzer speichert die Änderungen am Datenspeicher.

  14. Wenden Sie für alle Felder alle Use the current time to set the value of ... Aktionen an, die für das Feld entweder direkt oder indirekt unter einer bedingten Regel definiert sind.