Regeln und Regelauswetrung

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Regeln werden verwendet, um Wertzuweisungen auf ein Arbeitselementfeld festzulegen oder einzuschränken. Es gibt zwei Haupttypen von Regeln: automatisch generierte 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 sollen.

Sie definieren benutzerdefinierte Regeln, um Ihre geschäftlichen Anwendungsfälle zu unterstützen. Je nach Datentyp eines Felds können Sie die Eingaben in das Feld auf unterschiedliche Arten einschränken. 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 Abhängigkeiten zwischen den Werten verschiedener Felder als Basis für die möglichen Werte anderer Felder verwenden. 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:

• So wendet das System automatisch generierte Regeln an
• Einschränkungen bei der Definition von benutzerdefinierten Regeln in Systemfeldern
• Die verschiedenen Arten von benutzerdefinierten Regeln, die Sie anwenden können
• Auswertung von Regeln
• Unterschied zwischen Regeln, die für einen Vererbungsprozess definiert sind, im Vergleich zu einem lokalen XML-Prozess
• Warum Sie die Anzahl der von Ihnen definierten benutzerdefinierten Regeln minimieren sollten

Lesen Sie vor dem Definieren von benutzerdefinierten Regeln Azure Boards, um ein umfassendes Verständnis für die Anpassung von Azure Boards an Ihre Geschäftlichen Anforderungen zu erhalten.

Tipp

Minimieren Sie die Anzahl der Regeln, die Sie für ein WIT definieren. Während Sie mehrere Regeln für ein Arbeitselementtyp erstellen können, können sich Additionsregeln negativ auf die Leistung auswirken, wenn Benutzer*innen Arbeitselemente hinzufügen und ändern. Wenn Benutzer*innen 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 für die SQL-Auswertung zu komplex.

Automatisch generierte Regeln

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

Statusübergangsregeln

Geerbte Prozesse generieren den gesamten Satz von Zustandsübergangsregeln dynamisch für jeden benutzerdefinierten Arbeitsaufgabentyp und benutzerdefinierten Zustand, der einem Workflow hinzugefügt wird. Ein Übergang von einem beliebigen Zustand zu einem beliebigen Zustand ist gültig.

Bei lokalen XML-Prozessen müssen Sie die gültigen Übergänge innerhalb des WORKFLOW Abschnitts der Definition des Arbeitsaufgabentyps angeben.

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

Die Felder "Nach/Datum" entsprechen " Erstellt nach/Datum", "Aktiviert nach/Datum", "Aufgelöst nach/Datum" und "Abgeschlossen nach/Datum".

Bei geerbten Prozessen werden diese Felder automatisch festgelegt oder gelöscht, wenn Sie eine Arbeitsaufgabe von einem Zustand in einen anderen übertragen. Die Felder "Geändert nach/Datum" sind nicht enthalten, da sie mit jedem Speichern der Arbeitsaufgabe aktualisiert werden und nicht mit Zustandsübergängen verknüpft sind.

Standardregeln und -verhalten, die diese Felder regeln, umfassen:

1. Der Zustand "Geschlossen" ist immer in der Kategorie "Abgeschlossen" enthalten.
2. Die Kategorie " Abgeschlossener Zustand" ist nicht konfigurierbar und ist mit einem und nur einem Bundesland verknüpft.
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 wird durch das Gebietsschema beeinflusst, da die Regelbedingung den Zustandsnamen enthält, der lokalisiert wird. Das System generiert unterschiedliche Regeln für verschiedene Gebietsschemas.
5. Automatisch generierte Regeln für diese Felder werden nur für Arbeitsaufgabentypen angegeben, die diese Felder enthalten. Es ist möglich, dass ein Arbeitsaufgabentyp mindestens eins dieser Felder enthält.
6. Diese Regeln sind erforderlich, wenn ein Arbeitsaufgabentyp benutzerdefinierte Zustände aufweist oder der Arbeitsaufgabentyp ein benutzerdefinierter Arbeitsaufgabentyp 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 Statuskategorien zugeordnet, um den Workflow auf Kanban-Boards zu unterstützen. Weitere Informationen finden Sie unter How workflow states and state categories are used in Backlogs and Boards.

Feldregeln für Statusänderungsdatum

