Pravidla a vyhodnocení pravidel

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

Pravidla slouží k nastavení nebo omezení přiřazení hodnot polím pracovní položky. Existují dva hlavní typy pravidel: automaticky generovaná pravidla a vlastní pravidla definovaná pro proces nebo projekt. Automaticky generovaná pravidla minimalizují potřebu přidávat vlastní pravidla pro oblasti, které by měly fungovat standardním způsobem.

Vlastní pravidla definujete pro podporu svých obchodních případů použití. V závislosti na datovém typu pole můžete nastavit různá omezení, která data se můžou do daného pole zadávat. Můžete zadat hodnoty pro výběrový seznam (rozevírací nabídka), nastavit výchozí hodnoty, vymazat položky nebo omezit změny. Pomocí podmíněných pravidel můžete pravidla pro pole použít na základě závislostí mezi hodnotami různých polí. Můžete také omezit, kdo může pole upravovat, nebo nastavit obor pravidla tak, aby se vztahoval pouze na skupinu.

Přečtěte si tento článek a seznamte se s následujícími informacemi:

• Jak systém používá automaticky generovaná pravidla
• Omezení definice vlastních pravidel v systémových polích
• Různé typy vlastních pravidel, která můžete použít
• Jak se vyhodnocují pravidla
• Rozdíl mezi pravidly definovanými pro proces dědičnosti a místním procesem XML
• Proč byste měli minimalizovat počet vlastních pravidel, která definujete

Před definováním vlastních pravidel si přečtěte článek Konfigurace a přizpůsobení Azure Boards , abyste získali široké znalosti o tom, jak přizpůsobit Azure Boards tak, aby vyhovovaly vašim obchodním potřebám.

Tip

Minimalizujte počet pravidel, která definujete pro definici wit. I když můžete pro typ pracovní položky vytvořit více pravidel, přidávaná pravidla můžou mít negativní vliv na výkon, když uživatel přidává a upravuje pracovní položky. Když uživatelé ukládají pracovní položky, systém ověří všechna pravidla přidružená k polím pro příslušný typ pracovní položky. Za určitých podmínek je pro SQL vyhodnocení ověřovacího výrazu pravidla příliš složité.

Automaticky generovaná pravidla

Automaticky generovaná pravidla minimalizují potřebu přidávat vlastní pravidla pro oblasti, které by měly fungovat standardním způsobem.

Pravidla přechodu stavu

Zděděné procesy generují celou sadu pravidel přechodu stavu typu any-to-any dynamicky pro každý vlastní typ pracovní položky a vlastní stav přidaný do pracovního postupu. Přechod z libovolného stavu do libovolného stavu je platný.

V případě místních procesů XML je nutné zadat platné přechody v WORKFLOW části definice typu pracovní položky.

Přechody států a pravidla polí Podle/Data

Pole Podle data odpovídají polím Created By/Date(Datum), Activated By/Date (Datum), Aktivováno podle/Date (Datum), Resolved By/Date (Datum) a Closed By/Date (Datum).

U zděděných procesů se tato pole při přechodu pracovní položky z jednoho stavu do jiného automaticky nastaví nebo vymažou. Pole Změněno podle a data nejsou zahrnuta, protože se aktualizují o každou uloženou pracovní položku a nesouvisejí s přechody stavu.

Mezi výchozí pravidla a chování, která řídí tato pole, patří:

1. Uzavřený stav je vždy obsažen v kategorii Dokončeno.
2. Kategorie Dokončený stav není konfigurovatelná a je přidružená k jednomu a pouze jednomu státu.
3. Tento uzavřený stav je vždy uzavřen pro procesy Agilní a CMMI a vždy dokončen pro scrum a základní procesy.
4. Automatické generování těchto pravidel je ovlivněno národním prostředím, protože podmínka pravidla obsahuje název státu, který je lokalizován. Systém generuje různá pravidla pro různá národní prostředí.
5. Automaticky generovaná pravidla pro tato pole jsou určena pouze pro typy pracovních položek, které obsahují tato pole. Typ pracovní položky může obsahovat jedno nebo více těchto polí.
6. Tato pravidla jsou potřeba, pokud má typ pracovní položky vlastní stavy nebo typ pracovní položky je vlastní typ pracovní položky.
7. Tato pravidla se vztahují pouze na zděděné procesy; nikdy se negenerují pro hostované procesy XML nebo místní procesy XML.

Stavy pracovního postupu jsou přidružené k kategoriím stavů pro podporu pracovního postupu na panelech. Další informace naleznete v tématu Jak se v backlogech a panelech používají stavy a kategorie stavů pracovního postupu.

Pravidla pole Datum změny stavu

Tato pravidla jsou technicky mnohem jednodušší než pravidla uzavřená podle/uzavření, protože nejsou závislá na žádném konkrétním stavu. U každého typu pracovní položky budou vždy fungovat stejná pravidla. Musí se automaticky generovat, protože některé typy pracovních položek OOB neobsahují pole Datum změny stavu, takže když uživatel toto pole přidá do vlastního typu pracovní položky, musí se tato pravidla automaticky vygenerovat i. Platí zde i stejné zásady pro pravidla uzavřeného a uzavřeného data.

