Evaluatie van regels en regels

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

Regels worden gebruikt om waardetoewijzingen in te stellen of te beperken tot een werkitemveld. Er zijn twee belangrijke soorten regels: automatisch gegenereerde regels en aangepaste regels die zijn gedefinieerd voor een proces of project. Automatisch gegenereerde regels minimaliseren de noodzaak om aangepaste regels toe te voegen voor gebieden die op een standaard manier moeten werken.

U definieert aangepaste regels ter ondersteuning van uw zakelijke gebruiksscenario's. Afhankelijk van het gegevenstype van een veld kunt u verschillende beperkingen instellen voor de gegevens die in dat veld kunnen worden ingevoerd. U kunt waarden opgeven voor een keuzelijst (vervolgkeuzelijst), standaardwaarden instellen, vermeldingen wissen of wijzigingen beperken. Op basis van voorwaardelijke regels kunt u regels toepassen op een veld op basis van afhankelijkheden tussen de waarden van verschillende velden. U kunt ook beperken wie een veld of bereik van een regel kan wijzigen, zodat deze alleen van toepassing is op een groep.

Lees dit artikel voor meer informatie over het volgende:

• Hoe het systeem automatisch gegenereerde regels toepast
• Beperkingen voor de definitie van aangepaste regels voor systeemvelden
• De verschillende typen aangepaste regels die u kunt toepassen
• Hoe regels worden geëvalueerd
• Verschil tussen regels die zijn gedefinieerd voor een overnameproces versus een on-premises XML-proces
• Waarom u het aantal aangepaste regels dat u definieert, moet minimaliseren

Voordat u aangepaste regels definieert, leest u Azure Boards configureren en aanpassen om een breed inzicht te krijgen in het aanpassen van Azure Boards aan uw bedrijfsbehoeften.

Tip

Minimaliseer het aantal regels dat u definieert voor een WIT. Hoewel u meerdere regels voor een WIT kunt maken, kunnen toevoegingsregels een negatieve invloed hebben op de prestaties wanneer een gebruiker werkitems toevoegt en wijzigt. Wanneer gebruikers werkitems opslaan, valideert het systeem alle regels die zijn gekoppeld aan de velden voor het type werkitem. Onder bepaalde omstandigheden is de expressie voor regelvalidatie te complex om door SQL te kunnen worden geëvalueerd.

Automatisch gegenereerde regels

Automatisch gegenereerde regels minimaliseren de noodzaak om aangepaste regels toe te voegen voor gebieden die op een standaard manier moeten werken.

Statusovergangsregels

Overgenomen processen genereren de volledige set any-to-any statusovergangsregels dynamisch voor elk aangepast werkitemtype en de aangepaste status die aan een werkstroom wordt toegevoegd. Een overgang van elke status naar een willekeurige status is geldig.

Voor on-premises XML-processen moet u de geldige overgangen opgeven in de WORKFLOW sectie van de definitie van het type werkitem.

Statusovergangen en op/datum-veldregels

De velden By/Date komen overeen met gemaakt door/datum, geactiveerd op/datum, opgelost op/datum en gesloten op/datum.

Voor overgenomen processen worden deze velden automatisch ingesteld of gewist wanneer u een werkitem van de ene status naar de andere overdrat. De velden Gewijzigd op/Datum worden niet opgenomen omdat ze worden bijgewerkt met elk werkitem dat wordt opgeslagen en die niet zijn gerelateerd aan statusovergangen.

Standaardregels en -gedragingen die deze velden bepalen, zijn onder andere:

1. De status Gesloten is altijd opgenomen in de categorie Voltooide status.
2. De categorie Voltooide status kan niet worden geconfigureerd en is gekoppeld aan één en slechts één status.
3. Deze gesloten status is altijd gesloten voor Agile- en CMMI-processen en altijd gereed voor Scrum- en Basisprocessen.
4. Het automatisch genereren van deze regels wordt beïnvloed door landinstellingen omdat de regelvoorwaarde de naam van de staat bevat, die is gelokaliseerd. Het systeem genereert verschillende regels voor verschillende landinstellingen.
5. Automatisch gegenereerde regels voor deze velden worden alleen opgegeven voor werkitemtypen die deze velden bevatten. Het is mogelijk dat een type werkitem een of meer van deze velden niet bevat.
6. Deze regels zijn nodig wanneer een werkitemtype aangepaste statussen heeft of het type werkitem een aangepast werkitemtype is.
7. Deze regels zijn alleen van toepassing op overgenomen processen; ze worden nooit gegenereerd voor de gehoste XML- of on-premises XML-processen.

Werkstroomstatussen zijn gekoppeld aan statuscategorieën ter ondersteuning van de werkstroom op borden. Zie Hoe werkstroomstatussen en statuscategorieën worden gebruikt in achterstanden en borden voor meer informatie.

Veldregels voor datum van statuswijziging

Deze regels zijn technisch gezien veel eenvoudiger dan regels voor gesloten/gesloten datums, omdat ze niet afhankelijk zijn van een bepaalde status. Voor elk type werkitem werken dezelfde regels altijd. Ze moeten automatisch worden gegenereerd omdat sommige typen OOB-werkitems het veld Datum van statuswijziging niet bevatten, dus wanneer de gebruiker dit veld toevoegt aan een aangepast werkitemtype, moeten deze regels ook automatisch worden gegenereerd. Dezelfde principes voor regels voor gesloten/gesloten datums zijn hier ook van toepassing.

