Reguły i ocena reguł
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Reguły umożliwiają ustawianie lub ograniczanie przypisań wartości do pola elementu roboczego. Istnieją dwa główne typy reguł: reguły generowane automatycznie i reguły niestandardowe zdefiniowane dla procesu lub projektu. Reguły generowane automatycznie minimalizują potrzebę dodawania reguł niestandardowych w obszarach, które powinny działać standardowo.
Reguły niestandardowe można zdefiniować w celu obsługi przypadków użycia występujących w Twojej firmie. W zależności od typu danych w polu można ustawić różne ograniczenia danych, które można wprowadzić w tym polu. Można określić wartości, które znajdą się na liście wyboru (w menu rozwijanym), ustawić wartości domyślne, wyczyścić wpisy lub ograniczyć zmiany. Za pomocą reguł warunkowych można stosować reguły do pola na podstawie zależności między wartościami różnych pól. Można również ograniczyć możliwość modyfikowania pola do określonych osób lub określić zakres reguły, tak aby dotyczyła tylko określonej grupy.
Przeczytaj ten artykuł, aby zrozumieć następujące kwestie:
- Jak system stosuje reguły generowane automatycznie
- Ograniczenia dotyczące definicji reguł niestandardowych w polach systemowych
- Różne typy reguł niestandardowych, które można zastosować
- Jak są oceniane reguły
- Różnica między regułami zdefiniowanymi dla procesu dziedziczenia a lokalnym procesem XML
- Dlaczego należy zminimalizować liczbę zdefiniowanych reguł niestandardowych
Przed zdefiniowaniem reguł niestandardowych przeczytaj artykuł Configure and customize Azure Boards (Konfigurowanie i dostosowywanie usługi Azure Boards ), aby uzyskać szeroką wiedzę na temat dostosowywania usługi Azure Boards pod kątem potrzeb biznesowych.
Napiwek
Zminimalizuj liczbę reguł zdefiniowanych dla funkcji WIT. Chociaż można utworzyć wiele reguł dla typu elementu roboczego, dodawanie reguł może negatywnie wpływać na wydajność, gdy użytkownik dodaje i modyfikuje elementy robocze. Gdy użytkownicy zapisują elementy robocze, system weryfikuje wszystkie reguły skojarzone z polami dla typu elementu roboczego. W pewnych warunkach wyrażenie weryfikacji reguły jest zbyt złożone, aby aparat SQL mógł je ocenić.
Reguły generowane automatycznie
Reguły generowane automatycznie minimalizują potrzebę dodawania reguł niestandardowych w obszarach, które powinny działać standardowo.
Reguły przejścia stanu
Procesy dziedziczone generują cały zestaw reguł przejścia stanu dowolne-dowolne dynamicznie dla każdego niestandardowego typu elementu roboczego i stanu niestandardowego dodanego do przepływu pracy. Przejście z dowolnego stanu do dowolnego stanu jest prawidłowe.
W przypadku lokalnych procesów XML należy określić prawidłowe przejścia w WORKFLOW sekcji definicji typu elementu roboczego.
Przejścia stanu i reguły pól Według/Daty
Pola Według/Daty odpowiadają polam Utworzone według/Data, Aktywowane według/Data, Rozwiązane według/Data i Zamknięte według/Data.
W przypadku procesów dziedziczych te pola są automatycznie ustawiane lub czyszczone po przeniesieniu elementu roboczego z jednego stanu na inny. Pola Zmienione według/daty nie są uwzględniane, ponieważ są aktualizowane przy użyciu każdego zapisu elementu roboczego i nie są powiązane z przejściami stanu.
Domyślne reguły i zachowania, które zarządzają tymi polami, obejmują:
- Stan Zamknięty jest zawsze zawarty w kategorii Stan ukończony.
- Kategoria Ukończono stan nie jest konfigurowalna i jest skojarzona z jednym i tylko jednym stanem.
- Ten stan Zamknięty jest zawsze zamknięty dla procesów Agile i CMMI, a zawsze gotowe dla procesów Scrum i Podstawowych.
- Automatyczne generowanie tych reguł ma wpływ na ustawienia regionalne, ponieważ warunek reguły zawiera nazwę stanu, która jest zlokalizowana. System generuje różne reguły dla różnych ustawień regionalnych.
- Reguły generowane automatycznie dla tych pól są określane tylko dla typów elementów roboczych, które zawierają te pola. Typ elementu roboczego może nie zawierać co najmniej jednego z tych pól.
- Te reguły są wymagane, gdy typ elementu roboczego ma stany niestandardowe lub typ elementu roboczego jest niestandardowym typem elementu roboczego.
- Te reguły mają zastosowanie tylko do procesów dziedziczynych; nigdy nie są generowane dla hostowanych procesów XML lub lokalnych plików XML.
Stany przepływu pracy są skojarzone z kategoriami stanów w celu obsługi przepływu pracy na tablicach. Aby uzyskać więcej informacji, zobacz How workflow states and state categories are used in Backlogs and Boards (Jak są używane stany przepływu pracy i kategorie stanów w listach prac i tablicach).
Reguły pól Zmiany stanu
Te reguły są technicznie znacznie prostsze niż reguły zamknięte przez/zamknięte, ponieważ nie są zależne od żadnego określonego stanu. W przypadku dowolnego typu elementu roboczego te same reguły będą zawsze działać. Muszą one być generowane automatycznie, ponieważ niektóre typy elementów roboczych OOB nie zawierają pola Data zmiany stanu, więc gdy użytkownik dodaje to pole do niestandardowego typu elementu roboczego, te reguły muszą być również generowane automatycznie. Te same zasady dotyczące reguł zamkniętych/zamkniętych dat obowiązują również tutaj.
Reguły niestandardowe
Wszystkie reguły niestandardowe są opcjonalne. W przypadku dziedziczonego procesu należy określić regułę, która składa się z warunku plus akcji. W przypadku lokalnego procesu XML należy określić reguły dla pola lub w przepływie pracy.
Nie istnieje mapowanie jeden do jednego między dwoma procesami. W niektórych przypadkach reguła elementu XML jest definiowana w oknie dialogowym Edytowanie pola dla dziedziczonego procesu, a nie jako reguła. Inne elementy XML, takie jak FROZEN, , NOTSAMEASMATCH, nie są obsługiwane w procesie dziedziczony.
Należy zwrócić uwagę na następujące kwestie:
- Reguły są zawsze wymuszane, nie tylko w przypadku interakcji z formularzem, ale także podczas interfacingu za pośrednictwem innych narzędzi. Na przykład ustawienie pola jako tylko do odczytu nie tylko stosuje regułę w formularzu elementu roboczego, ale także za pośrednictwem interfejsu API i dodatku programu Excel Azure DevOps Server.
- Wpisy dziedziczonego procesu określają warunki i akcje, aby utworzyć pełną regułę. Elementy XML nie rozróżniają tych różnic.
- Reguły pól nie obsługują przypisywania wartości, które są sumą dwóch innych pól ani wykonywania innych obliczeń matematycznych. Można jednak znaleźć rozwiązanie, które odpowiada Twoim potrzebom za pośrednictwem rozszerzenia serwera TFS Aggregator (usługa internetowa) Marketplace. Zobacz również zestawienie pracy i innych pól.
- Możesz znaleźć dodatkowe rozwiązania do stosowania reguł niestandardowych do pól przy użyciu rozszerzeń witryny Marketplace, takich jak rozszerzenie biblioteki kontrolek formularza elementu roboczego.
Kompozycja reguły
W przypadku dziedziczonego procesu każda reguła składa się z dwóch części: Warunków i akcji. Warunki definiują okoliczności, które należy spełnić w celu zastosowania reguły. Akcje definiują operacje do wykonania. W przypadku większości reguł można określić maksymalnie dwa warunki i 10 akcji na regułę. Wszystkie reguły niestandardowe wymagają spełnienia wszystkich warunków w celu uruchomienia.
Na przykład można ustawić pole wymagane na podstawie wartości przypisanej do stanu i innego pola. Na przykład:
(Condition) When a work item State isAktywny
(Condition) And when the value ofObszar = wartościBiznes
(Action) Then make requiredPunkty historii
Uwaga
Obecnie tylko jeden warunek jest obsługiwany w przypadku reguł przejścia stanu. Jeśli stosujesz reguły na podstawie stanu, zobacz Stosowanie reguł do stanów przepływu pracy.
Poniższa tabela zawiera podsumowanie akcji, które są dostępne z wybranymi warunkami.
Warunek
Obsługiwane akcje
Ustawianie wartości pola lub wymaganie lub tylko do odczytu
Ograniczanie przejścia na podstawie stanu
Ukryj pole lub ustaw pole tylko do odczytu lub wymagane na podstawie członkostwa w stanie i użytkowniku lub grupie
Na podstawie członkostwa użytkownika lub grupy ustaw atrybut pola lub ogranicz przejście stanu
Co się stanie, jeśli zdefiniowano zbyt wiele reguł
Pojedyncze wyrażenie SQL jest definiowane dla każdego projektu w celu weryfikowania elementów roboczych za każdym razem, gdy zostaną utworzone lub zaktualizowane. To wyrażenie rośnie wraz z liczbą reguł określonych dla wszystkich typów elementów roboczych zdefiniowanych dla projektu. Każdy kwalifikator behawioralny określony dla pola powoduje zwiększenie liczby wyrażeń podrzędnych. Zagnieżdżone reguły, reguły, które mają zastosowanie tylko w przypadku przejścia lub warunku wartości innego pola, powodują dodanie większej liczby warunków do IF instrukcji. Gdy wyrażenie osiągnie określony rozmiar lub złożoność, program SQL nie może go już ocenić i wygenerować błąd. Usunięcie niektórych sieci WIT lub wyeliminowanie niektórych reguł może rozwiązać ten błąd.
Można określić wartości, które znajdą się na liście wyboru (w menu rozwijanym), ustawić wartości domyślne, wyczyścić wpisy lub ograniczyć zmiany. Za pomocą reguł warunkowych można stosować reguły do pola na podstawie zależności między wartościami różnych pól. Można również ograniczyć możliwość modyfikowania pola do określonych osób lub określić zakres reguły, tak aby dotyczyła tylko określonej grupy.
Reguły elementów roboczych nie istnieją jako pojedyncza kolekcja. Reguły są faktycznie generowane dynamicznie i scalane z różnych źródeł danych. Logika scalania jest prosta, konsoliduj identyczne reguły, ale nie przycinaj reguł konfliktów.
Pomijanie reguł
Ogólnie rzecz biorąc, wszystkie elementy robocze są weryfikowane przez aparat reguł podczas modyfikowania elementu roboczego przez użytkowników. Jednak w celu obsługi niektórych scenariuszy użytkownicy przypisani do reguł obejścia dla elementu roboczego aktualizują uprawnienia na poziomie projektu mogą zapisywać elementy robocze bez oceniania reguł.
Reguły można pominąć na jeden z dwóch sposobów. Pierwszy z nich dotyczy elementów roboczych — aktualizowanie interfejsu API REST i ustawianie parametru bypassRules na truewartość . Drugi jest oparty na modelu obiektów klienta, inicjując w trybie bypassrules (inicjowanie WorkItemStore za pomocą WorkItemStoreFlags.BypassRulespolecenia ).
Pola systemowe i reguły niestandardowe
Pola systemowe mają system.Nazwy odwołań, na przykład System.Title i System.State.
Następujące pola systemowe muszą mieć wartość: Identyfikator obszaru, Data zmiany, Data utworzenia, Utworzona przez, Stan i Przyczyna.
Aparat reguł ogranicza ustawianie warunków lub akcji do pól systemowych, z wyjątkiem następujących:
- Możesz ustawić pola Stan i Przyczyna tylko do odczytu.
- Większość reguł można zastosować do pól Tytuł, Przypisane do, Opis i Zmienione według.
Jeśli nie widzisz pola wymienionego w menu rozwijanym interfejsu użytkownika reguły dla procesu dziedziczenia, dlatego jest to przyczyna. Jeśli na przykład spróbujesz ustawić ścieżkę obszaru (System.AreaPath) tylko do odczytu na podstawie warunku, pole Ścieżka obszaru nie jest dostępne do wyboru. Nawet jeśli możesz określić pole systemowe, aparat reguł może ograniczyć zapisywanie reguły.
Reguły domyślne i reguły kopiowania
Reguły domyślne i reguły kopiowania modyfikują wartości pól elementów roboczych. Definiują one zachowanie i ograniczenia czasu wykonywania, takie jak określanie wartości domyślnych, czyszczenie pól, wymaganie definiowania pól i nie tylko.
Można ograniczyć stosowanie tych reguł na podstawie członkostwa w grupie bieżącego użytkownika zgodnie z opisem w temacie Ograniczenia reguły członkostwa w użytkownikach lub grupach.
Większość tych akcji reguły można zastosować przy wyborze dowolnego warunku.
Akcja dziedziczonego procesu
Opis
Copy the value from...
Określa inne pole, które zawiera wartość do skopiowania do bieżącego pola.
Clear the value of...
Czyści pole dowolnej wartości, która zawiera.
Use the current time to set the value of ...
Ustawia czas dla pola na podstawie ustawienia czasu bieżącego użytkownika.
Reguły ograniczeń
Reguły ograniczeń ograniczają zmianę wartości pola. Definiują prawidłowe stany elementu roboczego. Każde ograniczenie działa w jednym polu. Ograniczenia są oceniane na serwerze podczas zapisywania elementu roboczego, a jeśli jakiekolwiek ograniczenie zostanie naruszone, operacja zapisywania zostanie odrzucona.
Można ograniczyć stosowanie tych reguł na podstawie członkostwa w grupie bieżącego użytkownika zgodnie z opisem w temacie Ograniczenia reguły członkostwa w użytkownikach lub grupach.
Większość tych akcji reguły można zastosować przy wyborze dowolnego warunku.
Akcja dziedziczonego procesu
Opis
Hide the field...
Dostępne tylko po wybraniu warunku członkostwa w grupie.
Określa, aby nie wyświetlać pola w formularzu elementu roboczego, zasadniczo usuwając możliwość zmiany wartości pola przez bieżącego użytkownika.
Make read-only
Uniemożliwia modyfikowanie pola w ogóle. Możesz chcieć zastosować tę regułę w określonych warunkach. Na przykład po zamknięciu elementu roboczego chcesz ustawić pole tylko do odczytu, aby zachować dane na potrzeby raportowania.
Aby określić pole domyślne jest tylko do odczytu, określ w oknie dialogowym Edytowanie pola kartę Opcje .
Make required
Wymaga od użytkownika określenia wartości pola. Użytkownicy nie mogą zapisać elementu roboczego do momentu przypisania wartości do wszystkich wymaganych pól.
Aby określić wartość domyślną pola, określ wartość w oknie dialogowym Edytowanie pola, karcie Opcje .
Wybieranie list
Wybierz listy definiują wartości, które użytkownik może lub nie może wybrać dla pola Ciąg lub Liczba całkowita. Wartości zdefiniowane na liście wyboru są wyświetlane w formularzu elementu roboczego i edytorze zapytań.
W przypadku procesu dziedziczonego listy wyboru są definiowane za pośrednictwem okna dialogowego Edytowanie pola.
Okno dialogowe Edytowanie pola
Opis
Karta Definicja dla pola listy wyboru
Definiuje listę dozwolonych wartości dla pola. Dozwolone wartości to wartości, które są dostępne do wyboru na liście pól w formularzach elementów roboczych i w konstruktorze zapytań. Musisz wybrać jedną z tych wartości.
Zaznacz pole wyboru Zezwalaj użytkownikom na wprowadzanie własnych wartości na karcie Opcje, aby umożliwić użytkownikom określanie własnych wpisów
Definiuje listę sugerowanych wartości dla pola. Sugerowane wartości to wartości, które są dostępne do wyboru na liście pól w formularzach elementów roboczych i w konstruktorze zapytań. Możesz dodatkowo wprowadzić inne wartości na liście.
Wartości lub zmiany pól warunkowych
Reguły warunkowe określają akcję na podstawie wartości pola równego lub nie równej określonej wartości, lub jeśli zmiana była lub nie została wprowadzona do wartości określonego pola. Ogólnie rzecz biorąc, zasady warunkowe są stosowane najpierw w przypadku zasad bezwarunkowych. Jeśli wiele reguł warunkowych ma wartość true, kolejność wykonywania to: When, WhenNot, WhenChanged, WhenNotChanged.
Można określić wiele reguł warunkowych na pole. Można jednak określić tylko jedno pole jazdy dla reguły warunkowej.
Warunek dziedziczony
Opis
The value of ... (equals) [Kiedy]
Określa co najmniej jedną regułę, która ma być stosowana do bieżącego pola, gdy inne pole ma określoną wartość.
A change was made to the value of ... [WhenChanged]
Stosuje co najmniej jedną regułę do bieżącego pola po zmianie wartości określonego pola.
The value of ... (not equals) [WhenNot]
Stosuje co najmniej jedną regułę do bieżącego pola, gdy inne pole nie ma określonej wartości.
No change was made to the value of ... [WhenNotChanged]
Stosuje co najmniej jedną regułę do bieżącego pola, gdy wartość określonego pola nie zostanie zmieniona.
Akcja dziedziczona
Opis
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 ...
Określa akcję do wykonania dla określonego pola.
Ograniczenia reguły członkostwa użytkowników lub grup
Można ograniczyć stosowanie reguły na podstawie członkostwa bieżącego użytkownika. Zalecamy określenie zakresu reguły do grupy zabezpieczeń usługi Azure DevOps, a nie pojedynczego użytkownika, chociaż można określić tę drugą. Aby reguła obejmowała wiele grup, należy utworzyć nadrzędną grupę usługi Azure DevOps zawierającą zestaw grup, których chcesz użyć.
Implementacja procesu
Napiwek
Aby uniknąć problemów z oceną reguł, które mogą wystąpić, określ grupy zabezpieczeń usługi Azure DevOps, a nie Identyfikator entra firmy Microsoft lub grupy zabezpieczeń usługi Active Directory. Aby uzyskać więcej informacji, zobacz Reguły domyślne i aparat reguł.
Jak wskazano w poniższej tabeli, aby ograniczyć regułę na podstawie członkostwa bieżącego użytkownika, należy określić jeden z dwóch warunków dla procesu dziedziczonego. Te reguły są aktywne dla usługi Azure DevOps 2020 i nowszych wersji.
Dotyczy
Reguła
Stan
Current user is a member of group ...
Current user is not member of group ...
Akcja
Hide the field ...
Make read-only ...
Make required ...
Restrict the transition to state ...
Używanie tokenów do odwołowania się do użytkowników lub grup
Pola tożsamości lub selektora osób mogą akceptować wartości odwołujące się zarówno do użytkowników, jak i grup. W przypadku ograniczenia reguły do grupy należy wskazać domenę lub zakres grupy. W przypadku niektórych wartości można użyć tokenów.
Przykłady tokenów obejmują następujące elementy:
- [ProjectName], takie jak [Fabrikam], [FabrikamFiber], [MyProject]
- [OrganizationName], na przykład [fabrikam], [myorganization]
- [CollectionName], na przykład [fabrikam], [myorganization]
Aby dowiedzieć się więcej o zakresach dostępnych dla projektu lub organizacji, przejdź do strony Grupy uprawnień>ustawień>projektu lub Grupy uprawnień>ustawień>organizacji, możesz filtrować listę zgodnie z potrzebami. Na przykład na poniższej ilustracji przedstawiono pierwsze cztery wpisy do filtrowanej listy opartej na usłudze Azure DevOps. Aby uzyskać więcej informacji, zobacz Zmienianie uprawnień na poziomie projektu lub Zmienianie uprawnień na poziomie kolekcji projektów.
Aby dowiedzieć się więcej o domyślnych grupach zabezpieczeń, zobacz Uprawnienia i grupy
Ocena reguły
Reguły określające warunek oparty na członkostwie użytkownika lub grupy modyfikującego element roboczy są oceniane na jeden z dwóch sposobów. Po ocenie reguły aplikacja musi określić, czy reguła ma zastosowanie do bieżącego użytkownika, sprawdzając, czy dany użytkownik jest lub nie jest członkiem określonej grupy.
- Podczas modyfikowania elementu roboczego z portalu internetowego, interfejsu API REST lub polecenia usługi Azure Boards zostaje wykonane żądanie do identyfikatora Entra firmy Microsoft lub usługi Active Directory. W przypadku tej operacji nie występują żadne problemy.
- Podczas modyfikowania elementu roboczego z programu Visual Studio, programu Excel lub innego niestandardowego narzędzia przy użyciu modelu obiektów klienta WIT żądanie oceny członkostwa jest oparte na pamięci podręcznej klienta. Pamięć podręczna klienta nie jest świadoma grup usługi Active Directory.
Uwaga
Program Visual Studio 2019 Team Explorer dla projektów korzystających z narzędzia GIT został ponownie napisany w celu korzystania z interfejsów API REST.
Aby uniknąć problemów z aktualizowaniem elementów roboczych przez użytkowników z różnych klientów, określ grupy zabezpieczeń usługi Azure DevOps zamiast grup usługi Active Directory. Możesz łatwo utworzyć grupę zabezpieczeń usługi Azure DevOps odpowiadającą grupie usługi Active Directory. Aby dowiedzieć się, jak, zobacz Dodawanie lub usuwanie użytkowników lub grup, zarządzanie grupami zabezpieczeń.
Uwaga
Element OM klienta WIT jest przestarzały. Od 1 stycznia 2020 r. nie jest już obsługiwana podczas pracy z usługami Azure DevOps Services i Azure DevOps Server 2020.
Kolejność oceniania reguł
Reguły są zwykle przetwarzane w sekwencji, w której są wymienione. Jednak kompletna sekwencja oceny wszystkich reguł nie jest w pełni deterministyczna.
W tej sekcji opisano oczekiwane zachowanie i interakcje podczas stosowania reguł warunkowych, kopiowania i domyślnych.
Poniższe kroki pokazują, w odpowiedniej kolejności, interakcje wykonywane przez usługę Azure DevOps i przez użytkownika formularza elementu roboczego. Użytkownik wykonuje tylko kroki 1, 8 i 13.
Na podstawie klienta usługi Azure DevOps — takiego jak portal internetowy lub Program Visual Studio Team Explorer — użytkownik tworzy nowy element roboczy lub edytuje istniejący element roboczy.
Wypełnij wartości domyślne pól. W przypadku wszystkich pól zastosuj wszystkie wartości domyślne przypisane do pola, które nie są częścią klauzuli warunkowej.
Skopiuj lub ustaw wartości pól. W przypadku wszystkich pól zastosuj reguły, aby skopiować wartość lub ustawić wartość pola, które nie są częścią klauzuli warunkowej.
Dla wszystkich pól z regułą warunkową When, która jest zgodna, zastosuj reguły, aby ustawić lub skopiować wartość pola.
W przypadku wszystkich pól z regułą warunkową Gdy nie jest zgodna, zastosuj reguły, aby ustawić lub skopiować wartość pola.
System zawsze przetwarza reguły When rules before When Not rules (Kiedy nie są regułami).
W przypadku wszystkich pól, które miały zmienione wartości od kroku 1 i które zawierają reguły Po zmianie , zastosuj reguły, aby ustawić lub skopiować wartość pola.
Zezwól użytkownikowi na rozpoczęcie edytowania.
Użytkownik zmienia wartość pola, a następnie przenosi fokus z pola.
Przetwarzaj dowolne reguły When dla tego pola zgodnego z nową wartością.
Przetwórz dowolną regułę When Not dla tego pola, które jest zgodne z nową wartością.
Przetwarzaj dowolne reguły po zmianie dla tego pola zgodnego z nową wartością.
Zwracanie możliwości edytowania użytkownikowi.
Użytkownik zapisuje zmiany w magazynie danych.
W przypadku wszystkich pól zastosuj wszelkie
Use the current time to set the value of ...akcje zdefiniowane dla pola bezpośrednio lub pośrednio w ramach reguły warunkowej.