Regel- och regelutvärdering

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

Regler används för att ange eller begränsa värdetilldelningar till ett arbetsuppgiftsfält. Det finns två huvudsakliga typer av regler: automatiskt genererade regler och anpassade regler som definierats för en process eller ett projekt. Automatiskt genererade regler minimerar behovet av att lägga till anpassade regler för områden som ska fungera på ett standardiserat sätt.

Du definierar anpassade regler för att stödja dina användningsfall. Beroende på ett fälts datatyp kan du ange olika begränsningar för vilka data som kan anges i fältet. Du kan ange värden för en listruta, ange standardvärden, rensa poster eller begränsa ändringar. Med villkorsstyrda regler kan du tillämpa regler för ett fält baserat på beroenden mellan olika fälts värden. Du kan också begränsa vem som ska kunna ändra ett fält eller ändra en regels omfång så att den endast gäller för en viss grupp.

Läs den här artikeln för att förstå följande:

• Så här tillämpar systemet automatiskt genererade regler
• Begränsningar för definition av anpassade regler för systemfält
• De olika typer av anpassade regler som du kan tillämpa
• Hur regler utvärderas
• Skillnad mellan regler som definierats för en arvsprocess jämfört med en lokal XML-process
• Därför bör du minimera antalet anpassade regler som du definierar

Innan du definierar anpassade regler läser du Konfigurera och anpassa Azure Boards för att få en bred förståelse för hur du anpassar Azure Boards efter dina affärsbehov.

Dricks

Minimera antalet regler som du definierar för en WIT. Du kan skapa flera regler för en arbetsuppgiftstyp, men tilläggsregler kan påverka prestanda negativt när en användare lägger till och ändrar arbetsuppgifter. När användarna sparar arbetsuppgifter verifierar systemet alla regler som är associerade med fälten för arbetsuppgiftstypen. Under vissa förhållanden är regelverifieringsuttrycket för komplext för att SQL ska kunna utvärdera det.

Regler som genereras automatiskt

Automatiskt genererade regler minimerar behovet av att lägga till anpassade regler för områden som ska fungera på ett standardiserat sätt.

Regler för tillståndsövergång

Ärvda processer genererar hela uppsättningen alla-till-alla tillståndsövergångsregler dynamiskt för varje anpassad arbetsobjekttyp och anpassat tillstånd som läggs till i ett arbetsflöde. En övergång från ett tillstånd till ett tillstånd är giltig.

För lokala XML-processer måste du ange giltiga övergångar i WORKFLOW avsnittet i definitionen av arbetsobjekttyp.

Tillståndsövergångar och efter/datum-fältregler

Fälten Efter/Datum motsvarar Skapad efter/Datum, Aktiverad av/Datum, Matchad efter/Datum och Stängd efter/Datum.

För ärvda processer anges eller rensas fälten automatiskt när du övergår ett arbetsobjekt från ett tillstånd till ett annat. Fälten Ändrad efter/Datum ingår inte eftersom de uppdateras med varje sparande av arbetsobjekt och inte är relaterade till tillståndsövergångar.

Standardregler och beteenden som styr dessa fält är:

1. Tillståndet Stängt finns alltid i kategorin Slutfört tillstånd.
2. Kategorin Slutfört tillstånd kan inte konfigureras och är associerad med ett och endast ett tillstånd.
3. Det här stängda tillståndet är alltid Stängt för agila processer och CMMI-processer och alltid Klar för Scrum- och Basic-processer.
4. Automatisk generering av dessa regler påverkas av nationella inställningar eftersom regelvillkoret innehåller delstatsnamnet, som är lokaliserat. Systemet genererar olika regler för olika nationella inställningar.
5. Regler som genereras automatiskt för dessa fält anges endast för arbetsobjekttyper som innehåller dessa fält. Det är möjligt att en arbetsobjekttyp inte innehåller ett eller flera av dessa fält.
6. De här reglerna behövs när en arbetsobjekttyp har anpassade tillstånd, eller om arbetsobjekttypen är en anpassad typ av arbetsobjekt.
7. Dessa regler gäller endast för ärvda processer. de genereras aldrig för xml-processer eller lokala XML-processer.

Arbetsflödestillstånd är associerade med tillståndskategorier för att stödja arbetsflödet på Kanban-tavlor. Mer information finns i How workflow states and state categories are used in Backlogs and Boards (Hur arbetsflödestillstånd och tillståndskategorier används i kvarvarande uppgifter och tavlor).

Fältregler för tillståndsändringsdatum