Diese Regeln sind technisch viel einfacher als Geschlossene-Nach-/Geschlossene-Datum-Regeln, da sie nicht von einem bestimmten Zustand abhängig sind. Für jeden Arbeitsaufgabentyp funktionieren dieselben Regeln immer. Sie müssen automatisch generiert werden, da einige OOB-Arbeitsaufgabentypen nicht das Feld "Statusänderungsdatum" enthalten. Wenn der Benutzer dieses Feld einem benutzerdefinierten Arbeitsaufgabentyp hinzufügt, müssen diese Regeln ebenfalls automatisch generiert werden. Auch hier gelten die gleichen Grundsätze für Regeln für geschlossene Nach-/Schließungsdatum.

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 und nicht als Regel definiert. 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, wenn Sie über andere Tools interfacieren. Wenn Sie beispielsweise ein Feld als schreibgeschützt festlegen, gilt nicht nur die Regel für das Arbeitsaufgabenformular, sondern auch über die API und das Excel Azure DevOps Server-Add-In.
• Geerbte Prozesseinträge geben Bedingungen und Aktionen an, um eine vollständige Regel zu erstellen. XML-Elemente unterscheiden diese Unterschiede nicht.
• Feldregeln unterstützen das Zuweisen von Werten, die die Summe von zwei anderen Feldern sind oder andere mathematische Berechnungen ausführen. Möglicherweise finden Sie jedoch eine Lösung, die Ihren Anforderungen über die TFS-Aggregator-Erweiterung (Web Service) Marketplace entspricht. Siehe auch "Rollup von Arbeit" und anderen Feldern.
• Möglicherweise finden Sie zusätzliche Lösungen zum Anwenden von benutzerdefinierten Regeln auf Felder mithilfe einer Marketplace-Erweiterung, z. B. die Erweiterung " Formularbibliothek für Arbeitselemente".

Regelkomposition

Vererbungsprozess

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 auszuführenden Vorgänge. Für die meisten Regeln können Sie maximal zwei Bedingungen und 10 Aktionen pro Regel angeben. Alle benutzerdefinierten Regeln erfordern, dass alle Bedingungen erfüllt werden, 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 ofValue Area = Business
   (Action) Then make requiredStory-Punkte

Hinweis

Derzeit wird nur eine Bedingung für Zustandsübergangsregeln unterstützt. Wenn Sie Regeln basierend auf "State" anwenden, lesen Sie "Anwenden von Regeln auf Workflowstatus".

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

Condition

Unterstützte Aktionen

Festlegen des Feldwerts oder Festlegen eines erforderlichen oder schreibgeschützten Feldwerts

Einschränken eines Übergangs basierend auf dem Status

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

Lokaler XML-Prozess

Der lokale XML-Prozess definiert Regeln mithilfe von XML-Elementen. Alle diese Regelelemente können innerhalb der FIELD Definition einer Arbeitsaufgabentypdefinition definiert werden. Mit Ausnahme des HELPTEXT Elements können Sie diese Regeln angeben, die sich während eines Workflowübergangs oder als untergeordnete Elemente innerhalb eines FIELD (globalen Workflow)-Elements auswirken sollen.

Hinweis

Das VALIDUSER Element wird für TFS 2018 und höhere Versionen nicht unterstützt.

Wo eine Feldregel angewendet werden soll

Wenn eine Regel auf ein Feld während der gesamten Lebensdauer der Arbeitsaufgabe angewendet werden soll, geben Sie sie innerhalb des FIELD Abschnitts an. Beispielsweise ein Feld, das für einen Fehler erforderlich ist, der neu und aktiv ist Standard s erforderlich, bis der Fehler geschlossen wird. Andernfalls geben Sie sie innerhalb des WORKFLOW Abschnitts an, wenn sie basierend auf einer Änderung im Zustand, Grund oder Übergang angewendet werden soll.

Die Felder "State" (System.State) und "Reason " (System.Reason) werden innerhalb des WORKFLOW Abschnitts definiert. Sie können die meisten Feldregeln angeben, die während einer Änderung des Zustands, der Auswahl eines Grunds oder für einen bestimmten Übergang auf ein Feld angewendet werden sollen. Weitere Informationen finden Sie unter Ändern des Workflows für einen Arbeitsaufgabentyp.

Geben Sie andernfalls eine Regel an, die nur während einer Änderung des Zustands ausgewertet werden soll. Diese Regeln werden innerhalb des WORKFLOW Abschnitts unter den STATE, REASONoder TRANSITION Elementen definiert. Alle Regeln, mit Ausnahme von HELPTEXT, können innerhalb eines FIELD (Workflow)-Elements angewendet werden.

Feldregeln sind additiv. Das heißt, Sie können vier Regelsätze für dasselbe Feld angeben, die alle vom Regelmodul ausgewertet werden.

• Typspezifische Regeln für Arbeitsaufgaben gelten unabhängig vom Speicherort einer Arbeitsaufgabe im Zustandsmodell. Beispielsweise führt eine <REQUIRED \> Regel die folgende Prüfung aus:

  "MyField Value" != NULL

• Statusspezifische Regeln sind auf eine Arbeitselementinstanz festgelegt, wenn sie sich in einem bestimmten Zustand befindet. Eine zustandsspezifische Regel wird erzwungen, wenn die folgende Bedingung erfüllt ist:

  State field value == "MyState" && "MyField Value" != NULL

• Übergangsspezifische Regeln, die Sie für einen bestimmten Übergang angeben, sind auf eine Arbeitsaufgabe ausgerichtet, die einem bestimmten Übergang unterzogen wird. Diese Regeln werden erzwungen, wenn die folgenden Bedingungen erfüllt sind:

  State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState"
&& "MyField Value" != NULL

