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:
- Tillståndet Stängt finns alltid i kategorin Slutfört tillstånd.
- Kategorin Slutfört tillstånd kan inte konfigureras och är associerad med ett och endast ett tillstånd.
- 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.
- 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.
- 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.
- De här reglerna behövs när en arbetsobjekttyp har anpassade tillstånd, eller om arbetsobjekttypen är en anpassad typ av arbetsobjekt.
- 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å 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
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åde = Affä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
Dölj fält eller gör fältet skrivskyddat eller obligatoriskt baserat på tillstånd och användar- eller gruppmedlemskap
Baserat på och användar- eller gruppmedlemskap anger du fältattribut eller begränsar en tillståndsövergång
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.
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.
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.
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 .
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.
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.
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.
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.
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.
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 ...
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.
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 projektet eller organisationen går du till sidan Behörighetsgrupper> för projektinställningar>eller Behörighetsgrupper> för organisationsinställningar>. Du 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å.
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.
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.
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.
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.
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.
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.
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).
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.
Tillåt att användaren börjar redigera.
Användaren ändrar ett fältvärde och flyttar sedan fokus från fältet.
Bearbeta alla När-regler för fältet som matchar det nya värdet.
Bearbeta eventuella Regler när inte för det fält som matchar det nya värdet.
Bearbeta eventuella regler när det ändrades för det fält som matchar det nya värdet.
Returnera redigeringsförmågan till användaren.
Användaren sparar ändringarna i datalagret.
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.