Použití pravidel pro stavy pracovního postupu (proces dědičnosti)

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

Po přidání nebo úpravě stavů pracovního postupu pro typ pracovní položky můžete chtít definovat jedno nebo více pravidel, která se použijí v závislosti na změně stavu pracovního postupu. Přidání pravidel do stavů pracovního postupu podporuje následující scénáře:

  • Podpora schvalovacího procesu
  • Zabránění neoprávněným uživatelům v nastavení neplatného stavu
  • Nastavení pole jako povinného nebo jen pro čtení nebo jiné hodnoty na základě změn stavu
  • Omezení přechodu z jednoho stavu do jiného
  • Omezení nebo povolení přechodů stavu na konkrétní uživatele nebo skupiny
  • Udržování řízeného procesu pracovního postupu pro podporu požadavků auditování
  • Automatizace uzavírání nadřazených pracovních položek
  • Podpora schvalovacího procesu
  • Zabránění neoprávněným uživatelům v nastavení neplatného stavu
  • Nastavení pole jako povinného nebo jen pro čtení nebo jiné hodnoty na základě změn stavu
  • Omezení přechodu z jednoho stavu do jiného
  • Automatizace uzavírání nadřazených pracovních položek
  • Podpora schvalovacího procesu
  • Nastavení pole jako povinného nebo jen pro čtení nebo jiné hodnoty na základě změn stavu
  • Automatizace uzavírání nadřazených pracovních položek

V tomto článku se dozvíte, jak definovat pravidla, která se použijí při změně stavu pracovního postupu.

  • Vysvětlení typů pravidel pracovního postupu
  • Omezení stavu a pravidel pracovního postupu a osvědčené postupy
  • Nastavení hodnoty pole nebo nastavení pole jen pro čtení nebo povinné na základě výběru stavu
  • Omezení přechodů stavu
  • Omezení nebo povolení přechodů stavu na konkrétní uživatele nebo skupiny
  • Automatizace přechodů stavu nadřazených pracovních položek
  • Vysvětlení typů pravidel pracovního postupu
  • Omezení stavu a pravidel pracovního postupu a osvědčené postupy
  • Nastavení hodnoty pole nebo nastavení pole jen pro čtení nebo povinné na základě výběru stavu
  • Omezení přechodů stavu
  • Automatizace přechodů stavu nadřazených pracovních položek
  • Vysvětlení typů pravidel pracovního postupu
  • Omezení stavu a pravidel pracovního postupu a osvědčené postupy
  • Nastavení hodnoty pole nebo nastavení pole jen pro čtení nebo povinné na základě výběru stavu
  • Automatizace přechodů stavu nadřazených pracovních položek

Důležité

Tento článek se týká Azure DevOps Services a Azure DevOps Server 2019 a novějších verzí. Informace o přizpůsobení libovolného projektu definovaného v kolekci pro TFS 2018 nebo starší verzi najdete v tématu Místní model procesu XML.

Důležité

Model procesu dědičnosti můžete použít pouze pro projekty definované v kolekci projektů nakonfigurované tak, aby podporovaly model procesu dědičnosti. Pokud je vaše místní kolekce nakonfigurovaná tak, aby používala místní model procesu XML, můžete tento model procesu použít pouze k přizpůsobení prostředí pro sledování práce. Další informace najdete v tématu Přizpůsobení sledování práce, Volba modelu procesu pro kolekci projektů.

Informace o přizpůsobení libovolného projektu definovaného v kolekci pro TFS 2018 nebo starší verzi najdete v tématu Místní model procesu XML.

Pravidla pracovního postupu

Následující tabulka uvádí tři skupiny pravidel pracovního postupu, které můžete definovat. První skupina použije standardní akce při vytvoření pracovní položky, ve vybraném stavu nebo přesunutí z jednoho stavu do druhého. Tyto standardní akce nastaví hodnotu pole nebo nastaví pole jen pro čtení nebo povinné. V této skupině můžete zadat jednu nebo dvě podmínky a několik akcí.

Druhá a třetí skupina podporují omezení přechodů stavu. Tyto dvě skupiny umožňují zadat jednu a jenom jednu podmínku označující stav, do který se pracovní položka přesunula. Potom můžete zadat jednu nebo více akcí, které omezí přechod z tohoto stavu do jiných stavů.

Následující tabulka uvádí dvě skupiny pravidel pracovního postupu, které můžete definovat. První skupina použije standardní akce při vytvoření pracovní položky, ve vybraném stavu nebo přesunutí z jednoho stavu do druhého. Tyto standardní akce nastaví hodnotu pole nebo nastaví pole jen pro čtení nebo povinné. V této skupině můžete zadat jednu nebo dvě podmínky a několik akcí.