Aangepaste regels

Alle aangepaste regels zijn optioneel. Voor een overgenomen proces geeft u een regel op die bestaat uit een voorwaarde plus actie. Voor een on-premises XML-proces geeft u regels op voor een veld of binnen de werkstroom.

Er is geen een-op-een-toewijzing tussen de twee processen. In sommige gevallen wordt de XML-elementregel gedefinieerd in het dialoogvenster Veld bewerken voor het overgenomen proces en niet als regel. Andere XML-elementen, zoals FROZEN, MATCH, worden NOTSAMEASniet ondersteund in het overgenomen proces.

Let op het volgende:

• Regels worden altijd afgedwongen, niet alleen wanneer u met het formulier werkt, maar ook wanneer u via andere hulpprogramma's communiceert. Als u bijvoorbeeld een veld instelt als alleen-lezen, wordt de regel niet alleen toegepast op het werkitemformulier, maar ook via de API- en Excel Azure DevOps Server-invoegtoepassing.
• Overgenomen procesvermeldingen geven voorwaarden en acties op om een volledige regel te maken. XML-elementen maken deze verschillen niet.
• Veldregels bieden geen ondersteuning voor het toewijzen van waarden die de som zijn van twee andere velden of het uitvoeren van andere wiskundige berekeningen. Mogelijk vindt u echter een oplossing die aansluit bij uw behoeften via de MARKETPLACE-extensie TFS Aggregator (webservice ). Zie ook Samenvouwen van werk en andere velden.
• Mogelijk vindt u aanvullende oplossingen voor het toepassen van aangepaste regels op velden met behulp van een Marketplace-uitbreiding, zoals de bibliotheekextensie formulierbesturingselement voor werkitems.

Regelsamenstelling

Overnameproces

Voor een overgenomen proces bestaat elke regel uit twee onderdelen: Voorwaarden en Acties. Voorwaarden bepalen aan welke omstandigheden moet worden voldaan om de regel toe te passen. Acties definiëren de bewerkingen die moeten worden uitgevoerd. Voor de meeste regels kunt u maximaal twee voorwaarden en 10 acties per regel opgeven. Voor alle aangepaste regels moet aan alle voorwaarden worden voldaan om te kunnen worden uitgevoerd.

U kunt bijvoorbeeld een veld maken dat is vereist op basis van de waarde die is toegewezen aan de status en een ander veld. Voorbeeld:

   (Condition) When a work item State isActief
   (Condition) And when the value ofWaardegebied = Zaak
   (Action) Then make requiredVerhaalpunten

Notitie

Op dit moment wordt slechts één voorwaarde ondersteund voor statusovergangsregels. Zie Regels toepassen op werkstroomstatussen als u regels toepast op basis van Status.

De volgende tabel bevat een overzicht van de acties die beschikbaar zijn met de geselecteerde voorwaarden.

Condition

Ondersteunde acties

Veldwaarde instellen of vereist of alleen-lezen maken

Een overgang beperken op basis van status

Stel op basis van het lidmaatschap van gebruikers of groepen het veldkenmerk in of beperk een statusovergang

On-premises XML-proces

Het on-premises XML-proces definieert regels met behulp van XML-elementen. Al deze regelelementen kunnen worden gedefinieerd binnen de FIELD definitie van een definitie van een type werkitem. En, met uitzondering van het HELPTEXT element, kunt u deze regels opgeven die van invloed moeten worden tijdens een werkstroomovergang of als onderliggende elementen binnen een FIELD (globaal werkstroomelement) element.

Notitie

Het VALIDUSER element wordt niet ondersteund voor TFS 2018 en nieuwere versies.

Waar moet u een veldregel toepassen

Als u een regel wilt toepassen op een veld gedurende de hele levensduur van het werkitem, geeft u deze op in de FIELD sectie. Een veld dat bijvoorbeeld vereist is voor een fout die nieuw en actief is, blijft vereist totdat de fout is gesloten. Als u dit wilt toepassen op basis van een wijziging in status, reden of overgang, geeft u deze op in de WORKFLOW sectie.

De velden Status (System.State) en Reason (System.Reason) worden gedefinieerd in de WORKFLOW sectie. U kunt de meeste veldregels opgeven die moeten worden toegepast op een veld tijdens een wijziging van de status, selectie van een reden of voor een specifieke overgang. Zie De werkstroom voor een werkitemtype wijzigen voor meer informatie.

Anders geeft u een regel op die alleen moet worden geëvalueerd tijdens een wijziging in de status. Deze regels worden gedefinieerd in de WORKFLOW sectie onder de STATE, REASONof TRANSITION elementen. Alle regels, met uitzondering van HELPTEXT, kunnen worden toegepast binnen een FIELD (werkstroom) element.

Veldregels zijn additief. Dat wil gezegd, u kunt vier sets regels opgeven voor hetzelfde veld dat allemaal wordt geëvalueerd door de regelengine.

• Typeregels voor werkitems zijn van toepassing, ongeacht de locatie van een werkitem in het statusmodel. Een regel voert bijvoorbeeld <REQUIRED \> de volgende controle uit:

  "MyField Value" != NULL

• Statusspecifieke regels zijn gericht op een exemplaar van een werkitem wanneer deze zich in een bepaalde status bevindt. Er wordt een statusspecifieke regel afgedwongen wanneer aan de volgende voorwaarde wordt voldaan:

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