• Grundspezifische Regeln, die Sie für einen bestimmten Grund angeben, sind auf einen bestimmten Grund für einen bestimmten Übergang ausgerichtet. Sie werden verarbeitet, wenn die folgenden Bedingungen erfüllt sind:

  Reason field == "MyReason" &&
State field value == "ToState" &&
"Previous State Before Edit/New" == "FromState" && "MyField Value" != NULL

Im folgenden Beispiel wird die Änderung des Felds "Kundenschweregrad" eingeschränkt, wenn sich die Arbeitsaufgabe im Status "Aktiv" befindet.

<STATE name="Active">
      <FIELDS>
      <FIELD refname="MyCorp.Severity" >
         <READONLY />
      </FIELD>
      </FIELDS>
</STATE>

Was passiert, wenn zu viele Regeln definiert sind

Ein einzelner SQL-Ausdruck wird pro Projekt definiert, um Arbeitsaufgaben 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 Arbeitsaufgabentypen 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 gelten oder für den Wert eines anderen Felds bedingt sind, führen dazu, dass einer Anweisung weitere Bedingungen hinzugefügt IF werden. Sobald der Ausdruck eine bestimmte Größe oder Komplexität erreicht hat, kann SQL ihn 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 Abhängigkeiten zwischen den Werten verschiedener Felder als Basis für die möglichen Werte anderer Felder verwenden. 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 Logik, konsolidieren identische Regeln, aber kürzen Sie keine widersprüchlichen Regeln.

Umgehen von Regeln

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

Regeln können auf eine von zwei Arten umgangen werden. Der erste Besteht aus der Arbeitsaufgaben - REST-API aktualisieren und den bypassRules Parameter auf truefestlegen. Die zweite besteht aus dem Clientobjektmodell, indem sie im Bypassrules-Modus initialisiert werden (initialisieren WorkItemStore mit WorkItemStoreFlags.BypassRules).

Systemfelder und benutzerdefinierte Regeln

Systemfelder verfügen über System.Name reference names, for example System.Title and System.State.

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

Das Regelmodul schränkt das Festlegen von Bedingungen oder Aktionen auf Systemfelder außer wie folgt ein:

• 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 von" 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) basierend auf einer Bedingung schreibgeschützt zu machen , steht das Feld "Bereichspfad " für die Auswahl nicht zur Verfügung. 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 Arbeitsaufgabenfeldern. Sie definieren Laufzeitverhalten und Einschränkungen, z. B. Angeben von Standardwerten, Löschen von Feldern, Definieren von Feldern und mehr.

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

Vererbungsprozess

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

Geerbte Prozessaktion

Beschreibung

Copy the value from...

Gibt ein weiteres Feld an, das einen Wert enthält, der in das aktuelle Feld kopiert werden soll.

Clear the value of...

Löscht das Feld eines beliebigen darin enthaltenen Werts.

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

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

Lokaler XML-Prozess

Diese Regeln unterstützen das Festlegen von Standardwerten, das Kopieren von Werten aus einem Feld in ein anderes oder das Erzwingen eines Feldwerts, um einem vorgegebenen Muster zu entsprechen. Die Syntaxstruktur und Beispiele finden Sie unter Definieren eines Standardwerts oder Kopieren eines Werts in ein Feld.

XML-Element

Verwendung

COPY

Kopiert einen angegebenen Wert in ein Feld, wenn ein Benutzer eine Arbeitsaufgabe erstellt oder ändert.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
   <COPY from="value" value=" " />  
</FIELD> 

DEFAULT

Gibt einen Wert für ein Feld an, das leer ist, wenn ein Benutzer eine Arbeitsaufgabe erstellt oder ändert. Wenn ein Feld bereits einen Wert aufweist, wird die DEFAULT Regel ignoriert. Standardregeln werden nur ausgeführt, wenn der Is Wert des Felds zurzeit leer ist. Unterstützte Werte umfassen die aktuelle Uhrzeit (from = "clock"), den aktuellen Benutzer (from = "currentuser"), einen Literalwert (from = "value" value = "literal") oder den Wert eines anderen Felds (from = field field = "referenceNameField").

<FIELD refname="MyCorp.Priority" name="Priority" type="String" 
<HELPTEXT>Specify the severity of the problem</HELPTEXT 
   <ALLOWEDVALUES 
      <LISTITEM value="P1"/ 
      <LISTITEM value="P2"/ 
      <LISTITEM value="P3"/ 
   </ALLOWEDVALUES 
<DEFAULT from="value" value="P3"/ 
</FIELD 

SERVERDEFAULT

Gibt die Serveruhr oder den aktuellen Benutzer an, um einen Feldwert zu definieren.

<TRANSITION from="New" to="Active">  
   <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.StartWork" />  
   </ACTIONS>  
   <REASONS>  
      <DEFAULTREASON value="Work started" />  
   </REASONS>  
   <FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
            <COPY from="currentuser" />  
            <VALIDUSER />  
            <REQUIRED />  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
         <SERVERDEFAULT from="clock" />  
      </FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser" />  
      </FIELD>  
   </FIELDS>  
</TRANSITION>  

Einschränkungsregeln