Dessa regler är tekniskt sett mycket enklare än regler för stängt/stängt datum eftersom de inte är beroende av något visst tillstånd. För alla typer av arbetsobjekt fungerar samma regler alltid. De måste genereras automatiskt eftersom vissa typer av OOB-arbetsobjekt inte innehåller fältet Tillståndsändringsdatum, så när användaren lägger till det här fältet i en anpassad arbetsobjekttyp måste även dessa regler genereras automatiskt. Samma principer för regler för stängt/stängt datum gäller även här.

Anpassade regler

Alla anpassade regler är valfria. För en ärvd process anger du en regel som består av ett villkor plus en åtgärd. För en lokal XML-process anger du regler för ett fält eller i arbetsflödet.

Det finns ingen en-till-en-mappning mellan de två processerna. I vissa fall definieras XML-elementregeln i dialogrutan Redigera fält för den ärvda processen och inte som en regel. Andra XML-element, till exempel FROZEN, MATCH, NOTSAMEAS, stöds inte i den ärvda processen.

Notera följande:

• Regler tillämpas alltid, inte bara när du interagerar med formuläret utan även när du interagerar med andra verktyg. Om du till exempel anger ett fält som skrivskyddat gäller inte bara regeln i arbetsobjektsformuläret, utan även via API:et och Excel Azure DevOps Server-tillägget.
• Ärvda processposter anger villkor och åtgärder för att skapa en fullständig regel. XML-element gör inte dessa distinktioner.
• Fältregler stöder inte tilldelning av värden som är summan av två andra fält eller utför andra matematiska beräkningar. Du kan dock hitta en lösning som passar dina behov via MARKETPLACE-tillägget TFS Aggregator (Webbtjänst). Se även Sammanslagning av arbete och andra fält.
• Du kan hitta ytterligare lösningar för att tillämpa anpassade regler på fält med hjälp av ett Marketplace-tillägg, till exempel bibliotekstillägget för formulärkontroll för arbetsobjekt.

Regelsammansättning

Arvsprocess

För en ärvd process består varje regel av två delar: Villkor och åtgärder. Villkor definierar de omständigheter som måste uppfyllas för att regeln ska kunna tillämpas. Åtgärder definierar de åtgärder som ska utföras. För de flesta regler kan du ange högst två villkor och 10 åtgärder per regel. Alla anpassade regler kräver att alla villkor uppfylls för att kunna köras.

Du kan till exempel göra ett fält obligatoriskt baserat på värdet som tilldelats tillståndet och ett annat fält. Till exempel:

   (Condition) When a work item State isAktiv
   (Condition) And when the value ofVärdeområdesaffär =
   (Action) Then make requiredBerättelsepunkter

Kommentar

För närvarande stöds endast ett villkor för regler för tillståndsövergång. Om du tillämpar regler baserat på tillstånd kan du läsa Tillämpa regler på arbetsflödestillstånd.

I följande tabell sammanfattas de åtgärder som är tillgängliga med de valda villkoren.

Condition

Åtgärder som stöds

Ange fältvärde eller gör obligatoriskt eller skrivskyddat

Begränsa en övergång baserat på tillstånd

Baserat på och användar- eller gruppmedlemskap anger du fältattribut eller begränsar en tillståndsövergång

Lokal XML-process

Den lokala XML-processen definierar regler med xml-element. Alla dessa regelelement kan definieras i FIELD definitionen av en definition av arbetsobjekttyp. Och med undantag för elementet HELPTEXT kan du ange vilka regler som ska påverkas under en arbetsflödesövergång eller som underordnade element i ett FIELD (globalt arbetsflöde) element.

Kommentar

Elementet VALIDUSER stöds inte för TFS 2018 och senare versioner.

Var du ska tillämpa en fältregel

När du vill att en regel ska gälla för ett fält under hela arbetsobjektets livslängd anger du den i FIELD avsnittet. Till exempel krävs ett fält som krävs för en bugg som är ny och aktiv tills felet har stängts. Om du vill att det ska tillämpas baserat på en ändring i Tillstånd, Orsak eller övergång anger du det i WORKFLOW avsnittet.

Fälten State (System.State) och Reason (System.Reason) definieras i WORKFLOW avsnittet . Du kan ange de flesta fältregler som ska tillämpas på ett fält under en ändring av tillstånd, val av orsak eller för en specifik övergång. Mer information finns i Ändra arbetsflödet för en typ av arbetsobjekt.

I annat fall anger du en regel som endast ska utvärderas under en tillståndsändring. Dessa regler definieras i avsnittet WORKFLOW under elementen STATE, REASONeller TRANSITION . Alla regler, förutom HELPTEXT, kan tillämpas i ett FIELD (arbetsflöde)-element.

Fältregler är additiva. Det innebär att du kan ange fyra uppsättningar regler för samma fält som alla utvärderas av regelmotorn.