• Overgangsspecifieke regels die u opgeeft voor een specifieke overgang, zijn gericht op een werkitem dat een bepaalde overgang ondergaat. Deze regels worden afgedwongen wanneer aan de volgende voorwaarden wordt voldaan:

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

• Redenspecifieke regels die u voor een specifieke reden opgeeft, zijn beperkt tot een bepaalde reden voor een bepaalde overgang. Ze worden verwerkt wanneer aan de volgende voorwaarden wordt voldaan:

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

In het volgende voorbeeld wordt het wijzigen van het ernstveld van de klant beperkt wanneer het werkitem de status Actief heeft.

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

Wat gebeurt er als er te veel regels zijn gedefinieerd

Er wordt per project één SQL-expressie gedefinieerd om werkitems te valideren wanneer ze worden gemaakt of bijgewerkt. Deze expressie groeit met het aantal regels dat u opgeeft voor alle typen werkitems die zijn gedefinieerd voor het project. Elke gedragskwalificatie die is opgegeven voor een veld resulteert in een toename van het aantal subexpressies. Geneste regels, regels die alleen van toepassing zijn op een overgang of voorwaarde voor de waarde van een ander veld, zorgen ervoor dat er meer voorwaarden worden toegevoegd aan een IF instructie. Zodra de expressie een bepaalde grootte of complexiteit heeft bereikt, kan SQL deze niet meer evalueren en wordt er een fout gegenereerd. Als u sommige WIT's verwijdert of bepaalde regels verwijdert, kunt u de fout oplossen.

U kunt waarden opgeven voor een keuzelijst (vervolgkeuzelijst), standaardwaarden instellen, vermeldingen wissen of wijzigingen beperken. Op basis van voorwaardelijke regels kunt u regels toepassen op een veld op basis van afhankelijkheden tussen de waarden van verschillende velden. U kunt ook beperken wie een veld of bereik van een regel kan wijzigen, zodat deze alleen van toepassing is op een groep.

Regels voor werkitems bestaan niet als één verzameling. De regels worden in feite dynamisch gegenereerd en samengevoegd op basis van verschillende gegevensbronnen. De samenvoeglogica is een eenvoudige, identieke regels samenvoegen, maar conflicterende regels niet beperken.

Regels omzeilen

Over het algemeen worden alle werkitems gevalideerd door de regelengine wanneer gebruikers het werkitem wijzigen. Om bepaalde scenario's te ondersteunen, kunnen gebruikers echter de regels omzeilen voor werkitems bijwerken op projectniveau werkitems opslaan zonder dat er regels worden geëvalueerd.

Regels kunnen op twee manieren worden overgeslagen. De eerste is via de Werkitems - REST API bijwerken en de bypassRules parameter instellen op true. De tweede is via het clientobjectmodel door de bypassrules-modus te initialiseren (initialiseer WorkItemStore met WorkItemStoreFlags.BypassRules).

Systeemvelden en aangepaste regels

Systeemvelden hebben Systeem.Naamreferentienamen , bijvoorbeeld System.Title en System.State.

De volgende systeemvelden zijn vereist om een waarde te hebben: Area ID, Changed Date, Created Date, Created By, State en Reason.

De regelengine beperkt het instellen van voorwaarden of acties tot systeemvelden, behalve als volgt:

• U kunt de velden Status en Reden alleen-lezen maken.
• U kunt de meeste regels toepassen op de velden Titel, Toegewezen aan, Beschrijving en Gewijzigd door .

Als er geen veld wordt weergegeven in de vervolgkeuzelijst van de gebruikersinterface van de regel voor het overnameproces, is dit de reden. Als u bijvoorbeeld het gebiedspad (System.AreaPath) alleen-lezen probeert te maken op basis van een voorwaarde, is het veld Gebiedspad niet beschikbaar voor selectie. Zelfs als u een systeemveld kunt opgeven, kan de regelengine het opslaan van de regel beperken.

Standaardregels en regels kopiëren

Standaardregels en regels voor kopiëren wijzigen de waarden van werkitemvelden. Ze definiëren runtimegedrag en beperkingen, zoals het opgeven van standaardwaarden, het wissen van velden, het vereisen van gedefinieerde velden en meer.

U kunt de toepassing van deze regels beperken op basis van het groepslidmaatschap van de huidige gebruiker, zoals beschreven in regels voor gebruikers- of groepslidmaatschappen.

Overnameproces

De meeste van deze regelacties kunnen worden toegepast met de selectie van een voorwaarde.

Overgenomen procesactie

Beschrijving

Copy the value from...

Hiermee geeft u een ander veld op dat een waarde bevat die moet worden gekopieerd naar het huidige veld.

Clear the value of...

Hiermee wist u het veld van een waarde die deze bevat.

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

Hiermee stelt u de tijd voor een veld in op basis van de tijdinstelling van de huidige gebruiker.

On-premises XML-proces

Deze regels ondersteunen standaardinstellingen, het kopiëren van waarden van het ene veld naar het andere of het afdwingen van een veldwaarde om overeen te komen met een voorgeschreven patroon. Zie Een standaardwaarde definiëren of een waarde kopiëren naar een veld voor de syntaxisstructuur en voorbeelden.

XML-element

Gebruik

COPY