Vlastní pravidla

Všechna vlastní pravidla jsou volitelná. Pro zděděný proces zadáte pravidlo, které se skládá z podmínky plus akce. Pro místní proces XML zadáte pravidla pro pole nebo v rámci pracovního postupu.

Mezi těmito dvěma procesy neexistuje mapování 1:1. V některých případech je pravidlo elementu XML definováno v dialogovém okně Upravit pole pro zděděný proces, nikoli jako pravidlo. Jiné elementy XML, například FROZEN, MATCHNOTSAMEASnejsou v zděděném procesu podporovány.

Je potřeba upozornit na následující:

• Pravidla se vždy vynucují nejen v případě, že pracujete s formulářem, ale také při interakci s jinými nástroji. Nastavení pole jako jen pro čtení například platí nejen pro formulář pracovní položky, ale také prostřednictvím rozhraní API a doplňku Azure DevOps Server Pro Excel.
• Zděděné položky procesu určují podmínky a akce pro provedení úplného pravidla. Prvky XML tyto rozdíly nerozlišují.
• Pravidla polí nepodporují přiřazování hodnot, které jsou součtem dvou dalších polí nebo prováděním jiných matematických výpočtů. Můžete ale najít řešení, které vyhovuje vašim potřebám prostřednictvím rozšíření TFS Aggregator (Webová služba) Marketplace. Viz také souhrn práce a dalších polí.
• Můžete najít další řešení pro použití vlastních pravidel u polí pomocí rozšíření Marketplace, jako je například rozšíření knihovny ovládacích prvků formuláře pracovní položky.

Složení pravidel

Proces dědičnosti

Pro zděděný proces se každé pravidlo skládá ze dvou částí: Podmínky a akce. Podmínky definují okolnosti, které musí být splněny, aby se pravidlo použilo. Akce definují operace, které se mají provést. U většiny pravidel můžete zadat maximálně dvě podmínky a 10 akcí na pravidlo. Všechna vlastní pravidla vyžadují splnění všech podmínek, aby bylo možné spustit.

Jako příklad můžete vytvořit pole povinné na základě hodnoty přiřazené státu a jiného pole. Příklad:

   (Condition) When a work item State isAktivní
   (Condition) And when the value ofOblast = hodnotPodnikání
   (Action) Then make requiredBody příběhu

Poznámka:

V současné době se pro pravidla přechodu stavu podporuje pouze jedna podmínka. Pokud používáte pravidla založená na stavu, přečtěte si téma Použití pravidel pro stavy pracovního postupu.

Následující tabulka shrnuje akce, které jsou k dispozici s vybranými podmínkami.

Condition (Podmínka)

Podporované akce

Nastavení hodnoty pole nebo povinného nebo jen pro čtení

Omezení přechodu na základě stavu

Na základě členství uživatele nebo skupiny nastavte atribut pole nebo omezte přechod stavu.

Místní proces XML

Místní proces XML definuje pravidla pomocí elementů XML. Všechny tyto prvky pravidla lze definovat v FIELD definici definice typu pracovní položky. A s výjimkou elementu HELPTEXT můžete určit tato pravidla, která mají mít vliv během přechodu pracovního postupu nebo jako podřízené prvky v rámci elementu (globální pracovní postup).FIELD

Poznámka:

Tento VALIDUSER element není podporován pro TFS 2018 a novější verze.

Kde použít pravidlo pole

Pokud chcete, aby pravidlo platilo pro pole v průběhu životnosti pracovní položky, zadejte ho v oddílu FIELD . Například pole, které je požadováno pro chybu, která je nová a aktivní, zůstává povinné, dokud se chyba neskončí. V opačném případě, pokud ho chcete použít na základě změny ve stavu, důvodu nebo přechodu, zadejte ho v oddílu WORKFLOW .

Pole State (System.State) a Reason (System.Reason) jsou definována v rámci oddílu WORKFLOW . Můžete zadat většinu pravidel polí, která se mají použít u pole během změny stavu, výběru důvodu nebo pro konkrétní přechod. Další informace naleznete v tématu Změna pracovního postupu pro typ pracovní položky.

V opačném případě zadejte pravidlo, které se má vyhodnotit pouze při změně stavu. Tato pravidla jsou definována v oddílu WORKFLOW STATEREASONpod , nebo TRANSITION elementy. Všechna pravidla, s výjimkou HELPTEXT, lze použít v rámci elementu FIELD (Workflow).

Pravidla polí jsou doplňková. To znamená, že můžete zadat čtyři sady pravidel pro stejné pole, které budou všechny vyhodnoceny modulem pravidel.

• Pravidla specifická pro typ pracovní položky platí bez ohledu na umístění pracovní položky v modelu stavu. Pravidlo například <REQUIRED \> provede následující kontrolu:

  "MyField Value" != NULL