Druhá skupina podporuje omezení přechodů stavu. V této druhé skupině můžete zadat jednu a jenom jednu podmínku označující stav, do který se pracovní položka přesunula. Potom můžete zadat jednu nebo více akcí, které omezí přechod z tohoto stavu do jiných stavů.

Poznámka

Některé funkce vyžadují instalaci aktualizace Azure DevOps Server 2020.1. Další informace najdete v tématu Azure DevOps Server 2020 Update 1 RC1 – Poznámky k verzi, Panely.

Podmínky a akce pracovního postupu, které můžete nastavit, jsou znázorněny na následujících obrázcích. Standardní akce můžete použít, když je pracovní položka vytvořena, ve vybraném stavu nebo je přesunuta z jednoho stavu do jiného. Tyto standardní akce nastaví hodnotu pole nebo nastaví pole jen pro čtení nebo je povinné. Pro tuto sadu pravidel můžete zadat jednu nebo dvě podmínky a několik akcí.


Condition (Podmínka)

Podporované akce


Nastavení hodnoty pole nebo nastavení jen pro čtení nebo povinné na základě state

Podmínky, pracovní položka je vytvořená

Akce, pracovní položka je vytvořena


Omezení přechodu na základě stavu

Podmínka, pracovní položka se přesune

Akce, omezení transakce na základě state.


Skrytí pole nebo nastavení pole jen pro čtení nebo povinné na základě stavu a členství uživatelů nebo skupin

Podmínka, členství ve skupině uživatelů

Akce, omezení transakce na základě stavu a členství.


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

Podmínka, členství ve skupině uživatelů

Akce, omezení transakce na základě stavu a členství.


Poznámka

Při přizpůsobení zděděného procesu se všechny projekty, které tento proces používají, automaticky aktualizují tak, aby odrážely vlastní nastavení. Z tohoto důvodu doporučujeme, abyste vytvořili testovací proces a projekt testování, pokud máte řadu přizpůsobení, která je třeba provést, abyste je mohli otestovat ještě před jejich uvedením do vaší organizace. Další informace najdete v tématu Vytváření a správa zděděných procesů.

Omezení stavu a pravidel pracovního postupu

Následující tabulka shrnuje limity stavu pracovního postupu a pravidel pro proces dědičnosti.

Objekt Limit dědičnosti
Typy pracovních položek definované pro proces 64
Stavy pracovního postupu definované pro typ pracovní položky 32
Pravidla definovaná pro typ pracovní položky 1024

Při definování stavů a pravidel pracovního postupu doporučujeme zvážit následující doprovodné materiály, abyste minimalizovali problémy s výkonem.

  • Minimalizujte počet pravidel, která definujete pro 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é.
  • Minimalizujte počet vlastních typů pracovní položky, které definujete.

Pravidla pracovního postupu se použijí při přidávání nebo úpravách pracovních položek prostřednictvím některého z následujících rozhraní:

  • Webový portál: Formulář pracovní položky, hromadné aktualizace, aktualizace v zobrazení dotazu
  • Webový portál: Panel Kanbanu nebo Taskboard, přesunout pracovní položku do sloupce
  • Visual Studio 2017 a starší verze, formulář pracovní položky
  • Formát souboru CSV: hromadný import nebo aktualizace
  • Excel: hromadný import nebo aktualizace
  • ROZHRANÍ REST API: Přidání nebo úprava pracovních položek

Definování pravidla

Před definováním pravidla založeného na stavech pracovního postupu nezapomeňte nejprve definovat následující prvky:

Základní informace o definování pravidel najdete v tématu Přidání vlastního pravidla. Musíte splňovat požadavky definované v tomto článku.

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

Při prvním seskupení pravidel můžete zadat jednu nebo dvě podmínky a až 10 akcí na pravidlo.

Příklad zajištění schválení vedoucího týmu před aktivní prací

V tomto příkladu chtějí vývojové týmy zajistit, aby se žádný uživatelský scénář nepracoval, dokud ho neschválili vedoucí týmu. Výchozí stavy pracovního postupu se používají a přidá se pouze jedno vlastní pole Schváleno a skupina zabezpečení Team Lead Group.

Výchozí stavy pracovního postupu

Agilní proces, uživatelský scénář, výchozí stav pracovního postupu

Požadavky na pravidla