Einschränkungsregeln beschränken das Ändern des Werts eines Felds. Sie definieren die gültigen Zustände für eine Arbeitsaufgabe. Jede Einschränkung wird für ein einzelnes Feld ausgeführt. Einschränkungen werden auf dem Server beim Speichern von Arbeitsaufgaben 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 einschränkungen für Benutzer- oder Gruppenmitgliedschaft beschrieben.

Vererbungsprozess

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 Arbeitsaufgabenformular 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 überhaupt geändert wird. Sie können diese Regel unter bestimmten Bedingungen anwenden. Wenn beispielsweise eine Arbeitsaufgabe geschlossen wurde, möchten Sie ein Feld schreibgeschützt machen, 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

Erfordert, dass ein Benutzer einen Wert für das Feld angibt. Benutzer können eine Arbeitsaufgabe erst speichern, wenn sie allen erforderlichen Feldern Werte zugewiesen haben.
Um den Standardwert des Felds anzugeben, geben Sie im Dialogfeld "Feld bearbeiten" die Registerkarte "Optionen " an.

Lokaler XML-Prozess

XML-Element

Verwendung

ALLOWEDVALUES

Definiert eine Liste zulässiger Werte für das Feld. Zulässige Werte sind Werte, die für die Auswahl in einer Feldliste in Arbeitsaufgabenformularen und im Abfrage-Generator verfügbar sind. Sie müssen aus einem dieser Werte auswählen.

CANNOTLOSEVALUE

Verhindert, dass Benutzer ein Feld eines Werts löschen, nachdem ein Wert angegeben wurde. Dieses Element behält den aktuellen Feldwert bei und kann nicht gelöscht oder leer gemacht werden.

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <CANNOTLOSEVALUE /> 
</FIELD> 

FROZEN

Verhindert, dass Benutzer den Wert eines Felds ändern, sobald es einen Wert enthält. Sobald ein Benutzer die Arbeitsaufgabe mit einem Wert in diesem Feld speichert, kann der Wert nicht mehr geändert werden. Ein fixiertes Feld kann nicht in einen nicht leeren Wert geändert werden, nachdem Änderungen zugesichert wurden. Sie können das Feld jedoch manuell löschen, die Arbeitsaufgabe speichern und dann einen anderen Wert angeben.

<FIELD refname="MyCorp.Priority" name="Management Priority" type="String">  
    <FROZEN not="[Project]\Management Team" /> 
</FIELD> 

EMPTY

Löscht das Feld aller darin enthaltenen Werte und macht das Feld dann schreibgeschützt, wenn ein Benutzer die Arbeitsaufgabe speichert. Sie sollten nicht EMPTY mit READONLY.
EMPTYwird in erster Linie während des Zustandsübergangs verwendet, um Felder zu löschen, die für den Zustand gelten, auf den das Element übergehen soll.

<FIELD refname="MyCorp.SubStatus" />  
   <WHEN field="MyCorp.Status" value="Approve" >  
     <EMPTY />
   </WHEN>  
</FIELD>  

MATCH

Erzwingt die Eingabe eines String-Felds, um einem angegebenen Muster von Zeichen oder Zahlen zu entsprechen. Wenn Sie mehrere MATCH Elemente definieren, wird der Wert als gültig betrachtet, wenn er mit einem der von Ihnen angegebenen Muster übereinstimmt. Wenn mindestens ein Element erfolgreich ist, weist das Feld einen gültigen Wert auf.

<FIELD refname="MyCorp.GitHubURL" name="GitHub URL" type="String">  
   <MATCH pattern="https:\/\/github\.com\/\S+[\.md|\.yml]$"/>  
</FIELD>

NOTSAMEAS

Verhindert, dass einem Feld derselbe Wert zugewiesen wird wie dem, der einem anderen Feld zugewiesen wurde.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <NOTSAMEAS field="MyCorp.SubStatus" /> 
</FIELD> 

PROHIBITEDVALUES

Definiert eine Liste verbotener Werte für das Feld. Wenn mehrere ALLOWEDVALUES und/oder PROHIBITEDVALUES Regeln für ein bestimmtes Feld gelten, ist die vollständige Liste der gültigen Werte die Schnittmenge aller zulässigen Wertelisten – oder alles, wenn keine zulässigen Wertelisten vorhanden sind – minus – d. h. unterschied – die Vereinigung aller Listen zulässiger Werte.

READONLY

Verhindert, dass ein Feld überhaupt geändert wird. Sie können diese Regel unter bestimmten Bedingungen anwenden. Wenn beispielsweise eine Arbeitsaufgabe geschlossen wurde, möchten Sie ein Feld schreibgeschützt machen, um die Daten für Berichterstellungszwecke beizubehalten.
Verwenden Sie nicht READONLY mit dem EMPTY Element, da EMPTY auch ein Feld schreibgeschützt wird. Die Kombination dieser Elemente kann zu inkonsistenten Ergebnissen führen.
Darüber hinaus können Sie ein Feld mithilfe des Control Elementattributes ReadOnly als schreibgeschützt aus dem Arbeitselementformular anzeigen. Das Feld kann von anderen Clients geschrieben werden, aber nicht über das Arbeitsaufgabenformular.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <READONLY />  
</FIELD> 