• Typspecifika regler för arbetsobjekt gäller oavsett platsen för ett arbetsobjekt i dess tillståndsmodell. En regel utför till exempel <REQUIRED \> följande kontroll:

  "MyField Value" != NULL

• Tillståndsspecifika regler är begränsade till en arbetsobjektinstans när den är i ett visst tillstånd. En tillståndsspecifik regel tillämpas när följande villkor är sant:

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

• Övergångsspecifika regler som du anger för en specifik övergång är begränsade till ett arbetsobjekt som genomgår en viss övergång. Dessa regler tillämpas när följande villkor är uppfyllda:

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

• Orsaksspecifika regler som du anger av en specifik anledning är begränsade till en viss orsak till en viss övergång. De bearbetas när följande villkor är uppfyllda:

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

I följande exempel begränsas ändringen av kundens allvarlighetsgrad när arbetsobjektet är i aktivt tillstånd.

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

Vad händer om för många regler definieras

Ett enda SQL-uttryck definieras per projekt för att verifiera arbetsobjekt när de skapas eller uppdateras. Det här uttrycket växer med det antal regler som du anger för alla typer av arbetsobjekt som definierats för projektet. Varje beteendekvalificerare som anges för ett fält resulterar i en ökning av antalet underuttryck. Kapslade regler, regler som endast gäller för en övergång eller som är villkorade för värdet för något annat fält, gör att fler villkor läggs till i en IF -instruktion. När uttrycket når en viss storlek eller komplexitet kan SQL inte utvärdera det längre och genererar ett fel. Om du tar bort vissa WIT-nätverk eller eliminerar vissa regler kan du lösa felet.

Du kan ange värden för en listruta, ange standardvärden, rensa poster eller begränsa ändringar. Med villkorsstyrda regler kan du tillämpa regler för ett fält baserat på beroenden mellan olika fälts värden. Du kan också begränsa vem som ska kunna ändra ett fält eller ändra en regels omfång så att den endast gäller för en viss grupp.

Arbetsobjektregler finns inte som en enda samling. Reglerna genereras och sammanfogas dynamiskt från olika datakällor. Sammanslagningslogik är enkel och konsoliderar identiska regler, men trimma inte motstridiga regler.

Kringgå regler

I allmänhet verifieras alla arbetsobjekt av regelmotorn när användarna ändrar arbetsobjektet. Men för att stödja vissa scenarier kan användare som tilldelats behörigheten Kringgå regler för arbetsobjektuppdateringar spara arbetsobjekt utan att regler utvärderas.

Regler kan kringgås på ett av två sätt. Den första är genom Arbetsobjekt – uppdatera REST-API :et och ange parametern bypassRules till true. Den andra är genom klientobjektmodellen genom att initiera i förbikopplingsläge (initiera WorkItemStore med WorkItemStoreFlags.BypassRules).

Systemfält och anpassade regler

Systemfält har System.Namnreferensnamn , till exempel System.Title och System.State.

Följande systemfält måste ha ett värde: Områdes-ID, Ändrat datum, Skapat datum, Skapat av, Tillstånd och Orsak.

Regelmotorn begränsar inställningsvillkor eller åtgärder till systemfält, förutom på följande sätt:

• Du kan göra fälten Tillstånd och Orsak skrivskyddade.
• Du kan tillämpa de flesta regler på fälten Rubrik, Tilldelad till, Beskrivning och Ändrad efter .

Om du inte ser något fält i listrutan i regelanvändargränssnittet för arvsprocessen är det därför. Om du till exempel försöker göra Områdessökväg (System.AreaPath) skrivskyddad baserat på ett villkor är fältet Områdessökväg inte tillgängligt för markering. Även om du kan ange ett systemfält kan regelmotorn hindra dig från att spara regeln.

Standard- och kopieringsregler

Standard- och kopieringsregler ändrar värdena för arbetsobjektfält. De definierar körningsbeteende och begränsningar, till exempel att ange standardvärden, rensa fält, kräva att fält definieras med mera.

Du kan begränsa tillämpningen av dessa regler baserat på den aktuella användarens gruppmedlemskap enligt beskrivningen i Regelbegränsningar för användar- eller gruppmedlemskap.

Arvsprocess

De flesta av dessa regelåtgärder kan tillämpas med val av villkor.

Ärvd processåtgärd

Beskrivning

Copy the value from...

Anger ett annat fält som innehåller ett värde som ska kopieras till det aktuella fältet.

Clear the value of...

Rensar fältet för alla värden som det innehåller.

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

Anger tid för ett fält baserat på den aktuella användarens tidsinställning.

Lokal XML-process