Hiermee kopieert u een opgegeven waarde naar een veld wanneer een gebruiker een werkitem maakt of wijzigt.

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

DEFAULT

Hiermee geeft u een waarde op voor een veld dat leeg is wanneer een gebruiker een werkitem maakt of wijzigt. Als een veld al een waarde heeft, wordt de DEFAULT regel genegeerd. Standaardregels worden alleen uitgevoerd als de Is waarde van het veld momenteel leeg is. Ondersteunde waarden zijn de huidige tijd (from = "clock"), de huidige gebruiker (from = "currentuser"), een letterlijke waarde (from = "value" value = "literal") of de waarde van een ander veld (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

Hiermee geeft u de serverklok of de huidige gebruiker om een veldwaarde te definiëren.

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

Regels voor beperkingen

Beperkingsregels beperken het wijzigen van de waarde van een veld. Ze definiëren de geldige statussen voor een werkitem. Elke beperking werkt op één veld. Beperkingen worden geëvalueerd op de server voor het opslaan van werkitems en als een beperking wordt geschonden, wordt de bewerking voor opslaan geweigerd.

U kunt de toepassing van deze regels beperken op basis van het groepslidmaatschap van de huidige gebruiker, zoals beschreven in regels voor gebruikers- of groepslidmaatschappen.

Overnameproces

De meeste van deze regelacties kunnen worden toegepast met de selectie van een voorwaarde.

Overgenomen procesactie

Beschrijving

Hide the field...
Alleen beschikbaar wanneer een groepslidmaatschapsvoorwaarde is geselecteerd.

Hiermee geeft u op dat het veld in het werkitemformulier niet wordt weergegeven, zodat de huidige gebruiker de waarde van het veld kan wijzigen.

Make read-only

Hiermee voorkomt u dat een veld helemaal wordt gewijzigd. U kunt deze regel onder bepaalde voorwaarden toepassen. Nadat een werkitem is gesloten, wilt u bijvoorbeeld een veld alleen-lezen maken om de gegevens te bewaren voor rapportagedoeleinden.
Als u de standaardwaarde voor het veld wilt opgeven, geeft u op in het dialoogvenster Veld bewerken, tabblad Opties .

Make required

Vereist dat een gebruiker een waarde voor het veld opgeeft. Gebruikers kunnen een werkitem pas opslaan als ze waarden hebben toegewezen aan alle vereiste velden.
Als u de standaardwaarde voor het veld wilt opgeven, geeft u op in het dialoogvenster Veld bewerken, tabblad Opties .

On-premises XML-proces

XML-element

Gebruik

ALLOWEDVALUES

Hiermee definieert u een lijst met toegestane waarden voor het veld. Toegestane waarden zijn waarden die beschikbaar zijn voor selectie in een lijst met velden in werkitemformulieren en in de opbouwfunctie voor query's. U moet een van deze waarden selecteren.

CANNOTLOSEVALUE

Hiermee voorkomt u dat gebruikers een veld van een waarde wissen zodra een waarde is opgegeven. Met dit element blijft de huidige veldwaarde behouden en kan deze niet worden gewist of leeg gemaakt.

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

FROZEN

Hiermee voorkomt u dat gebruikers de waarde van een veld wijzigen zodra het een waarde bevat. Zodra een gebruiker het werkitem met een waarde in dat veld opslaat, kan de waarde niet meer worden gewijzigd. Een geblokkeerd veld kan niet worden gewijzigd in een niet-lege waarde nadat wijzigingen zijn doorgevoerd. U kunt het veld echter handmatig wissen, het werkitem opslaan en vervolgens een andere waarde opgeven.

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

EMPTY

Hiermee wist u het veld met een waarde die deze bevat en wordt het veld vervolgens alleen-lezen wanneer een gebruiker het werkitem opslaat. U mag niet gebruiken EMPTY met READONLY.
EMPTY wordt voornamelijk gebruikt tijdens de statusovergang om velden te wissen die van toepassing zijn op de status waarop het item overgaat.

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

MATCH

Dwingt invoer in een tekenreeksveld om te voldoen aan een opgegeven patroon van tekens of getallen. Als u meerdere MATCH elementen definieert, wordt de waarde als geldig beschouwd als deze overeenkomt met een van de patronen die u opgeeft. Als ten minste één element slaagt, heeft het veld een geldige waarde.

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

NOTSAMEAS

Hiermee voorkomt u dat aan een veld dezelfde waarde wordt toegewezen als aan een ander veld.

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

PROHIBITEDVALUES

Hiermee definieert u een lijst met verboden waarden voor het veld. Als meerdere ALLOWEDVALUES en/of PROHIBITEDVALUES regels van toepassing zijn op een bepaald veld, is de volledige lijst met geldige waarden het snijpunt van alle lijsten met toegestane waarden (of alles, als er geen toegestane waardenlijsten zijn, min- dat wil gezegd het verschil instellen) de samenvoeging van alle lijsten met verboden waarden.

READONLY

Hiermee voorkomt u dat een veld helemaal wordt gewijzigd. U kunt deze regel onder bepaalde voorwaarden toepassen. Nadat een werkitem is gesloten, wilt u bijvoorbeeld een veld alleen-lezen maken om de gegevens te bewaren voor rapportagedoeleinden.
Gebruik dit niet READONLY met het EMPTY element omdat EMPTY er ook een veld met het kenmerk Alleen-lezen wordt. Het combineren van deze elementen kan inconsistente resultaten opleveren.
Daarnaast kunt u een veld weergeven als alleen-lezen vanuit het werkitemformulier met behulp van het Control elementkenmerk ReadOnly . Het veld kan door andere clients worden geschreven, maar niet via het werkitemformulier.

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

REQUIRED

Vereist dat een gebruiker een waarde voor het veld opgeeft. Gebruikers kunnen een werkitem pas opslaan als ze waarden hebben toegewezen aan alle vereiste velden.

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

Lijsten kiezen

Kieslijsten definiëren de waarden die een gebruiker wel of niet kan kiezen voor een tekenreeks- of geheel getalveld. Waarden die in een selectielijst zijn gedefinieerd, worden weergegeven in een werkitemformulier en de queryeditor.

Overnameproces

Voor een overgenomen proces worden selectielijsten gedefinieerd via het dialoogvenster Veld bewerken.

Dialoogvenster Veld bewerken

Beschrijving

Tabblad Definitie voor een selectielijstveld

Hiermee definieert u een lijst met toegestane waarden voor het veld. Toegestane waarden zijn waarden die beschikbaar zijn voor selectie in een lijst met velden in werkitemformulieren en in de opbouwfunctie voor query's. U moet een van deze waarden selecteren.

Schakel het selectievakje Toestaan dat gebruikers hun eigen waarden invoeren op het tabblad Opties om gebruikers toe te staan hun eigen vermeldingen op te geven

Hiermee definieert u een lijst met voorgestelde waarden voor het veld. Voorgestelde waarden zijn waarden die beschikbaar zijn voor selectie in een lijst met velden in werkitemformulieren en in de opbouwfunctie voor query's. U kunt ook andere waarden invoeren voor de waarden in de lijst.

On-premises XML-proces

U definieert selectielijsten met XML-elementen die worden vermeld in de volgende tabel. Zie Selectielijsten definiëren voor syntaxisstructuur en voorbeelden.

U kunt lijsten combineren en lijsten uitvouwen of contracten. U kunt de toepassing van deze regels ook beperken op basis van het groepslidmaatschap van de huidige gebruiker, zoals wordt beschreven in regels voor gebruikers- of groepslidmaatschappen.

XML-element

Beschrijving

ALLOWEDVALUES

Hiermee definieert u een lijst met toegestane waarden voor het veld. Toegestane waarden zijn waarden die beschikbaar zijn voor selectie in een lijst met velden in werkitemformulieren en in de opbouwfunctie voor query's. U moet een van deze waarden selecteren.

ALLOWEXISTINGVALUE

Hiermee definieert u het veld om bestaande waarden toe te staan. Met dit element kunnen de veldwaarden die al bestaan, worden gebruikt, zelfs als ze niet geldig zijn. Alle nieuwe veldwaarden moeten geldig zijn.

PROHIBITEDVALUES

Hiermee definieert u een lijst met verboden waarden voor het veld.

SUGGESTEDVALUES

Hiermee definieert u een lijst met voorgestelde waarden voor het veld. Voorgestelde waarden zijn waarden die beschikbaar zijn voor selectie in een lijst met velden in werkitemformulieren en in de opbouwfunctie voor query's. U kunt ook andere waarden invoeren voor de waarden in de lijst.

Identiteitsvelden en validatiefouten

Als u validatiefouten wilt voorkomen die anders optreden wanneer leden het team verlaten en niet meer zijn geregistreerd als projectbijdragers, neemt u het element ALLOWEXISTINGVALUE op voor het veld Toegewezen aan .

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

Waarden of wijzigingen voor voorwaardelijk veld

Met voorwaardelijke regels wordt een actie opgegeven op basis van de waarde van een veld dat gelijk is aan of niet gelijk is aan een specifieke waarde, of als een wijziging wel of niet is aangebracht in de waarde van een specifiek veld. Over het algemeen worden voorwaardelijke regels eerst toegepast op onvoorwaardelijke regels. Wanneer meerdere voorwaardelijke regels waar worden geëvalueerd, is de uitvoeringsvolgorde: Wanneer, WhenNot, WhenChanged, WhenNotChanged.

Overnameproces

U kunt meerdere voorwaardelijke regels per veld opgeven. U kunt echter slechts één rijveld per voorwaardelijke regel opgeven.

Overgenomen voorwaarde

Beschrijving

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

Hiermee geeft u een of meer regels op die moeten worden toegepast op het huidige veld wanneer een ander veld een specifieke waarde heeft.

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

Hiermee past u een of meer regels toe op het huidige veld wanneer de waarde van een specifiek veld wordt gewijzigd.

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

Hiermee past u een of meer regels toe op het huidige veld wanneer een ander veld geen specifieke waarde heeft.

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

Hiermee past u een of meer regels toe op het huidige veld wanneer de waarde van een specifiek veld niet wordt gewijzigd.

Overgenomen actie

Beschrijving

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

Hiermee geeft u de actie op die moet worden uitgevoerd voor een specifiek veld.

On-premises XML-proces

De volgende XML-elementen worden gebruikt om voorwaarden in te stellen voor wanneer andere regels worden geëvalueerd. U kunt meerdere voorwaardelijke regels per veld opgeven. U kunt echter slechts één rijveld per voorwaardelijke regel opgeven. U kunt geen voorwaardelijke regels nesten. Ondersteunde acties voor elk procesmodel bevatten acties die worden vermeld in de volgende tabel.

Zie Waarden en regels op basis van voorwaardelijke waarden en regels toewijzen voor syntaxisstructuur en voorbeelden. U kunt de toepassing van deze regels beperken op basis van het groepslidmaatschap van de huidige gebruiker, zoals beschreven in regels voor gebruikers- of groepslidmaatschappen.

XML-element

Gebruik

WHEN

Hiermee geeft u een of meer regels op die moeten worden toegepast op het huidige veld wanneer een ander veld een specifieke waarde heeft. Het bovenliggende element definieert het huidige veld.
Wanneer het opgegeven veld de opgegeven waarde heeft, worden de regels in dit element toegepast op het huidige veld.

WHENCHANGED

Hiermee geeft u een voorwaarde op waaronder een of meer regels op het huidige veld moeten worden toegepast. De regels zijn van toepassing op het huidige veld wanneer de waarde van een ander veld wordt gewijzigd in een revisie in een werkitem. Het bovenliggende element definieert het huidige veld.

WHENNOT

Hiermee geeft u een voorwaarde op waaronder een of meer regels op het huidige veld moeten worden toegepast. De regels zijn van toepassing op het huidige veld wanneer de waarde van een ander veld wordt gewijzigd. Het bovenliggende element definieert het huidige veld.
Wanneer het opgegeven veld niet de opgegeven waarde bevat, worden de regels in dit element toegepast op het huidige veld.

WHENNOTCHANGED

Hiermee geeft u een voorwaarde op waaronder een of meer regels op het huidige veld moeten worden toegepast. De regels zijn van toepassing op het huidige veld wanneer de waarde van een ander veld niet wordt gewijzigd in een revisie van een werkitem. Het bovenliggende element definieert het huidige veld.

Beperkingen voor regels voor gebruikers- of groepslidmaatschappen

U kunt de toepassing van een regel beperken op basis van het lidmaatschap van de huidige gebruiker. U wordt aangeraden de regel te bepalen voor een Azure DevOps-beveiligingsgroep en niet voor één gebruiker, maar u kunt deze laatste opgeven. Als u de regel wilt toepassen op meerdere groepen, moet u een bovenliggende Azure DevOps-groep maken die de set groepen bevat die u wilt gebruiken.

Proces-implementatie

Tip

Als u problemen met regelevaluatie wilt voorkomen die zich kunnen voordoen, geeft u Azure DevOps-beveiligingsgroepen op en niet microsoft Entra-id of Active Directory-beveiligingsgroepen. Zie Standaardregels en de regelengine voor meer informatie.

Overnameproces

Zoals aangegeven in de volgende tabel, om een regel te beperken op basis van het lidmaatschap van de huidige gebruiker, geeft u een van de twee voorwaarden op voor een overgenomen proces. Deze regels zijn actief voor Azure DevOps 2020 en latere versies.

Is van toepassing op

Regel

Conditie

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

Actie

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

On-premises XML-proces

Als u een regel wilt beperken op basis van het lidmaatschap van de huidige gebruiker, geeft u de for of not kenmerken in het regelelement op. U geeft het bereik van de regel op. Als u de regel wilt toepassen op meerdere groepen, moet u een bovenliggende Azure DevOps-groep maken die de set groepen bevat die u wilt gebruiken.

Scenario

Gebruik

Een veld alleen vereist maken voor een opgegeven groep

Gebruik for dit om een regel toe te passen op een groep. Voor dit voorbeeld moet elke gebruiker in de groep Junior Analysts het veld Second Approver voltooien.

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

Het wijzigen van een veld beperken tot een groep gebruikers

Gebruik not dit om een groep uit te sluiten van een regel. In dit voorbeeld wordt het veld Beschrijving van triage gedefinieerd als alleen-lezen voor iedereen behalve die gebruikers in de groep Triage-comité.

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

Een veld maken dat vereist is voor sommige gebruikers en niet voor anderen

Gebruik een combinatie van for en not om tegelijkertijd een regel toe te passen op sommige en niet op andere. In dit voorbeeld wordt ernst gedefinieerd als een vereist veld voor gebruikers in de groep Projectleden, maar niet voor gebruikers in de groep Projectbeheerders. Als een gebruiker zich in beide groepen bevindt, wordt de for instructie afgedwongen en is het veld vereist.

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

Tokens gebruiken om te verwijzen naar gebruikers of groepen

Identiteits- of personenkiezervelden kunnen waarden accepteren die verwijzen naar zowel gebruikers als groepen. Wanneer u een regel beperkt tot een groep, geeft u het domein of bereik van de groep aan. Voor sommige waarden kunt u tokens gebruiken.

Overnameproces

Voorbeelden van tokens zijn onder andere:

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

Als u meer wilt weten over de bereiken die beschikbaar zijn voor uw project of organisatie, gaat u naar de pagina Machtigingengroepen voor projectinstellingen>>of organisatie-instellingen>.> U kunt de lijst zo nodig filteren. In de volgende afbeelding ziet u bijvoorbeeld de eerste vier vermeldingen in een gefilterde lijst op basis van Azure DevOps. Zie Machtigingen op projectniveau wijzigen of Machtigingen op projectverzamelingsniveau wijzigen voor meer informatie.

On-premises XML-proces

Voorbeelden van tokens zijn onder andere:

• [Project], zoals [Project]\Inzenders, [Project]\Fabrikam Team, [Project]\Project Goedkeurders Het token [Project] geeft een groep op die is gedefinieerd voor een project. Dit kan overeenkomen met een team, een standaardbeveiligingsgroep of aangepaste beveiligingsgroep of een Active Directory-groep die aan het project is toegevoegd.
• [GLOBAL], als u wilt verwijzen naar een groep met verzamelingsbereik, bijvoorbeeld [GLOBAL]\Beheerders van projectverzamelingen [GLOBAL] gebruiken om te verwijzen naar een beveiligingsgroep met een verzamelingsbereik, zoals de groep Projectverzamelingsbeheerders of een Windows-groep die is toegevoegd aan een verzameling. Bijvoorbeeld:

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

• [Team Foundation] om te verwijzen naar een groep met serverbereik, bijvoorbeeld [Team Foundation]\Team Foundation-beheerders gebruiken [Team Foundation] om te verwijzen naar een groep met serverbereik, zoals een ingebouwde groep of een Windows-groep die u toevoegt aan een groep op serverniveau. Bijvoorbeeld:

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

• [DomainName] om te verwijzen naar een groep met serverbereik, bijvoorbeeld [Team Foundation]\Team Foundation Administrators Domain Qualified Account Name, zoals de naam die in het volgende voorbeeld wordt weergegeven, kan worden gebruikt om te verwijzen naar een domeingebruiker of groep. Sommige regels ondersteunen alleen groepen en bieden geen ondersteuning voor het verwijzen naar domeingebruikers.

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

Notitie

[Project], [GLOBAL] en [Team Foundation] worden als zodanig gebruikt. U vervangt ze niet door de naam van het project, de verzameling of de servernaam.

Als u meer wilt weten over de bereiken die beschikbaar zijn voor uw project of verzameling, gaat u naar de pagina Machtigingengroepen voor Projectinstellingen>>of Verzamelingsinstellingen>machtigingengroepen>. Filter de lijst zo nodig. In de volgende afbeelding ziet u bijvoorbeeld de eerste vier vermeldingen in een gefilterde lijst op basis van Azure DevOps. Zie Machtigingen op projectniveau wijzigen of Machtigingen op projectverzamelingsniveau wijzigen voor meer informatie.

Alle gebruikers en groepen moeten worden gekwalificeerd door een van deze tokens. De volgende XML is bijvoorbeeld ongeldig omdat de opgegeven groep niet in aanmerking komt met een geldig token.

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

Zie Machtigingen en groepen voor meer informatie over standaardbeveiligingsgroepen

Evaluatie van regels

Regels die een voorwaarde opgeven op basis van het gebruikers- of groepslidmaatschap van de gebruiker die een werkitem wijzigt, worden op twee manieren geëvalueerd. Wanneer de regel wordt geëvalueerd, moet de toepassing bepalen of de regel van toepassing is op de huidige gebruiker door te controleren of die gebruiker wel of geen lid is van de opgegeven groep.

• Wanneer u het werkitem wijzigt vanuit de webportal, REST API of Azure Boards-opdracht , wordt er een aanvraag naar de Microsoft Entra-id of Active Directory gedaan. Er treden geen problemen op voor deze bewerking.
• Wanneer u het werkitem wijzigt vanuit Visual Studio, Excel of een ander aangepast hulpprogramma met behulp van het WIT Client Object Model, is de aanvraag voor het evalueren van lidmaatschap gebaseerd op een clientcache. De clientcache is niet op de hoogte van Active Directory-groepen.

Notitie

Visual Studio 2019 Team Explorer voor projecten die GIT gebruiken, is opnieuw geschreven om REST API's te gebruiken.

Als u problemen wilt voorkomen met gebruikers die werkitems van verschillende clients bijwerken, geeft u Azure DevOps-beveiligingsgroepen op in plaats van Active Directory-groepen. U kunt eenvoudig een Azure DevOps-beveiligingsgroep maken die overeenkomt met een Active Directory-groep. Zie Gebruikers of groepen toevoegen of verwijderen, beveiligingsgroepen beheren voor meer informatie.

Notitie

De WIT Client OM is afgeschaft. Vanaf 1 januari 2020 wordt deze niet meer ondersteund bij het werken met Azure DevOps Services en Azure DevOps Server 2020.

Volgorde waarin regels worden geëvalueerd

Regels worden doorgaans verwerkt in de volgorde waarin ze worden vermeld. De volledige volgorde voor de evaluatie van alle regels is echter niet volledig deterministisch.

In deze sectie worden het verwachte gedrag en de interacties beschreven wanneer u voorwaardelijke, kopieer- en standaardregels toepast.

Overnameproces

De volgende stappen tonen, in de juiste volgorde, de interacties die Azure DevOps uitvoert en door de gebruiker van een werkitemformulier. Alleen stap 1, 8 en 13 worden door de gebruiker uitgevoerd.

1. Vanuit een Azure DevOps-client, zoals de webportal of Visual Studio Team Explorer, maakt een gebruiker een nieuw werkitem of bewerkt een bestaand werkitem.

2. Vul de standaardinstellingen voor velden in. Pas voor alle velden alle standaardwaarden toe die zijn toegewezen aan het veld dat geen deel uitmaakt van een voorwaardelijke component.

3. Veldwaarden kopiëren of instellen. Pas voor alle velden regels toe om een waarde te kopiëren of stel de waarde in van een veld dat geen deel uitmaakt van een voorwaardelijke component.

4. Voor alle velden met een voorwaardelijke regel die overeenkomt, past u regels toe om een veldwaarde in te stellen of te kopiëren.

5. Pas regels toe om een veldwaarde in te stellen of te kopiëren voor alle velden met een niet-voorwaardelijke regel die overeenkomt.

   Het systeem verwerkt altijd Wanneer regels vóór Wanneer geen regels.

6. Voor alle velden waarop de waarden zijn gewijzigd sinds stap 1 en die regels bevatten wanneer de regels zijn gewijzigd , past u regels toe om een veldwaarde in te stellen of te kopiëren.

7. Hiermee staat u de gebruiker toe om te beginnen met bewerken.

8. De gebruiker wijzigt een veldwaarde en verplaatst vervolgens de focus van het veld.

9. Alle Wanneer-regels voor dat veld verwerken die overeenkomen met de nieuwe waarde.

10. Verwerkt alle wanneer niet-regels voor dat veld die overeenkomen met de nieuwe waarde.

11. Verwerken wanneer er regels zijn gewijzigd voor dat veld die overeenkomen met de nieuwe waarde.

12. Retourneer de mogelijkheid om de gebruiker te bewerken.

13. De gebruiker slaat de wijzigingen in het gegevensarchief op.

14. Pas voor alle velden acties Use the current time to set the value of ... toe die direct of indirect onder een voorwaardelijke regel zijn gedefinieerd voor het veld.

On-premises XML-proces

Regels worden doorgaans verwerkt in de volgorde waarin ze worden vermeld. Wanneer u echter de elementen WHEN, DEFAULT en COPY gebruikt, kunnen aanvullende gedragingen van toepassing zijn. De volgende stappen tonen, in de juiste volgorde, de interacties die Azure DevOps uitvoert en door de gebruiker van een werkitemformulier. Alleen stap 1, 8 en 13 worden door de gebruiker uitgevoerd.

1. Vanuit een Azure DevOps-client, zoals de webportal of Visual Studio Team Explorer, maakt een gebruiker een nieuw werkitem of bewerkt een bestaand werkitem.

2. Vul de standaardinstellingen voor velden in. Pas voor alle velden alle STANDAARDregels toe die buiten of WANNEER-regels zijn opgegeven.

3. Veldwaarden kopiëren. Gebruik voor alle velden copy-regels die zich buiten WHEN-componenten bevinden.

4. Voor alle velden met een WHEN-regel die overeenkomt, voert u eerst DEFAULT en vervolgens COPY-regels in.

5. Voor alle velden met een WHENNOT-regel die overeenkomt, voert u eerst DEFAULT en vervolgens COPY-regels in.

   Het systeem verwerkt altijd WHEN-regels vóór WHENNOT-regels .

6. Voer voor alle velden die hun waarden hebben gewijzigd sinds stap 1 en die WHENCHANGED-regels bevatten eerst DEFAULT en vervolgens COPY-regels binnen.

7. Hiermee staat u de gebruiker toe om te beginnen met bewerken.

8. De gebruiker wijzigt een veldwaarde en verplaatst vervolgens de focus van het veld.

9. Verhoog alle WHEN-regels voor dat veld die overeenkomen met de nieuwe waarde.

10. Verhoog eventuele WHENNOT-regels voor dat veld die overeenkomen met de nieuwe waarde.

11. Verhoog eventuele WHENCHANGED-regels voor dat veld die overeenkomen met de nieuwe waarde.

12. Retourneer de mogelijkheid om de gebruiker te bewerken.

13. De gebruiker slaat de wijzigingen in de database op.

14. Voor alle velden voert u SERVERDEFAULT-bewerkingen uit die zijn gedefinieerd voor het veld direct of indirect onder een WHEN- of WHENNOT-regel.

Toetsaanslagen en evaluatie van regels

Het systeem stelt een nieuwe waarde in voor een veld telkens wanneer een gebruiker een toetsaanslag binnen een veld invoert via het werkitemformulier. Dit betekent dat een voorwaardelijke regel onverwacht kan optreden wanneer aan de vereisten van de regel wordt voldaan.

In het volgende XML-voorbeeld leegt het systeem MyCorp.SubStatus terwijl u 'Goedgekeurd opnieuw' typt in het veld Status, omdat de REGEL WANNEER plaatsvindt zodra de gebruiker de letter 'e' typt in Goedgekeurd, zelfs als de beoogde uiteindelijke waarde niet 'Goedkeuren' is. Denk daarom zorgvuldig na wanneer u voorwaardelijke regels gebruikt.

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

Verwante artikelen:

• Voorbeeldregelscenario's
• Veldindex werkitem
• Werkitemvelden en -kenmerken
• Machtigingen op projectniveau wijzigen
• Machtigingen op projectverzamelingsniveau wijzigen
• Machtigingen en groepen
• Overgenomen proces
  • Een aangepaste regel toevoegen aan een werkitemtype
  • Regels toepassen op werkstroomstatussen
• On-premises XML-proces
  • Een standaardwaarde definiëren of een waarde kopiëren naar een veld
  • Selectielijsten definiëren
  • Waarden en regels op basis van voorwaardelijke voorwaarden toewijzen