Aby se zajistilo schválení před aktivní prací, musí být definována následující pravidla:

  • Vyžadovat vyplnění pole Schváleno, když se stát přesune z nového na aktivní.
  • Omezit uživatele, kteří nepatří do skupiny potenciálních zákazníků týmu, na vyplnění pole Schváleno
  • Když se stát přesune na Nový nebo Odebraný, vymažte pole Schváleno.

Definice pravidel

Požadavky na pravidla se překládají na následující čtyři definice pravidel.

   


Název pravidla

Condition (Podmínka)

Akce


Schváleno uživatelem vymazáno, když je nový

Kdy A work item state changes to New

Pak Clear the value of Approved By

Schváleno uživatelem vymazáno při odebrání

Kdy A work item state changes to Removed

Pak Clear the value of Approved By

Schváleno jen pro čtení

Kdy Current user is not member of group Team Leads Group

Pak Make read-only Approved By

Autor schválení vyžaduje

Kdy A work item state changes from New to Active

Pak Make required Approved By


Omezení přechodů stavu

Při zadávání podmínky A work item state moved from ...můžete zadat pouze tuto podmínku. Můžete zadat až 10 akcí.

Poznámka

Tato funkce vyžaduje aktualizaci Azure DevOps Server 2020.1 nebo novější verzi.

Příklad omezení přechodů stavu a schváleného stavu

V souladu s terminologií používanou obchodní skupinou jsou pro uživatelský scénář definovány následující stavy pracovního postupu. Zděděné stavy Nový, Vyřešeno a Odebráno jsou skryté. Místo toho se použijí navrhované stavy, revizní stavy a stavy vyjmutí . Kromě toho jsou definovány tři další stavy: Prozkoumat, Návrh a Schváleno. Tyto stavy by měly následovat sekvenci, jak je znázorněno na následujícím obrázku.

Uživatelský scénář, stavy pracovního postupu

Uživatelé můžou bez jakýchkoli omezení přecházet z jednoho státu do libovolného jiného stavu, a to jak dopředu, tak dozadu v rámci sekvence.

Požadavky na pravidla

V rámci podpory více řízeného pracovního postupu se obchodní skupina rozhodla vytvořit pravidla, která by podporovala následující přechody dopředného a zpětného stavu u typu pracovní položky Uživatelský scénář.

  • Navrhované může přejít pouze na research a vyjmout.
  • Výzkum se dá přesunout jenom na návrh a vyjmout.
  • Návrh se dá přesunout jenom na Zdroje informací, Schválení a Vyjmout.
  • Schváleno se dá přesunout jenom na Návrh, Aktivní a Vyjmout.
  • Aktivní se může přesunout jenom do části Při kontrole.
  • V části Revize se dá přesunout jenom na Aktivní (nalezená další práce), Uzavřená nebo Vyjmout
  • Uzavřená může přejít na Zdroje informací, Návrh, Aktivní, Zkontrolovat (umožňuje případy, kdy uživatel zavřel pracovní položku omylem)
  • Možnost Vyjmout se může přesunout jenom na Navrhované.

Poznámka

Při omezování přechodů stavů zvažte případy, kdy uživatel přesune stav omylem. Chcete, aby uživatelé mohli provést řádné obnovení.

Obchodní skupina chce také použít pravidla pro povinná pole:

  • Vyžadovat vyplnění pole Schváleno, když se stát přesune ze schváleného na aktivní
  • Povolit vyplnění pole Schváleno pouze uživatelům, kteří patří do skupiny Autorizovaní schvalovatelé.
  • Vymažte pole Schváleno, když se stát přesune na Vyjmout.
  • Vyžadovat, aby se kritéria přijetí vyplnila, když se stát přesune na Aktivní

Definice pravidel

Pro implementaci výše uvedených omezení správce procesu přidá vlastní pole identity Schváleno , skupinu zabezpečení Autorizovaní schvalovatelé a následujících jedenáct pravidel.

   


Název pravidla

Condition (Podmínka)

Akce


Navrhovaný stav

Kdy A work item state moved from Proposed

Pak Restrict the state transition to Design
A Restrict the state transition to Approved
A Restrict the state transition to Active
A Restrict the state transition to In Review
A Restrict the state transition to Closed

Stav výzkumu

Kdy A work item state moved from Research

Pak Restrict the state transition to Proposed
A Restrict the state transition to Approved
A Restrict the state transition to Active
A Restrict the state transition to In Review
A Restrict the state transition to Closed

Stav návrhu

Kdy A work item state moved from Design