REQUIRED

Erfordert, dass ein Benutzer einen Wert für das Feld angibt. Benutzer können eine Arbeitsaufgabe erst speichern, wenn sie allen erforderlichen Feldern Werte zugewiesen haben.

<FIELD refname="MyCorp.Status" name="Status" type="String">  
    <REQUIRED />  
</FIELD> 

Auswahllisten

Auswahllisten definieren die Werte, die ein Benutzer für ein Feld "Zeichenfolge" oder "Ganzzahl" auswählen kann oder nicht. In einer Auswahlliste definierte Werte werden in einem Arbeitselementformular und im Abfrage-Editor angezeigt.

Vererbungsprozess

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

Dialogfeld 'Feld bearbeiten'

Beschreibung

Registerkarte "Definition " für ein Auswahllistenfeld

Definiert eine Liste zulässiger Werte für das Feld. Zulässige Werte sind Werte, die für die Auswahl in einer Feldliste in Arbeitsaufgabenformularen und im Abfrage-Generator verfügbar sind. Sie müssen aus einem dieser Werte auswählen.

Aktivieren Sie das Kontrollkästchen "Eigene Werte zulassen" auf der Registerkarte "Optionen ", damit Benutzer ihre eigenen Einträge angeben können.

Definiert eine Liste der vorgeschlagenen Werte für das Feld. Vorgeschlagene Werte sind Werte, die für die Auswahl in einer Feldliste in Arbeitsaufgabenformularen und im Abfrage-Generator verfügbar sind. Sie können weitere Werte zusätzlich zu den Werten in der Liste eingeben.

Lokaler XML-Prozess

Sie definieren Auswahllisten mithilfe von XML-Elementen, die in der folgenden Tabelle aufgeführt sind. Syntaxstruktur und Beispiele finden Sie unter Definieren von Auswahllisten.

Sie können Listen kombinieren und Listen erweitern oder vertragen. Darüber hinaus können Sie die Anwendung dieser Regeln auf der Grundlage der Gruppenmitgliedschaft des aktuellen Benutzers einschränken, wie in Einschränkungen der Benutzer- oder Gruppenmitgliedschaftsregel beschrieben.

XML-Element

Beschreibung

ALLOWEDVALUES

Definiert eine Liste zulässiger Werte für das Feld. Zulässige Werte sind Werte, die für die Auswahl in einer Feldliste in Arbeitsaufgabenformularen und im Abfrage-Generator verfügbar sind. Sie müssen aus einem dieser Werte auswählen.

ALLOWEXISTINGVALUE

Definiert das Feld, um vorhandene Werte zuzulassen. Mit diesem Element können die bereits vorhandenen Feldwerte verwendet werden, auch wenn sie ungültig sind. Alle neuen Feldwerte müssen gültig sein.

PROHIBITEDVALUES

Definiert eine Liste verbotener Werte für das Feld.

SUGGESTEDVALUES

Definiert eine Liste der vorgeschlagenen Werte für das Feld. Vorgeschlagene Werte sind Werte, die für die Auswahl in einer Feldliste in Arbeitsaufgabenformularen und im Abfrage-Generator verfügbar sind. Sie können weitere Werte zusätzlich zu den Werten in der Liste eingeben.

Identitätsfelder und Überprüfungsfehler

Um Validierungsfehler zu vermeiden, die andernfalls auftreten würden, wenn Mitglieder das Team verlassen und nicht mehr als Projekt-Mitwirkender registriert sind, schließen Sie das ALLOWEXISTINGVALUE-Element für das Feld "Zugewiesen an" ein.

<FIELD name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
      <HELPTEXT>The user who is working on this work item</HELPTEXT>
      <ALLOWEXISTINGVALUE />
      <VALIDUSER />
      <ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
      <LISTITEM value="Active" />
      <LISTITEM value="[project]\Contributors" />
      </ALLOWEDVALUES>
      <DEFAULT from="field" field="System.CreatedBy" />
</FIELD>

Bedingte Feldwerte oder Änderungen

Bedingte Regeln geben eine Aktion basierend auf dem Wert eines Felds an, das einem bestimmten Wert entspricht, oder wenn eine Änderung an dem Wert eines bestimmten Felds vorgenommen wurde oder nicht. 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.

Vererbungsprozess

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

Geerbte Bedingung

Beschreibung

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

Gibt eine oder mehrere Regeln an, die auf das aktuelle Feld angewendet werden sollen, wenn ein anderes Feld einen bestimmten Wert aufweist.

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

Wendet eine oder mehrere Regeln auf das aktuelle Feld an, wenn der Wert eines bestimmten Felds geändert wird.

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

Wendet eine oder mehrere Regeln auf das aktuelle Feld an, wenn ein anderes Feld keinen bestimmten Wert aufweist.

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

Wendet eine oder mehrere Regeln 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 für ein bestimmtes Feld ausgeführt werden soll.