• Pravidla specifická pro konkrétní stav jsou vymezena na instanci pracovní položky, pokud je v určitém stavu. Pravidlo specifické pro stav se vynucuje, pokud je splněna následující podmínka:

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

• Pravidla specifická pro přechod, která zadáte pro určitý přechod, jsou vymezena na pracovní položku, která prochází určitým přechodem. Tato pravidla se vynucují, pokud jsou splněny následující podmínky:

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

• Pravidla specifická pro důvod, která zadáte z konkrétního důvodu, jsou vymezena na konkrétní důvod konkrétního přechodu. Zpracovávají se, pokud jsou splněny následující podmínky:

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

Následující příklad omezuje úpravy pole závažnosti zákazníka, pokud je pracovní položka ve stavu Aktivní.

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

Co se stane, když je definováno příliš mnoho pravidel

Pro každý projekt je definován jeden výraz SQL, který ověřuje pracovní položky při každém vytvoření nebo aktualizaci. Tento výraz roste s počtem pravidel zadaných pro všechny typy pracovních položek definovaných pro projekt. Každý kvalifikátor chování zadaný pro pole vede ke zvýšení počtu dílčích výrazů. Vnořená pravidla, která se vztahují pouze na přechod nebo podmínku na hodnotě některého jiného pole, způsobují přidání dalších podmínek do IF příkazu. Jakmile výraz dosáhne určité velikosti nebo složitosti, SQL ho už nemůže vyhodnotit a vygenerovat chybu. Odstranění některých pracovních položek nebo odstranění některých pravidel může chybu vyřešit.

Můžete zadat hodnoty pro výběrový seznam (rozevírací nabídka), nastavit výchozí hodnoty, vymazat položky nebo omezit změny. Pomocí podmíněných pravidel můžete pravidla pro pole použít na základě závislostí mezi hodnotami různých polí. Můžete také omezit, kdo může pole upravovat, nebo nastavit obor pravidla tak, aby se vztahoval pouze na skupinu.

Pravidla pracovních položek neexistují jako jedna kolekce. Pravidla se ve skutečnosti dynamicky generují a slučují z různých zdrojů dat. Logika sloučení je jednoduchá, konsolidovat stejná pravidla, ale neoříznout konfliktní pravidla.

Pravidla obejití

Obecně platí, že všechny pracovní položky jsou ověřeny modulem pravidel, když uživatelé upravují pracovní položku. Aby však uživatelé přiřadili pravidla obejití pracovních položek , můžou kvůli podpoře určitých scénářů ukládat pracovní položky bez vyhodnocení pravidel na úrovni projektu.

Pravidla je možné obejít jedním ze dvou způsobů. První je prostřednictvím pracovních položek – aktualizujte rozhraní REST API a nastavujte bypassRules parametr na true. Druhá je prostřednictvím klientského objektového modelu inicializací v režimu obejití (inicializace WorkItemStore pomocí WorkItemStoreFlags.BypassRules).

Systémová pole a vlastní pravidla

Systémová pole mají systém.Názvy odkazů na názvy, například System.Title a System.State.

Následující systémová pole musí mít hodnotu: ID oblasti, změněné datum, datum vytvoření, datum vytvoření, stav a důvod.

Modul pravidel omezuje nastavení podmínek nebo akcí na systémová pole s výjimkou následujících podmínek:

• Pole Stav a Důvod můžete nastavit jen pro čtení.
• Většinu pravidel můžete použít u polí Název, Přiřazeno, Popis a Změněno podle .

Pokud v rozevírací nabídce uživatelského rozhraní pravidla pro proces dědičnosti nevidíte pole, je to důvod. Pokud se například pokusíte nastavit cestu k oblasti (System.AreaPath) jen pro čtení na základě podmínky, pole Cesta oblasti není k dispozici pro výběr. I když můžete zadat systémové pole, modul pravidel vám může zakázat uložení pravidla.

Výchozí a kopírovat pravidla

Výchozí pravidla a pravidla kopírování upravují hodnoty polí pracovních položek. Definují chování za běhu a omezení, například zadání výchozích hodnot, vymazání polí, vyžadování definování polí a další.

Použití těchto pravidel můžete omezit na základě členství ve skupině aktuálního uživatele, jak je popsáno v omezeních pravidel členství uživatele nebo skupiny.

Proces dědičnosti

Většinu těchto akcí pravidel je možné použít s výběrem libovolné podmínky.

Akce zděděného procesu

Popis

Copy the value from...

Určuje jiné pole, které obsahuje hodnotu, která se má zkopírovat do aktuálního pole.

Clear the value of...

Vymaže pole libovolné hodnoty, kterou obsahuje.

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

Nastaví čas pole na základě nastavení času aktuálního uživatele.

Místní proces XML

Tato pravidla podporují nastavení výchozích hodnot, kopírování hodnot z jednoho pole do druhého nebo vynucení hodnoty pole tak, aby odpovídaly předepsanému vzoru. Strukturu syntaxe a příklady najdete v tématu Definování výchozí hodnoty nebo zkopírování hodnoty do pole.