Dessa regler stöder inställning av standardvärden, kopiering av värden från ett fält till ett annat eller framtvingar ett fältvärde för att matcha ett föreskrivet mönster. Syntaxstrukturen och exemplen finns i Definiera ett standardvärde eller kopiera ett värde till ett fält.

XML-element

Användning

COPY

Kopierar ett angivet värde till ett fält när en användare skapar eller ändrar ett arbetsobjekt.

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

DEFAULT

Anger ett värde för ett fält som är tomt när en användare skapar eller ändrar ett arbetsobjekt. Om ett fält redan har ett värde DEFAULT ignoreras regeln. Standardregler körs endast om Is värdet för fältet för närvarande är tomt. Värden som stöds inkluderar aktuell tid (from = "clock"), den aktuella användaren (from = "currentuser"), ett literalvärde (from = "value" value = "literal") eller värdet för ett annat fält (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

Anger serverklockan eller den aktuella användaren för att definiera ett fältvärde.

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

Villkorsregler

Villkorsregler begränsar ändring av värdet för ett fält. De definierar giltiga tillstånd för ett arbetsobjekt. Varje begränsning fungerar på ett enda fält. Begränsningar utvärderas på servern när arbetsobjektet sparas och om någon begränsning överträds avvisas åtgärden spara.

Du kan begränsa tillämpningen av dessa regler baserat på den aktuella användarens gruppmedlemskap enligt beskrivningen i Regelbegränsningar för användar- eller gruppmedlemskap.

Arvsprocess

De flesta av dessa regelåtgärder kan tillämpas med val av villkor.

Ärvd processåtgärd

Beskrivning

Hide the field...
Endast tillgängligt när ett villkor för gruppmedlemskap har valts.

Anger att fältet inte ska visas i arbetsobjektsformuläret, vilket i princip tar bort möjligheten för den aktuella användaren att ändra fältets värde.

Make read-only

Förhindrar att ett fält ändras alls. Du kanske vill tillämpa den här regeln under vissa villkor. När till exempel ett arbetsobjekt har stängts vill du göra ett fält skrivskyddat för att bevara data i rapporteringssyfte.
Om du vill ange att fältets standardvärde är skrivskyddat anger du i dialogrutan Redigera fält, fliken Alternativ .

Make required

Kräver att en användare anger ett värde för fältet. Användarna kan inte spara ett arbetsobjekt förrän de har tilldelat värden till alla obligatoriska fält.
Om du vill ange att fältets standard är obligatoriskt anger du i dialogrutan Redigera fält, fliken Alternativ .

Lokal XML-process

XML-element

Användning

ALLOWEDVALUES

Definierar en lista över tillåtna värden för fältet. Tillåtna värden är värden som är tillgängliga för val i en fältlista i arbetsobjektsformulär och i frågeverktyget. Du måste välja från något av dessa värden.

CANNOTLOSEVALUE

Hindrar användare från att rensa ett fält med ett värde när ett värde har angetts. Det här elementet behåller det aktuella fältvärdet och kan inte rensas eller göras tomt.

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

FROZEN

Hindrar användare från att ändra värdet för ett fält när det innehåller ett värde. Så snart en användare sparar arbetsobjektet med ett värde i fältet kan värdet inte längre ändras. Det går inte att ändra ett låst fält till ett värde som inte är tomt när ändringarna har checkats in. Du kan dock rensa fältet manuellt, spara arbetsobjektet och sedan ange ett annat värde.

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

EMPTY

Rensar fältet för alla värden som det innehåller och gör sedan fältet skrivskyddat när en användare sparar arbetsobjektet. Du bör inte använda EMPTY med READONLY.
EMPTY används främst under tillståndsövergången för att rensa fält som gäller för det tillstånd som objektet övergår till.

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

MATCH

Tvingar poster som gjorts till ett strängfält att överensstämma med ett angivet mönster med tecken eller siffror. Om du definierar flera MATCH element anses värdet vara giltigt om det matchar något av de mönster som du anger. Om minst ett element lyckas har fältet ett giltigt värde.

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

NOTSAMEAS

Förhindrar att ett fält tilldelas samma värde som det som tilldelades till ett annat fält.

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

PROHIBITEDVALUES

Definierar en lista över förbjudna värden för fältet. Om flera ALLOWEDVALUES och/eller PROHIBITEDVALUES regler gäller för ett visst fält är den fullständiga listan över giltiga värden skärningspunkten mellan alla tillåtna värdens listor– eller allt, om det inte finns några tillåtna värdelistor – minus , det vill: ange skillnad – union av alla listor över förbjudna värden.

READONLY

Förhindrar att ett fält ändras alls. Du kanske vill tillämpa den här regeln under vissa villkor. När till exempel ett arbetsobjekt har stängts vill du göra ett fält skrivskyddat för att bevara data i rapporteringssyfte.
Använd inte READONLY med elementet EMPTY eftersom EMPTY även gör ett fält skrivskyddat. Att kombinera dessa element kan ge inkonsekventa resultat.
Dessutom kan du få ett fält att visas som skrivskyddat från arbetsobjektsformuläret med elementattributet ControlReadOnly . Fältet kan skrivas till av andra klienter, men inte via arbetsobjektformuläret.

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

REQUIRED

Kräver att en användare anger ett värde för fältet. Användarna kan inte spara ett arbetsobjekt förrän de har tilldelat värden till alla obligatoriska fält.

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

Välj listor

Välj listor definierar de värden som en användare kan eller inte kan välja för ett sträng- eller heltalsfält. Värden som definierats i en listruta visas i ett arbetsobjektformulär och frågeredigeraren.

Arvsprocess

För en ärvd process definieras listrutor via dialogrutan Redigera fält.

Dialogrutan Redigera fält

Beskrivning

Fliken Definition för ett listfält

Definierar en lista över tillåtna värden för fältet. Tillåtna värden är värden som är tillgängliga för val i en fältlista i arbetsobjektsformulär och i frågeverktyget. Du måste välja från något av dessa värden.

Markera kryssrutan Tillåt användare att ange sina egna värden på fliken Alternativ så att användarna kan ange sina egna poster

Definierar en lista över föreslagna värden för fältet. Föreslagna värden är värden som är tillgängliga för val i en fältlista i arbetsobjektsformulär och i frågeverktyget. Du kan även ange andra värden i listan.

Lokal XML-process

Du definierar plocklistor med hjälp av XML-element som anges i följande tabell. Syntaxstruktur och exempel finns i Definiera plocklistor.

Du kan kombinera listor och expandera eller kontraktlistor. Du kan också begränsa tillämpningen av dessa regler baserat på den aktuella användarens gruppmedlemskap enligt beskrivningen i Regelbegränsningar för användar- eller gruppmedlemskap.

XML-element

Beskrivning

ALLOWEDVALUES

Definierar en lista över tillåtna värden för fältet. Tillåtna värden är värden som är tillgängliga för val i en fältlista i arbetsobjektsformulär och i frågeverktyget. Du måste välja från något av dessa värden.

ALLOWEXISTINGVALUE

Definierar fältet för att tillåta befintliga värden. Med det här elementet kan fältvärdena som redan finns användas, även om de inte är giltiga. Alla nya fältvärden måste vara giltiga.

PROHIBITEDVALUES

Definierar en lista över förbjudna värden för fältet.

SUGGESTEDVALUES

Definierar en lista över föreslagna värden för fältet. Föreslagna värden är värden som är tillgängliga för val i en fältlista i arbetsobjektsformulär och i frågeverktyget. Du kan även ange andra värden i listan.

Identitetsfält och valideringsfel

Om du vill undvika valideringsfel som annars skulle inträffa när medlemmar lämnar teamet och inte längre är registrerade som projektdeltagare tar du med elementet ALLOWEXISTINGVALUE för fältet Tilldelad till .

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

Villkorsstyrda fältvärden eller ändringar

Villkorsregler anger en åtgärd baserat på värdet för ett fält som är lika med eller inte är lika med ett visst värde, eller om en ändring gjordes eller inte gjordes i värdet för ett visst fält. I allmänhet tillämpas villkorliga regler först på villkorslösa regler. När flera villkorsregler utvärderas till true är körningsordningen: When, WhenNot, WhenChanged, WhenNotChanged.

Arvsprocess

Du kan ange flera villkorsregler per fält. Du kan dock bara ange ett enda körfält per villkorsregel.

Ärvt villkor

Beskrivning

The value of ... (equals) [När]

Anger en eller flera regler som ska tillämpas på det aktuella fältet när ett annat fält har ett specifikt värde.

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

Tillämpar en eller flera regler på det aktuella fältet när ett visst fälts värde ändras.

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

Tillämpar en eller flera regler på det aktuella fältet när ett annat fält inte har något specifikt värde.

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

Tillämpar en eller flera regler på det aktuella fältet när ett visst fälts värde inte ändras.

Ärvd åtgärd

Beskrivning

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

Anger vilken åtgärd som ska vidtas för ett visst fält.

Lokal XML-process

Följande XML-element används för att ange villkor för när andra regler utvärderas. Du kan ange flera villkorsregler per fält. Du kan dock bara ange ett enda körfält per villkorsregel. Du kan inte kapsla villkorsregler. Åtgärder som stöds för varje processmodell innehåller de som anges i följande tabell.

Syntaxstruktur och exempel finns i Tilldela villkorsbaserade värden och regler. Du kan begränsa tillämpningen av dessa regler baserat på den aktuella användarens gruppmedlemskap enligt beskrivningen i Regelbegränsningar för användar- eller gruppmedlemskap.

XML-element

Användning

WHEN

Anger en eller flera regler som ska tillämpas på det aktuella fältet när ett annat fält har ett specifikt värde. Det överordnade elementet definierar det aktuella fältet.
När det angivna fältet har det angivna värdet tillämpas reglerna i det här elementet på det aktuella fältet.

WHENCHANGED

Anger ett villkor för att tillämpa en eller flera regler på det aktuella fältet. Reglerna gäller för det aktuella fältet när värdet för ett annat fält ändras i en revision av ett arbetsobjekt. Det överordnade elementet definierar det aktuella fältet.

WHENNOT

Anger ett villkor för att tillämpa en eller flera regler på det aktuella fältet. Reglerna gäller för det aktuella fältet när värdet för ett annat fält ändras. Det överordnade elementet definierar det aktuella fältet.
När det angivna fältet inte innehåller det angivna värdet tillämpas reglerna i det här elementet på det aktuella fältet.

WHENNOTCHANGED

Anger ett villkor för att tillämpa en eller flera regler på det aktuella fältet. Reglerna gäller för det aktuella fältet när värdet för ett annat fält inte ändras i en revision av ett arbetsobjekt. Det överordnade elementet definierar det aktuella fältet.

Begränsningar för användar- eller gruppmedlemskapsregler

Du kan begränsa tillämpningen av en regel baserat på den aktuella användarens medlemskap. Vi rekommenderar att du omfångsbegränsar regeln till en Azure DevOps-säkerhetsgrupp och inte en enda användare, även om du kan ange den senare. Om du vill att regeln ska omfatta flera grupper måste du skapa en överordnad Azure DevOps-grupp som innehåller den uppsättning grupper som du vill använda.

Processimplementering

Dricks

För att undvika problem med regelutvärdering som kan uppstå anger du Azure DevOps-säkerhetsgrupper och inte Microsoft Entra-ID eller Active Directory-säkerhetsgrupper. Mer information finns i Standardregler och regelmotorn.

Arvsprocess

Som du ser i följande tabell anger du ett av två villkor för en ärvd process för att begränsa en regel baserat på den aktuella användarens medlemskap. Dessa regler är aktiva för Azure DevOps 2020 och senare versioner.

Gäller för

Regel

Villkor

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

Åtgärd

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

Lokal XML-process

Om du vill begränsa en regel baserat på den aktuella användarens medlemskap anger du antingen attributen for eller not i regelelementet. Du anger regelns omfång. Om du vill att regeln ska omfatta flera grupper måste du skapa en överordnad Azure DevOps-grupp som innehåller den uppsättning grupper som du vill använda.

Scenario

Användning

Gör ett fält obligatoriskt endast för en angiven grupp

Använd for för att tillämpa en regel på en grupp. Det här exemplet kräver att alla användare i gruppen Junior Analysts slutför fältet Second Approver .

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

Begränsa ändringar av ett fält till en grupp användare

Använd not för att exkludera en grupp från en regel. I det här exemplet definieras fältet Beskrivning av sortering som skrivskyddat för alla utom de användare i gruppen Triage-kommitté.

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

Skapa ett fält som krävs för vissa användare och inte för andra

Använd en kombination av for och not för att samtidigt tillämpa en regel på vissa och inte för andra. I det här exemplet definieras allvarlighetsgrad som ett obligatoriskt fält för användare i gruppen Projektmedlemmar, men inte för dem i gruppen Projektadministratörer. Om en användare finns i båda grupperna tillämpas -instruktionen for och fältet krävs.

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

Använda token för att referera till användare eller grupper

Identitets- eller personväljarefält kan acceptera värden som refererar till både användare och grupper. När du begränsar en regel till en grupp anger du gruppens domän eller omfattning. För vissa värden kan du använda token.

Arvsprocess

Exempel på token är följande:

• [ProjectName], till exempel [Fabrikam], [FabrikamFiber], [MyProject]
• [OrganizationName], till exempel [fabrikam], [myorganization]
• [CollectionName], till exempel [fabrikam], [myorganization]

Om du vill veta mer om de omfång som är tillgängliga för ditt projekt eller din organisation går du till sidan Project Inställningar> Permissions>Groups or Organization Inställningar> Permissions Groups (Grupper för Inställningar Behörigheter>) och kan filtrera listan efter behov. Följande bild visar till exempel de första fyra posterna i en filtrerad lista baserat på Azure DevOps. Mer information finns i Ändra behörigheter på projektnivå eller Ändra behörigheter på projektsamlingsnivå.

Lokal XML-process

Exempel på token är följande:

• [Project], till exempel [Project]\Contributors, [Project]\Fabrikam Team, [Project]\Project Approvers [Project]-token anger en grupp som definierats för ett projekt. Detta kan motsvara ett team, en standard- eller anpassad säkerhetsgrupp eller en Active Directory-grupp som har lagts till i projektet.
• [GLOBAL] för att referera till en samlingsomfångsgrupp, till exempel [GLOBAL]\Projektsamlingsadministratörer använder [GLOBAL] för att referera till en säkerhetsgrupp med samlingsomfång, till exempel gruppen Administratörer för projektsamling eller en Windows-grupp som lagts till i en samling. Till exempel:

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

• [Team Foundation] för att referera till en serveromfattande grupp, till exempel [Team Foundation]\Team Foundation-administratörer använder [Team Foundation] för att referera till en serveromfattande grupp, till exempel en inbyggd grupp eller en Windows-grupp som du lägger till i en servernivågrupp. Till exempel:

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

• [DomainName] för att referera till en serveromfattande grupp, till exempel [Team Foundation]\Team Foundation Administrators Domain-qualified account name, till exempel det som visas i följande exempel, kan användas för att referera till en domänanvändare eller grupp. Vissa regler stöder endast grupper och stöder inte refererande domänanvändare.

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

Kommentar

[Project], [GLOBAL] och [Team Foundation] används som de är. Du ersätter dem inte med namnet på projektet, samlingen eller servernamnet.

Om du vill veta mer om de omfång som är tillgängliga för ditt projekt eller din samling går du till sidan Project Inställningar Permissions Groups or Collection Inställningar Permissions Groups (Grupper för projekt Inställningar> Behörigheter>eller Samling Inställningar> Behörighetsgrupper>). Filtrera listan efter behov. Följande bild visar till exempel de första fyra posterna i en filtrerad lista baserat på Azure DevOps. Mer information finns i Ändra behörigheter på projektnivå eller Ändra behörigheter på projektsamlingsnivå.

Alla användare och grupper måste kvalificeras av någon av dessa token. Följande XML är till exempel inte giltigt eftersom den inte kvalificerar den angivna gruppen med en giltig token.

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

Mer information om standardsäkerhetsgrupper finns i Behörigheter och grupper

Regelutvärdering

Regler som anger ett villkor baserat på användarens eller gruppens medlemskap för användaren som ändrar ett arbetsobjekt utvärderas på något av två sätt. När regeln utvärderas måste programmet avgöra om regeln gäller för den aktuella användaren genom att kontrollera om användaren är eller inte är medlem i den angivna gruppen.

• När du ändrar arbetsobjektet från webbportalen, REST API eller azure boards-kommandot görs en begäran till Microsoft Entra-ID eller Active Directory. Inga problem uppstår för den här åtgärden.
• När du ändrar arbetsobjektet från Visual Studio, Excel eller ett annat anpassat verktyg med hjälp av WIT-klientobjektmodellen baseras begäran om att utvärdera medlemskap på en klientcache. Klientcachen känner inte till Active Directory-grupper.

Kommentar

Visual Studio 2019 Team Explorer för projekt som använder GIT har skrivits om för att använda REST-API:er.

Om du vill undvika problem med användare som uppdaterar arbetsobjekt från olika klienter anger du Azure DevOps-säkerhetsgrupper i stället för Active Directory-grupper. Du kan enkelt skapa en Azure DevOps-säkerhetsgrupp som motsvarar en Active Directory-grupp. Mer information finns i Lägga till eller ta bort användare eller grupper, hantera säkerhetsgrupper.

Kommentar

OM för WIT-klienten är inaktuell. Från och med den 1 januari 2020 stöds den inte längre när du arbetar mot Azure DevOps Services och Azure DevOps Server 2020.

I vilken ordning reglerna utvärderas

Regler bearbetas vanligtvis i den sekvens där de visas. Den fullständiga sekvensen för utvärdering av alla regler är dock inte helt deterministisk.

I det här avsnittet beskrivs det förväntade beteendet och interaktionerna när du tillämpar villkors-, kopierings- och standardregler.

Arvsprocess

Följande steg visar i rätt ordning de interaktioner som Azure DevOps utför och av användaren av ett arbetsobjektformulär. Endast steg 1, 8 och 13 utförs av användaren.

1. Från en Azure DevOps-klient – till exempel webbportalen eller Visual Studio Team Explorer – skapar en användare ett nytt arbetsobjekt eller redigerar ett befintligt arbetsobjekt.

2. Fyll i fältstandarder. För alla fält tillämpar du alla standardvärden som tilldelats fältet som inte ingår i en villkorssats.

3. Kopiera eller ange fältvärden. För alla fält tillämpar du alla regler för att kopiera ett värde eller ange värdet för ett fält som inte ingår i en villkorssats.

4. För alla fält med villkorsregeln När som matchar tillämpar du regler för att ange eller kopiera ett fältvärde.

5. För alla fält med villkorsregeln När inte som matchar tillämpar du regler för att ange eller kopiera ett fältvärde.

   Systemet bearbetar alltid When rules before When Not rules (När inte-regler).

6. För alla fält som har ändrat sina värden sedan steg 1 och som innehåller Regler som ändras , tillämpar du regler för att ange eller kopiera ett fältvärde.

7. Tillåt att användaren börjar redigera.

8. Användaren ändrar ett fältvärde och flyttar sedan fokus från fältet.

9. Bearbeta alla När-regler för fältet som matchar det nya värdet.

10. Bearbeta eventuella Regler när inte för det fält som matchar det nya värdet.

11. Bearbeta eventuella regler när det ändrades för det fält som matchar det nya värdet.

12. Returnera redigeringsförmågan till användaren.

13. Användaren sparar ändringarna i datalagret.

14. För alla fält tillämpar du alla Use the current time to set the value of ... åtgärder som har definierats för fältet antingen direkt eller indirekt under en villkorsregel.

Lokal XML-process

Regler bearbetas vanligtvis i den sekvens där de visas. Men när du använder elementen WHEN, DEFAULT och COPY kan ytterligare beteenden gälla. Följande steg visar i rätt ordning de interaktioner som Azure DevOps utför och av användaren av ett arbetsobjektformulär. Endast steg 1, 8 och 13 utförs av användaren.

1. Från en Azure DevOps-klient – till exempel webbportalen eller Visual Studio Team Explorer – skapar en användare ett nytt arbetsobjekt eller redigerar ett befintligt arbetsobjekt.

2. Fyll i fältstandarder. För alla fält tillämpar du standardreglersom anges utanför eller NÄR-regler.

3. Kopiera fältvärden. För alla fält använder du alla COPY-regler som ligger utanför WHEN-satser .

4. För alla fält med en WHEN-regel som matchar, gör du först STANDARD och sedan KOPIERA regler inuti.

5. För alla fält med en WHENNOT-regel som matchar, gör du först STANDARD och sedan KOPIERA regler inuti.

   Systemet bearbetar alltid WHEN-regler före WHENNOT-regler .

6. För alla fält som har ändrat sina värden sedan steg 1 och som innehåller WHENCHANGED-regler gör du först STANDARD och sedan KOPIERA regler inuti.

7. Tillåt att användaren börjar redigera.

8. Användaren ändrar ett fältvärde och flyttar sedan fokus från fältet.

9. Höj alla WHEN-regler för det fält som matchar det nya värdet.

10. Höj alla WHENNOT-regler för det fält som matchar det nya värdet.

11. Skapa alla WHENCHANGED-regler för det fält som matchar det nya värdet.

12. Returnera redigeringsförmågan till användaren.

13. Användaren sparar ändringarna i databasen.

14. För alla fält utför du SERVERDEFAULT-åtgärder som definieras för fältet antingen direkt eller indirekt under en WHEN - eller EN WHENNOT-regel .

Tangenttryckningsposter och regelutvärdering

Systemet anger ett nytt värde för ett fält varje gång en användare anger ett tangenttryckning i ett fält via arbetsobjektsformuläret. Det innebär att en villkorsregel kan inträffa oväntat när regelns kravvillkor uppfylls.

I följande XML-exempel tömmer systemet MyCorp.SubStatus när du skriver "Godkänd igen" i fältet Status eftersom WHEN-regeln inträffar så snart användaren skriver bokstaven "e" i Godkänd, även om det avsedda slutliga värdet inte är "Godkänn". Därför bör du tänka noga när du använder villkorsstyrda regler.

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

Relaterade artiklar

• Exempel på regelscenarier
• Index för arbetsuppgiftsfält
• Fält och attribut för arbetsobjekt
• Ändra behörigheter på projektnivå
• Ändra behörigheter på projektsamlingsnivå
• Behörigheter och grupper
• Ärvd process
  • Lägga till en anpassad regel i en arbetsobjektstyp
  • Tillämpa regler på arbetsflödestillstånd
• Lokal XML-process
  • Definiera ett standardvärde eller kopiera ett värde till ett fält
  • Definiera listrutor
  • Tilldela villkorsbaserade värden och regler