Lokaler XML-Prozess

Die folgenden XML-Elemente werden verwendet, um Bedingungen festzulegen, für die andere Regeln ausgewertet werden. Sie können mehrere bedingte Regeln pro Feld angeben. Sie können jedoch nur ein einzelnes Fahrfeld pro bedingte Regel angeben. Sie können bedingte Regeln nicht verschachteln. Zu den unterstützten Aktionen für jedes Prozessmodell gehören die in der folgenden Tabelle aufgeführten Aktionen.

Syntaxstruktur und Beispiele finden Sie unter Zuweisen bedingter Werte und Regeln. Sie können die Anwendung dieser Regeln auf der Grundlage der Gruppenmitgliedschaft des aktuellen Benutzers einschränken, wie in einschränkungen für Benutzer- oder Gruppenmitgliedschaft beschrieben.

XML-Element

Verwendung

WHEN

Gibt eine oder mehrere Regeln an, die auf das aktuelle Feld angewendet werden sollen, wenn ein anderes Feld einen bestimmten Wert aufweist. Das übergeordnete Element definiert das aktuelle Feld.
Wenn das angegebene Feld den angegebenen Wert aufweist, werden die Regeln in diesem Element auf das aktuelle Feld angewendet.

WHENCHANGED

Gibt eine Bedingung an, unter der mindestens eine Regel auf das aktuelle Feld angewendet werden soll. Die Regeln gelten für das aktuelle Feld, wenn der Wert eines anderen Felds in einer Überarbeitung in eine Arbeitsaufgabe geändert wird. Das übergeordnete Element definiert das aktuelle Feld.

WHENNOT

Gibt eine Bedingung an, unter der mindestens eine Regel auf das aktuelle Feld angewendet werden soll. Die Regeln gelten für das aktuelle Feld, wenn sich der Wert eines anderen Felds ändert. Das übergeordnete Element definiert das aktuelle Feld.
Wenn das angegebene Feld nicht den angegebenen Wert enthält, werden die Regeln in diesem Element auf das aktuelle Feld angewendet.

WHENNOTCHANGED

Gibt eine Bedingung an, unter der mindestens eine Regel auf das aktuelle Feld angewendet werden soll. Die Regeln gelten für das aktuelle Feld, wenn der Wert eines anderen Felds nicht in einer Überarbeitung in eine Arbeitsaufgabe geändert wird. Das übergeordnete Element definiert das aktuelle Feld.

Einschränkungen für Benutzer- oder Gruppenmitgliedschaftsregel

Sie können die Anwendung einer Regel basierend auf 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 Probleme mit der Regelauswertung zu vermeiden, die auftreten können, geben Sie Azure DevOps-Sicherheitsgruppen und keine Microsoft Entra-ID oder Active Directory-Sicherheitsgruppen an. Weitere Informationen finden Sie unter "Standardregeln" und "Regelmodul".

Vererbungsprozess

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.

Gilt für

Regel

Erkrankung

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

Lokaler XML-Prozess

Um eine Regel basierend auf der Mitgliedschaft des aktuellen Benutzers einzuschränken, geben Sie entweder die for Attribute not im Regelelement an. Sie geben den Bereich der Regel an. 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.

Szenario

Verwendung

Festlegen eines Felds, das nur für eine angegebene Gruppe erforderlich ist

Wird for verwendet, um eine Regel auf eine Gruppe anzuwenden. In diesem Beispiel muss jeder Benutzer in der Gruppe "Junior Analysts" das Feld "Second Approver" abschließen.

<FIELD name="Second Approver">
<REQUIRED for="Example1\Junior Analysts"/>
</FIELD>

Einschränken der Änderung eines Felds auf eine Gruppe von Benutzern

Wird verwendet not , um eine Gruppe aus einer Regel auszuschließen. In diesem Beispiel wird das Feld "Triage Description" für alle Personen mit Ausnahme der Benutzer in der Gruppe "Triage Committee" als schreibgeschützt definiert.

<FIELD name="Triage Description">
<READONLY not="[Project]\Triage Committee" />
</FIELD>

Festlegen eines Felds, das für einige Benutzer und nicht für andere erforderlich ist

Verwenden Sie eine Kombination aus for und wenden Sie eine Regel gleichzeitig auf einige und not nicht für andere an. In diesem Beispiel wird der Schweregrad als erforderliches Feld für Benutzer in der Gruppe "Projektmitglieder" definiert, aber nicht für die Benutzer in der Gruppe "Projektadministratoren". Wenn sich ein Benutzer in beiden Gruppen befindet, wird die for Anweisung erzwungen, und das Feld wäre erforderlich.

<FIELD name="Severity">
<REQUIRED for="[Project]\Project Members" not="[Global]\Project Admins"/>
</FIELD>

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 dies an Standard oder den Bereich der Gruppe. Für einige Werte können Sie Token verwenden.

Vererbungsprozess

Beispiele für Token sind:

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