Element XML

Využití

COPY

Zkopíruje zadanou hodnotu do pole, když uživatel vytvoří nebo upraví pracovní položku.

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

DEFAULT

Určuje hodnotu pole, které je prázdné, když uživatel vytvoří nebo upraví pracovní položku. Pokud pole již obsahuje hodnotu, DEFAULT pravidlo se ignoruje. Výchozí pravidla se spustí jenom v případě, Is že je hodnota pole aktuálně prázdná. Mezi podporované hodnoty patří aktuální čas (from = "clock"), aktuální uživatel (from = "currentuser"), hodnota literálu (from = "value" value = "literal") nebo hodnota jiného pole (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

Určuje hodiny serveru nebo aktuálního uživatele pro definování hodnoty pole.

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

Pravidla omezení

Pravidla omezení omezují změnu hodnoty pole. Definují platné stavy pro pracovní položku. Každé omezení funguje na jednom poli. Omezení se vyhodnocují na serveru při ukládání pracovních položek a pokud dojde k porušení nějakého omezení operace uložení, operace uložení se odmítne.

Použití těchto pravidel můžete omezit na základě členství ve skupině aktuálního uživatele, jak je popsáno v omezeních pravidel členství uživatele nebo skupiny.

Proces dědičnosti

Většinu těchto akcí pravidel je možné použít s výběrem libovolné podmínky.

Akce zděděného procesu

Popis

Hide the field...
K dispozici pouze v případech, kdy je vybrána podmínka členství ve skupině.

Určuje, že se pole ve formuláři pracovní položky nezobrazí, v podstatě odebere možnost aktuálního uživatele změnit hodnotu pole.

Make read-only

Zabrání úpravě pole vůbec. Toto pravidlo můžete chtít použít za určitých podmínek. Například po zavření pracovní položky chcete vytvořit pole jen pro čtení, abyste zachovali data pro účely vytváření sestav.
Chcete-li zadat výchozí pole jen pro čtení, zadejte v dialogovém okně Upravit pole karta Možnosti .

Make required

Vyžaduje, aby uživatel zadal hodnotu pole. Uživatelé nemohou uložit pracovní položku, dokud nebudou přiřazeny hodnoty ke všem požadovaným polím.
Chcete-li zadat výchozí pole, zadejte v dialogovém okně Upravit pole karta Možnosti .

Místní proces XML

Element XML

Využití

ALLOWEDVALUES

Definuje seznam povolených hodnot pro pole. Povolené hodnoty jsou hodnoty, které jsou k dispozici pro výběr v seznamu polí ve formulářích pracovních položek a v tvůrci dotazů. Musíte vybrat jednu z těchto hodnot.

CANNOTLOSEVALUE

Zabrání uživatelům v vymazání pole hodnoty po zadání hodnoty. Tento prvek zachová aktuální hodnotu pole a nedá se vymazat ani vyprázdnit.

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

FROZEN

Zabrání uživatelům změnit hodnotu pole, jakmile obsahuje hodnotu. Jakmile uživatel uloží pracovní položku s hodnotou v daném poli, nebude už možné tuto hodnotu upravit. Po potvrzení změn nelze zablokované pole změnit na žádnou neprázdnou hodnotu. Pole však můžete ručně vymazat, uložit pracovní položku a pak zadat jinou hodnotu.

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

EMPTY

Vymaže pole libovolné hodnoty, kterou obsahuje, a pak pole nastaví jako jen pro čtení, když uživatel uloží pracovní položku. Neměli byste používat EMPTY s READONLY.
EMPTY se primárně používá během přechodu stavu k vymazání polí, která se vztahují na stav, na který položka přechází.

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

MATCH

Vynutí položky vytvořené do pole String tak, aby odpovídaly zadanému vzoru znaků nebo čísel. Pokud definujete více MATCH prvků, hodnota se považuje za platnou, pokud odpovídá některému ze zadaných vzorů. Pokud je alespoň jeden prvek úspěšný, pole má platnou hodnotu.

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

NOTSAMEAS

Zabrání přiřazení stejné hodnoty jako pole, které bylo přiřazeno jinému poli.

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

PROHIBITEDVALUES

Definuje seznam zakázaných hodnot pro pole. Pokud se na určité pole použije více ALLOWEDVALUES a/nebo PROHIBITEDVALUES pravidel, úplný seznam platných hodnot je průnikem všech povolených seznamů hodnot ( nebo vše, pokud neexistují žádné seznamy povolených hodnot – minus – tj. nastavit rozdíl – sjednocení všech zakázaných seznamů hodnot).

READONLY

Zabrání úpravě pole vůbec. Toto pravidlo můžete chtít použít za určitých podmínek. Například po zavření pracovní položky chcete vytvořit pole jen pro čtení, abyste zachovali data pro účely vytváření sestav.
Nepoužívejte READONLY s elementem EMPTY , protože EMPTY také vytvoří pole jen pro čtení. Kombinace těchto prvků může přinést nekonzistentní výsledky.
Kromě toho můžete pomocí atributu Control elementu ReadOnly vytvořit pole jako jen pro čtení z formuláře pracovní položky. Pole lze zapisovat do jiných klientů, ale ne prostřednictvím formuláře pracovní položky.

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

REQUIRED

Vyžaduje, aby uživatel zadal hodnotu pole. Uživatelé nemohou uložit pracovní položku, dokud nebudou přiřazeny hodnoty ke všem požadovaným polím.

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

Výběr seznamů

Vyberte seznamy definují hodnoty, které uživatel může nebo nemůže zvolit pro pole String nebo Integer. Hodnoty definované v rozevíracím seznamu se zobrazí ve formuláři pracovní položky a v editoru dotazů.

Proces dědičnosti

Pro zděděný proces jsou seznamy výběru definovány prostřednictvím dialogového okna Upravit pole.

Dialogové okno Upravit pole

Popis

Karta Definice pro pole rozevíracího seznamu

Definuje seznam povolených hodnot pro pole. Povolené hodnoty jsou hodnoty, které jsou k dispozici pro výběr v seznamu polí ve formulářích pracovních položek a v tvůrci dotazů. Musíte vybrat jednu z těchto hodnot.

Zaškrtněte políčko Povolit uživatelům zadat vlastní hodnoty na kartě Možnosti, aby uživatelé mohli zadat vlastní položky.

Definuje seznamnavrhovaných Navrhované hodnoty jsou hodnoty, které jsou k dispozici pro výběr v seznamu polí ve formulářích pracovních položek a v tvůrci dotazů. Kromě hodnot v seznamu můžete zadat i další hodnoty.

Místní proces XML

Výběrové seznamy definujete pomocí elementů XML uvedených v následující tabulce. Informace o struktuře syntaxe a příkladech najdete v tématu Definování seznamů výběrů.

Seznamy můžete kombinovat a rozbalit nebo uzavřít seznamy. Můžete také omezit použití těchto pravidel na základě členství ve skupině aktuálního uživatele, jak je popsáno v omezeních pravidel členství uživatele nebo skupiny.

Element XML

Popis

ALLOWEDVALUES

Definuje seznam povolených hodnot pro pole. Povolené hodnoty jsou hodnoty, které jsou k dispozici pro výběr v seznamu polí ve formulářích pracovních položek a v tvůrci dotazů. Musíte vybrat jednu z těchto hodnot.

ALLOWEXISTINGVALUE

Definuje pole, které povolí existující hodnoty. Tento prvek umožňuje použít hodnoty polí, které již existují, i když nejsou platné. Všechny nové hodnoty polí musí být platné.

PROHIBITEDVALUES

Definuje seznam zakázaných hodnot pro pole.

SUGGESTEDVALUES

Definuje seznamnavrhovaných Navrhované hodnoty jsou hodnoty, které jsou k dispozici pro výběr v seznamu polí ve formulářích pracovních položek a v tvůrci dotazů. Kromě hodnot v seznamu můžete zadat i další hodnoty.

Pole identit a chyby ověřování

Aby nedocházelo k chybám ověřování, ke kterým by jinak docházelo, když členové opustí tým a nejsou už zaregistrovaní jako přispěvatelé projektu, zahrňte element ALLOWEXISTINGVALUE pro pole Přiřazeno .

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

Hodnoty nebo změny podmíněného pole

Podmíněná pravidla určují akci na základě hodnoty pole, které se rovná určité hodnotě nebo se nerovná určité hodnotě, nebo pokud došlo ke změně nebo nebyla provedena na hodnotu konkrétního pole. Obecně platí, že podmíněná pravidla se použijí jako první nad nepodmíněnými pravidly. Pokud se vyhodnotí více podmíněných pravidel jako true, pořadí provádění je: When, WhenNot, WhenChanged, WhenNotChanged, WhenNotChanged.

Proces dědičnosti

Pro každé pole můžete zadat více podmíněných pravidel. Pro každé podmíněné pravidlo však můžete zadat pouze jedno pole pro řízení.

Zděděná podmínka

Popis

The value of ... (equals) [Když]

Určuje jedno nebo více pravidel, která se mají použít pro aktuální pole, pokud má jiné pole určitou hodnotu.

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

Použije jedno nebo více pravidel na aktuální pole při změně hodnoty konkrétního pole.

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

Použije jedno nebo více pravidel na aktuální pole, pokud jiné pole nemá určitou hodnotu.

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

Použije jedno nebo více pravidel na aktuální pole, pokud se nezmění hodnota konkrétního pole.

Zděděná akce

Popis

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

Určuje akci, která se má provést u konkrétního pole.

Místní proces XML

Následující elementy XML slouží k nastavení podmínek při vyhodnocování jiných pravidel. Pro každé pole můžete zadat více podmíněných pravidel. Pro každé podmíněné pravidlo však můžete zadat pouze jedno pole pro řízení. Podmíněná pravidla nelze vnořit. Podporované akce pro každý model procesu zahrnují ty, které jsou uvedené v následující tabulce.

Informace o struktuře syntaxe a příkladech najdete v tématu Přiřazení podmíněných hodnot a pravidel. Použití těchto pravidel můžete omezit na základě členství ve skupině aktuálního uživatele, jak je popsáno v omezeních pravidel členství uživatele nebo skupiny.

Element XML

Využití

WHEN

Určuje jedno nebo více pravidel, která se mají použít pro aktuální pole, pokud má jiné pole určitou hodnotu. Nadřazený prvek definuje aktuální pole.
Pokud zadané pole má zadanou hodnotu, pravidla v tomto prvku se použijí na aktuální pole.

WHENCHANGED

Určuje podmínku, za které se má použít jedno nebo více pravidel pro aktuální pole. Pravidla platí pro aktuální pole, když se hodnota jiného pole změní v revizi pracovní položky. Nadřazený prvek definuje aktuální pole.

WHENNOT

Určuje podmínku, za které se má použít jedno nebo více pravidel pro aktuální pole. Pravidla platí pro aktuální pole, když se změní hodnota jiného pole. Nadřazený prvek definuje aktuální pole.
Pokud zadané pole neobsahuje zadanou hodnotu, pravidla v tomto prvku se použijí na aktuální pole.

WHENNOTCHANGED

Určuje podmínku, za které se má použít jedno nebo více pravidel pro aktuální pole. Pravidla platí pro aktuální pole, pokud se hodnota jiného pole nezmění v revizi pracovní položky. Nadřazený prvek definuje aktuální pole.

Omezení pravidel členství uživatelů nebo skupin

Aplikaci pravidla můžete omezit na základě členství aktuálního uživatele. Doporučujeme nastavit obor pravidla na skupinu zabezpečení Azure DevOps, a ne na jednoho uživatele, i když můžete zadat toto pravidlo. Pokud chcete mít pravidlo omezené na více skupin, musíte vytvořit nadřazenou skupinu Azure DevOps, která obsahuje sadu skupin, které chcete použít.

Implementace procesu

Tip

Pokud se chcete vyhnout problémům s vyhodnocením pravidel, které mohou nastat, zadejte skupiny zabezpečení Azure DevOps, a ne skupiny zabezpečení Microsoft Entra NEBO Active Directory. Další informace najdete v tématu Výchozí pravidla a modul pravidel.

Proces dědičnosti

Jak je uvedeno v následující tabulce, pokud chcete omezit pravidlo na základě členství aktuálního uživatele, zadáte jednu ze dvou podmínek pro zděděný proces. Tato pravidla jsou aktivní pro Azure DevOps 2020 a novější verze.

Platí pro

Pravidlo

Podmínka

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

Akce

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

Místní proces XML

Chcete-li omezit pravidlo na základě členství aktuálního uživatele, zadáte buď for not atributy v elementu pravidla. Zadáte rozsah pravidla. Pokud chcete mít pravidlo omezené na více skupin, musíte vytvořit nadřazenou skupinu Azure DevOps, která obsahuje sadu skupin, které chcete použít.

Scénář

Využití

Nastavit pole jako povinné pouze pro zadanou skupinu

Slouží for k použití pravidla pro skupinu. Tento příklad vyžaduje, aby každý uživatel ve skupině Junior Analysts dokončil pole Druhého schvalovatele.

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

Omezení úpravy pole na skupinu uživatelů

Slouží not k vyloučení skupiny z pravidla. Tento příklad definuje pole Popis třídění jako jen pro čtení pro všechny kromě těch uživatelů ve skupině Výboru pro třídění.

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

Nastavení pole požadovaného pro některé uživatele, ne pro jiné

Použijte kombinaci for a not současně aplikovat pravidlo na některé a ne pro jiné. Tento příklad definuje závažnost jako povinné pole pro uživatele ve skupině Členové projektu, ale ne pro uživatele ve skupině Správci projektu. Pokud je uživatel v obou skupinách, for příkaz by se vynutil a pole by se vyžadovalo.

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

Použití tokenů k odkazování na uživatele nebo skupiny

Pole pro výběr identity nebo osob můžou přijímat hodnoty, které odkazují na uživatele i skupiny. Když omezíte pravidlo na skupinu, označíte doménu nebo obor skupiny. U některých hodnot můžete použít tokeny.

Proces dědičnosti

Mezi příklady tokenů patří:

• [Název_projektu], například [Fabrikam], [FabrikamFiber], [MyProject]
• [OrganizationName], například [fabrikam], [moje uspořádání]
• [CollectionName], například [fabrikam], [moje uspořádání]

Pokud se chcete dozvědět o oborech dostupných pro váš projekt nebo organizaci, přejděte na stránku Skupiny oprávnění>nastavení>projektu nebo skupiny oprávnění nastavení>>organizace, podle potřeby můžete seznam filtrovat. Následující obrázek například ukazuje první čtyři položky do filtrovaného seznamu založeného na Azure DevOps. Další informace naleznete v tématu Změna oprávnění na úrovni projektu nebo Změna oprávnění na úrovni kolekce projektů.

Místní proces XML

Mezi příklady tokenů patří:

• [Project], například [Project]\Contributors, [Project]\Fabrikam Team, [Project]\Project Approvers The [Project] token určuje skupinu definovanou pro projekt. To může odpovídat týmu, výchozí nebo vlastní skupině zabezpečení nebo skupině Active Directory, která byla přidána do projektu.
• [GLOBAL], pokud chcete odkazovat na skupinu s vymezenou kolekcí, například [GLOBAL]\Správci kolekce projektů používají [GLOBAL] k odkazování na skupinu zabezpečení s vymezenou kolekcí, například skupinu Správci kolekce projektů nebo skupinu Systému Windows přidanou do kolekce. Příklad:

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

• [Team Foundation] pokud chcete odkazovat na skupinu s vymezeným serverem, například [Team Foundation]\Team Foundation Administrators Use [Team Foundation] k odkazování na skupinu s vymezeným serverem, jako je integrovaná skupina nebo skupina Windows, kterou přidáte do skupiny na úrovni serveru. Příklad:

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

• [DomainName] pro odkazování na skupinu v oboru serveru, například [Team Foundation]\Team Foundation Administrators Název domény, například název účtu, který je uvedený v následujícím příkladu, lze použít k odkazování na uživatele domény nebo skupinu. Některá pravidla podporují jenom skupiny a nepodporují odkazování uživatelů domény.

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

Poznámka:

[Projekt], [GLOBAL] a [Team Foundation] se používají tak, jak je. Nenahrazujete je názvem projektu, kolekce nebo názvu serveru.

Informace o oborech dostupných pro váš projekt nebo kolekci najdete na stránce Skupiny oprávnění nastavení>>projektu nebo Skupiny oprávnění nastavení>>kolekce. Podle potřeby vyfiltrujte seznam. Následující obrázek například ukazuje první čtyři položky do filtrovaného seznamu založeného na Azure DevOps. Další informace naleznete v tématu Změna oprávnění na úrovni projektu nebo Změna oprávnění na úrovni kolekce projektů.

Všichni uživatelé a skupiny musí být kvalifikovaní jedním z těchto tokenů. Například následující xml není platný, protože nekvalifikuje zadanou skupinu s platným tokenem.

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

Další informace o výchozích skupinách zabezpečení najdete v tématu Oprávnění a skupiny.

Vyhodnocení pravidla

Pravidla, která určují podmínku na základě členství uživatele nebo skupiny uživatele, který upravuje pracovní položku, se vyhodnocují jedním ze dvou způsobů. Při vyhodnocování pravidla musí aplikace určit, jestli se pravidlo vztahuje na aktuálního uživatele, a to tak, že zkontroluje, jestli je daný uživatel nebo není členem zadané skupiny.

• Při úpravě pracovní položky z webového portálu, rozhraní REST API nebo příkazu azure boards se vytvoří požadavek na ID Microsoft Entra nebo Active Directory. U této operace nedochází k žádným problémům.
• Při úpravě pracovní položky ze sady Visual Studio, Excelu nebo jiného vlastního nástroje pomocí klientského objektového modelu WIT je požadavek na vyhodnocení členství založený na mezipaměti klienta. Mezipaměť klienta nezná skupiny služby Active Directory.

Poznámka:

Visual Studio 2019 Team Explorer for projects using GIT has been re-written to use REST APIs.

Pokud se chcete vyhnout problémům s aktualizacemi pracovních položek uživatelů z různých klientů, místo skupin zabezpečení Active Directory zadejte skupiny zabezpečení Azure DevOps. Skupinu zabezpečení Azure DevOps můžete snadno vytvořit tak, aby odpovídala skupině Active Directory. Informace o tom, jak, najdete v tématu Přidání nebo odebrání uživatelů nebo skupin, správa skupin zabezpečení.

Poznámka:

Virtuální počítač klienta WIT je zastaralý. Od 1. ledna 2020 už není podporována při práci s Azure DevOps Services a Azure DevOps Serverem 2020.

Pořadí, ve kterém se pravidla vyhodnocují

Pravidla se obvykle zpracovávají v posloupnosti, ve které jsou uvedeny. Úplná posloupnost vyhodnocení všech pravidel ale není plně deterministická.

Tato část popisuje očekávané chování a interakce při použití podmíněných, kopírování a výchozích pravidel.

Proces dědičnosti

Následující kroky ukazují ve správném pořadí interakce, které Azure DevOps provádí, a uživatelem formuláře pracovní položky. Uživatel provádí pouze kroky 1, 8 a 13.

1. Z klienta Azure DevOps, jako je webový portál nebo Visual Studio Team Explorer, uživatel vytvoří novou pracovní položku nebo upraví existující pracovní položku.

2. Vyplňte výchozí hodnoty polí. U všech polí použijte všechny výchozí hodnoty přiřazené k poli, které nejsou součástí podmíněné klauzule.

3. Zkopírujte nebo nastavte hodnoty polí. U všech polí použijte všechna pravidla ke zkopírování hodnoty nebo nastavení hodnoty pole, které nejsou součástí podmíněné klauzule.

4. Pro všechna pole s podmíněným pravidlem, které odpovídá, použijte pravidla pro nastavení nebo zkopírování hodnoty pole.

5. Pro všechna pole s podmíněným pravidlem, které neodpovídá, použijte pravidla pro nastavení nebo zkopírování hodnoty pole.

   Systém vždy zpracovává pravidla před pravidly When Not.

6. Pro všechna pole, u kterých došlo ke změně hodnot od kroku 1 a která obsahují pravidla Při změně , použijte pravidla pro nastavení nebo zkopírování hodnoty pole.

7. Umožňuje uživateli začít s úpravami.

8. Uživatel změní hodnotu pole a přesune fokus z pole.

9. Zpracovat všechna pravidla pro toto pole, která odpovídají nové hodnotě.

10. Zpracujte libovolná pravidla When Not pro toto pole, která odpovídají nové hodnotě.

11. Zpracovat všechna pravidla při změně pro toto pole, která odpovídají nové hodnotě.

12. Vrácení možnosti úprav uživateli

13. Uživatel uloží změny do úložiště dat.

14. U všech polí použijte všechny Use the current time to set the value of ... akce definované pro toto pole přímo nebo nepřímo v rámci podmíněného pravidla.

Místní proces XML

Pravidla se obvykle zpracovávají v posloupnosti, ve které jsou uvedeny. Pokud však použijete elementy WHEN, DEFAULT a COPY , může se použít další chování. Následující kroky ukazují ve správném pořadí interakce, které Azure DevOps provádí, a uživatelem formuláře pracovní položky. Uživatel provádí pouze kroky 1, 8 a 13.

1. Z klienta Azure DevOps, jako je webový portál nebo Visual Studio Team Explorer, uživatel vytvoří novou pracovní položku nebo upraví existující pracovní položku.

2. Vyplňte výchozí hodnoty polí. Pro všechna pole použijte všechna výchozí pravidla zadaná mimo pravidla nebo když .

3. Zkopírujte hodnoty polí. Pro všechna pole použijte všechna pravidla COPY , která jsou mimo klauzule WHEN .

4. Pro všechna pole s pravidlem KDYŽ , které odpovídá, nejprve proveďte výchozí a potom zkopírujte pravidla uvnitř.

5. Pro všechna pole s pravidlem WHENNOT, které odpovídá, nejprve proveďte výchozí a potom zkopírujte pravidla uvnitř.

   Systém vždy zpracovává pravidla WHEN před pravidly WHENNOT .

6. U všech polí, u kterých byly hodnoty změněny od kroku 1 a která obsahují pravidla WHENCHANGED , proveďte nejprve výchozí a potom zkopírujte pravidla uvnitř.

7. Umožňuje uživateli začít s úpravami.

8. Uživatel změní hodnotu pole a přesune fokus z pole.

9. Zvedněte všechna pravidla WHEN pro toto pole, která odpovídají nové hodnotě.

10. Vyvolání všech pravidel WHENNOT pro toto pole, která odpovídají nové hodnotě.

11. Uvolněte všechna pravidla WHENCHANGED pro toto pole, která odpovídají nové hodnotě.

12. Vrácení možnosti úprav uživateli

13. Uživatel uloží změny do databáze.

14. U všech polí proveďte operace SERVERDEFAULT definované pro pole přímo nebo nepřímo pod pravidlem WHEN nebo WHENNOT.

Položky stisknutí kláves a vyhodnocení pravidel

Systém nastaví novou hodnotu pole pokaždé, když uživatel zadá stisknutí klávesy do pole prostřednictvím formuláře pracovní položky. To znamená, že podmíněné pravidlo může dojít neočekávaně pokaždé, když jsou splněny požadavky pravidla.

V následujícím příkladu XML systém vyprázdní MyCorp.SubStatus při psaní "Schváleno znovu" do pole Stav, protože když pravidlo WHEN nastane, jakmile uživatel zadá písmeno "e" ve Schválené, i když zamýšlená konečná hodnota není "Schválit". Proto pečlivě zvažte, kdy používáte podmíněná pravidla.

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

Související články

• Ukázkové scénáře pravidel
• Index pole pracovních položek
• Pole a atributy pracovní položky
• Změna oprávnění na úrovni projektu
• Změna oprávnění na úrovni kolekce projektů
• Oprávnění a skupiny
• Zděděný proces
  • Přidání vlastního pravidla do typu pracovní položky
  • Použití pravidel na stavy pracovního postupu
• Místní proces XML
  • Definování výchozí hodnoty nebo zkopírování hodnoty do pole
  • Definování seznamů výběrů
  • Přiřazení podmíněných hodnot a pravidel