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ří:
Uzavřený stav je vždy obsažen v kategorii Dokončeno.
Kategorie Dokončený stav není konfigurovatelná a je přidružená k jednomu a pouze jednomu státu.
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.
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í.
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í.
Tato pravidla jsou potřeba, pokud má typ pracovní položky vlastní stavy nebo typ pracovní položky je vlastní typ pracovní položky.
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.
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
Skrytí pole nebo nastavení pole jen pro čtení nebo povinné na základě členství ve státě a uživateli nebo skupině
Na základě členství uživatele nebo skupiny nastavte atribut pole nebo omezte přechod stavu.
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 WORKFLOWSTATEREASONpod , 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í.
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.
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.
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.
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").
XML
<FIELDrefname="MyCorp.Priority"name="Priority"type="String"
<HELPTEXT>Specify the severity of the problem</HELPTEXT
<ALLOWEDVALUES
<LISTITEMvalue="P1"/
<LISTITEMvalue="P2"/
<LISTITEMvalue="P3"/
</ALLOWEDVALUES
<DEFAULTfrom="value"value="P3"/
</FIELD
SERVERDEFAULT
Určuje hodiny serveru nebo aktuálního uživatele pro definování hodnoty pole.
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.
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 .
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.
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.
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í.
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.
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.
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ů.
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.
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 .
XML
<FIELDname="Assigned To"refname="System.AssignedTo"type="String"syncnamechanges="true"reportable="dimension"><HELPTEXT>The user who is working on this work item</HELPTEXT><ALLOWEXISTINGVALUE /><VALIDUSER /><ALLOWEDVALUESexpanditems="true"filteritems="excludegroups"><LISTITEMvalue="Active" /><LISTITEMvalue="[project]\Contributors" /></ALLOWEDVALUES><DEFAULTfrom="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.
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.
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.
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 ...
Chcete-li omezit pravidlo na základě členství aktuálního uživatele, zadáte buď fornot 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.
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í.
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.
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.
[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ů.
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:
[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:
XML
<FIELDname="Title"><READONLYfor="[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.
XML
<LISTITEMvalue="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.
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.
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.
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.
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.
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.
Pro všechna pole s podmíněným pravidlem, které odpovídá, použijte pravidla pro nastavení nebo zkopírování hodnoty pole.
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.
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.
Umožňuje uživateli začít s úpravami.
Uživatel změní hodnotu pole a přesune fokus z pole.
Zpracovat všechna pravidla pro toto pole, která odpovídají nové hodnotě.
Zpracujte libovolná pravidla When Not pro toto pole, která odpovídají nové hodnotě.
Zpracovat všechna pravidla při změně pro toto pole, která odpovídají nové hodnotě.
Vrácení možnosti úprav uživateli
Uživatel uloží změny do úložiště dat.
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.
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.
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.
Vyplňte výchozí hodnoty polí. Pro všechna pole použijte všechna výchozí pravidla zadaná mimo pravidla nebo když .
Zkopírujte hodnoty polí. Pro všechna pole použijte všechna pravidla COPY , která jsou mimo klauzule WHEN .
Pro všechna pole s pravidlem KDYŽ , které odpovídá, nejprve proveďte výchozí a potom zkopírujte pravidla uvnitř.
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 .
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ř.
Umožňuje uživateli začít s úpravami.
Uživatel změní hodnotu pole a přesune fokus z pole.
Zvedněte všechna pravidla WHEN pro toto pole, která odpovídají nové hodnotě.
Vyvolání všech pravidel WHENNOT pro toto pole, která odpovídají nové hodnotě.
Uvolněte všechna pravidla WHENCHANGED pro toto pole, která odpovídají nové hodnotě.
Vrácení možnosti úprav uživateli
Uživatel uloží změny do databáze.
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.