Wenn Sie mehr über die für Ihr Projekt oder Ihre Organisation verfügbaren Bereiche erfahren möchten, wechseln Sie zur Seite "Project Einstellungen> Permissions-Gruppen>" oder "Organisation Einstellungen> Permissionsgruppen>", um die Liste nach Bedarf zu 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.

Lokaler XML-Prozess

Beispiele für Token sind:

• [Project], z. B. [Project]\Contributors, [Project]\Fabrikam Team, [Project]\Project Approvers The [Project] token specifies a group defined for a project. Dies kann einem Team, einer Standard- oder benutzerdefinierten Sicherheitsgruppe oder einer Active Directory-Gruppe entsprechen, die dem Projekt hinzugefügt wurde.
• [GLOBAL], um auf eine Sammlungsgruppe zu verweisen, z. B. [GLOBAL]\Project Collection Administrators Use [GLOBAL] to reference a collection-scoped security group, such as the Project Collection Administrators group or a Windows group added to a collection. Beispiel:

  <FIELD name="Title">
      <READONLY for="[GLOBAL]\Project Collection Valid Users"/>
  </FIELD>
  

• [Team Foundation] um auf eine Servergruppe zu verweisen, z. B. [Team Foundation]\Team Foundation-Administratoren verwenden [Team Foundation] zum Verweisen auf eine serverbereichsbezogene Gruppe, z. B. eine integrierte Gruppe oder eine Windows-Gruppe, die Sie einer Gruppe auf Serverebene hinzufügen. Beispiel:

  <FIELD name="Title">
      <READONLY for="[Team Foundation]\Team Foundation Valid Users"/>
  </FIELD>
  

• [Do Standard Name] zum Verweisen auf eine Servergruppe, z. B. [Team Foundation]\Team Foundation Administrators Do Standard-qualified account name, such as the one shown in the following example, can be used to reference a do Standard user or group. Einige Regeln unterstützen nur Gruppen und unterstützen nicht das Verweisen auf do Standard Benutzer.

  <LISTITEM value="FABRIKAM\Christie Church's Direct Reports"/>
  

Hinweis

[Project], [GLOBAL] und [Team Foundation] werden wie folgt verwendet. Sie ersetzen sie nicht durch den Namen des Projekts, der Auflistung oder des Servernamens.

Wenn Sie mehr über die bereiche erfahren möchten, die für Ihr Projekt oder Ihre Sammlung verfügbar sind, wechseln Sie zur Seite "Project Einstellungen> Permissions>Groups" oder "Collection Einstellungen> Permissions>Groups". Filtern Sie die Liste nach Bedarf. 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.

Alle Benutzer und Gruppen müssen von einem dieser Token qualifiziert werden. Der folgende XML-Code ist beispielsweise ungültig, da er die angegebene Gruppe nicht mit einem gültigen Token qualifiziert.

<FIELD name="Title">
    <READONLY for="Dev Team"/>
</FIELD>

Weitere Informationen zu Standardsicherheitsgruppen finden Sie unter "Berechtigungen und Gruppen".

Regelauswertung

Regeln, die eine Bedingung basierend auf der Benutzer- oder Gruppenmitgliedschaft des Benutzers zum Ändern einer Arbeitsaufgabe angeben, werden auf zwei Arten ausgewertet. Wenn die Regel ausgewertet wird, muss die Anwendung ermitteln, ob die Regel für den aktuellen Benutzer gilt, indem überprüft wird, ob dieser Benutzer Mitglied der angegebenen Gruppe ist oder nicht.

• Beim Ändern der Arbeitsaufgabe über das Webportal, die REST-API oder den Azure Boards-Befehl wird eine Anforderung an die Microsoft Entra-ID oder Active Directory gestellt. Für diesen Vorgang treten keine Probleme auf.
• Beim Ändern der Arbeitsaufgabe aus Visual Studio, Excel oder einem anderen benutzerdefinierten Tool mithilfe des WIT-Clientobjektmodells basiert die Anforderung zum Auswerten der Mitgliedschaft auf einem Clientcache. Der Clientcache ist active Directory-Gruppen nicht bekannt.

Hinweis

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

Um Probleme beim Aktualisieren von Arbeitsaufgaben 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 beim Arbeiten mit Azure DevOps Services und Azure DevOps Server 2020 nicht mehr unterstützt.

Reihenfolge, in der Regeln ausgewertet werden

Regeln werden in der Regel in der Reihenfolge verarbeitet, in der sie aufgelistet werden. 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 Regeln, Kopien und Standardregeln anwenden.

Vererbungsprozess

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

1. Aus einem Azure DevOps-Client , z. B. dem Webportal oder dem Visual Studio Team Explorer– erstellt ein Benutzer eine neue Arbeitsaufgabe oder bearbeitet eine vorhandene Arbeitsaufgabe.

2. Standardmäßiges Ausfüllen von Feldern. Wenden Sie für alle Felder alle Standardwerte an, die dem Feld zugewiesen sind, das nicht Teil einer Bedingungsklausel 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 Bedingungsklausel 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 Wann nicht-Regeln .