Pak Restrict the state transition to Proposed
A Restrict the state transition to Research
A Restrict the state transition to Active
A Restrict the state transition to In Review
A Restrict the state transition to Closed

Schválený stav

Kdy A work item state moved from Approved

Pak Restrict the state transition to Proposed
A Restrict the state transition to Research
A Restrict the state transition to Design
A Restrict the state transition to In Review
A Restrict the state transition to Closed

Aktivní stav

Kdy A work item state moved from Active

Pak Restrict the state transition to Proposed
A Restrict the state transition to Research
A Restrict the state transition to Design
A Restrict the state transition to Approved
A Restrict the state transition to Closed

Ve stavu revize

Kdy A work item state moved from In Review

Pak Restrict the state transition to Proposed
A Restrict the state transition to Research
A Restrict the state transition to Design
A Restrict the state transition to Approved

Uzavřený stav

Kdy A work item state moved from Closed

Pak Restrict the state transition to Proposed
A Restrict the state transition to Cut

Vyjmout stav

Kdy A work item state moved from Cut

Pak Restrict the state transition to Research
A Restrict the state transition to Design
A Restrict the state transition to Approved
A Restrict the state transition to Active
A Restrict the state transition to In Review
A Restrict the state transition to Closed

Povinná pole schváleného stavu

Kdy A work item changes from Approved to Active

Pak Make required Acceptance Criteria
A Make required Approved By

Autorizovaní schvalovatelé

Kdy Current user is not a member of Authorized Approvers

Pak Make read-only Approved By

Vymazat pole Schváleno

Kdy A work item state changes to Cut

Pak Clear the value of Approved By


Ověření omezení přechodu stavu

Jakmile jsou pravidla definovaná pro proces a projekt se s procesem aktualizují, aktualizujte prohlížeč a zkontrolujte operace prostřednictvím formuláře pracovní položky a z prohlížeče Kanban.

U pravidel definovaných v předchozí tabulce byste měli vidět následující rozevírací nabídky Stav. Otevřete panel Kanbanu a zkontrolujte možnost přecházet z jednoho státu do druhého.

Proposed Výzkum Návrh Schválené
Nabídka Navrhované Nabídka Zdroje informací Nabídka Návrh Schválená nabídka
Aktivní V revizi Uzavřeno Vyjmout
Aktivní nabídka V nabídce Zkontrolovat Zavřená nabídka Nabídka Vyjmout

Omezení přechodu stavu na základě členství uživatele nebo skupiny

Při zadávání jedné ze dvou podmínek na základě členství Current user is member of group ... uživatele nebo skupiny nebo Current user is not member of group ...můžete zadat pouze jednu podmínku. Pokud zadáte akci Restrict the transition to state..., můžete zadat pouze jednu akci.

Poznámka

Pracovní položky podléhají pravidlům, která se na ně vztahují. Podmíněná pravidla založená na členství uživatele nebo skupiny se ukládají do mezipaměti webového prohlížeče. Pokud zjistíte, že jste omezili aktualizaci pracovní položky, možná jste narazili na jedno z těchto pravidel. Pokud se domníváte, že jste narazili na problém, který se vás netýká, přečtěte si téma Problémy s ukládáním do mezipaměti indexdb ve formuláři pracovní položky.

Automatizace přechodů stavu nadřazených pracovních položek

Pokud chcete automatizovat přechody stavu nadřazených pracovních položek na základě přiřazení stavu provedených k podřízeným pracovním položkám, můžete přidat web hook a použít kód a konfiguraci, které jsou k dispozici v projektu Automate State Transitions na GitHubu.

Poznámka

Projekt Automate State Transitions na GitHubu není podporovanou funkcí Azure Boards, a proto není podporován produktovým týmem. V případě dotazů, návrhů nebo problémů, které máte při používání těchto rozšíření, je napište na stránce projektu GitHub.

Automatizace opětovného přiřazení na základě změny stavu

Typ pracovní položky chyby agilního procesu měl dříve pravidlo, které chybu znovu přiřadí osobě, která ji vytvořila. Toto pravidlo bylo odebráno z výchozího systémového procesu. Pomocí následující podmínky a akce můžete pravidlo obnovit nebo přidat podobné pravidlo k jiným typům pracovních položek:

KdyA work item state changes toVyřešenoPotomCopy the value from byl vytvořen uživatelemPřiřazeno.

Poznámka

Změny zděděného procesu můžete zkontrolovat prostřednictvím protokolu auditu. Další informace najdete v tématu Přístup, export a filtrování protokolů auditu.