6. Wenden Sie für alle Felder, die ihre Werte seit Schritt 1 geändert haben und wenn geänderte Regeln enthalten, Regeln zum Festlegen oder Kopieren eines Feldwerts an.

7. Zulassen, dass der Benutzer mit der Bearbeitung beginnt.

8. Der Benutzer ändert einen Feldwert und verschiebt dann den Fokus aus dem Feld.

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

10. Verarbeiten Sie " When Not "-Regeln für dieses Feld, die dem neuen Wert entsprechen.

11. Verarbeiten Sie alle "When Changed"-Regeln für dieses Feld, die dem neuen Wert entsprechen.

12. Gibt die Bearbeitungsmöglichkeit an den Benutzer zurück.

13. Der Benutzer speichert die Änderungen im 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.

Lokaler XML-Prozess

Regeln werden in der Regel in der Reihenfolge verarbeitet, in der sie aufgelistet werden. Wenn Sie jedoch die ELEMENTE WHEN, DEFAULT und COPY verwenden, können zusätzliche Verhaltensweisen angewendet werden. Die folgenden Schritte zeigen in der richtigen Reihenfolge die Interaktionen, die Azure DevOps ausführt, und vom Benutzer eines Arbeitselementformulars. Vom Benutzer werden nur die Schritte 1, 8 und 13 ausgeführt.

1. Aus einem Azure DevOps-Client , z. B. dem Webportal oder dem Visual Studio Team Explorer– erstellt ein Benutzer eine neue Arbeitsaufgabe oder bearbeitet eine vorhandene Arbeitsaufgabe.

2. Standardmäßiges Ausfüllen von Feldern. Wenden Sie für alle Felder alle STANDARDregeln an, die außerhalb oder WENN-Regeln angegeben sind.

3. Kopieren Sie Feldwerte. Verwenden Sie für alle Felder alle COPY-Regeln , die sich außerhalb von WHEN-Klauseln befinden.

4. Führen Sie für alle Felder mit einer WENN-Regel, die übereinstimmt, zuerst DEFAULT und dann COPY-Regeln innerhalb aus.

5. Führen Sie für alle Felder mit einer WENNNOT-Regel, die übereinstimmt, zuerst DEFAULT und dann COPY-Regeln innerhalb aus.

   Das System verarbeitet immer WHEN-Regeln vor WHENNOT-Regeln .

6. Führen Sie für alle Felder, die ihre Werte seit Schritt 1 geändert haben und WENNCHANGED-Regeln enthalten, zuerst DEFAULT- und dann COPY-Regeln ein.

7. Zulassen, dass der Benutzer mit der Bearbeitung beginnt.

8. Der Benutzer ändert einen Feldwert und verschiebt dann den Fokus aus dem Feld.

9. Lösen Sie alle WENN-Regeln für dieses Feld aus, die dem neuen Wert entsprechen.

10. Lösen Sie alle WHENNOT-Regeln für dieses Feld aus, die dem neuen Wert entsprechen.

11. Lösen Sie alle WHENCHANGED-Regeln für dieses Feld aus, die dem neuen Wert entsprechen.

12. Gibt die Bearbeitungsmöglichkeit an den Benutzer zurück.

13. Der Benutzer speichert die Änderungen in der Datenbank.

14. Führen Sie für alle Felder SERVERDEFAULT-Vorgänge aus, die für das Feld entweder direkt oder indirekt unter einer WHEN- oder WHENNOT-Regel definiert sind.

Tastatureingabeeinträge und Regelauswertung

Das System legt jedes Mal einen neuen Wert für ein Feld fest, wenn ein Benutzer einen Tastaturanschlag innerhalb eines Felds über das Arbeitsaufgabenformular eingibt. Dies bedeutet, dass eine bedingte Regel unerwartet auftreten kann, wenn die Voraussetzungen der Regel erfüllt sind.

Im folgenden XML-Beispiel leert das System MyCorp.SubStatus, während Sie "Genehmigt erneut" in das Feld "Status" eingeben, da die WHEN-Regel auftritt, sobald der Benutzer den Buchstaben "e" in "Genehmigt" eingibt, auch wenn der beabsichtigte Endwert nicht "Genehmigen" ist. Denken Sie daher sorgfältig nach, wenn Sie bedingte Regeln verwenden.

<FIELD refname="MyCorp.SubStatus" />
   <WHEN field="MyCorp.Status" value="Approve" >
      <EMPTY />
   </WHEN>
</FIELD>

Verwandte Artikel

• Beispielszenarien für Regeln
• Feldindex des Workitems
• Arbeitselementfelder und -attribute
• Ändern von Berechtigungen auf Projektebene
• Ändern von Berechtigungen auf Projektsammlungsebene
• Berechtigungen und Gruppen
• Geerbter Prozess
  • Hinzufügen einer benutzerdefinierten Regel zu einem Arbeitsaufgabentyp
  • Anwenden von Regeln auf Workflowzustände
• Lokaler XML-Prozess
  • Definieren eines Standardwerts oder Kopieren eines Werts in ein Feld
  • Definieren von Auswahllisten
  • Zuweisen bedingter Werte und Regeln