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

1. Stan Zamknięty jest zawsze zawarty w kategorii Stan ukończony.
2. Kategoria Ukończono stan nie jest konfigurowalna i jest skojarzona z jednym i tylko jednym stanem.
3. Ten stan Zamknięty jest zawsze zamknięty dla procesów Agile i CMMI, a zawsze gotowe dla procesów Scrum i Podstawowych.
4. 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.
5. 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.
6. Te reguły są wymagane, gdy typ elementu roboczego ma stany niestandardowe lub typ elementu roboczego jest niestandardowym typem elementu roboczego.
7. 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 Kanban. Aby dowiedzieć się więcej, 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

Proces dziedziczenia

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 isAktywne
   (Condition) And when the value ofBiznes w obszarze = wartości
   (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

Na podstawie członkostwa użytkownika lub grupy ustaw atrybut pola lub ogranicz przejście stanu

Lokalny proces XML

Lokalny proces XML definiuje reguły przy użyciu elementów XML. Wszystkie te elementy reguły można zdefiniować w FIELD definicji definicji typu elementu roboczego. Z wyjątkiem HELPTEXT elementu można określić te reguły, które mają mieć wpływ podczas przejścia przepływu pracy lub jako elementy podrzędne w elemecie FIELD (globalny przepływ pracy).

Uwaga

Element VALIDUSER nie jest obsługiwany w przypadku wersji TFS 2018 i nowszych.

Gdzie stosować regułę pola

Jeśli chcesz, aby reguła miała być stosowana do pola przez cały okres życia elementu roboczego, określ ją w FIELD sekcji. Na przykład pole wymagane dla usterki, która jest nowa i aktywna, pozostaje wymagane do momentu zamknięcia usterki. W przeciwnym razie, jeśli ma zostać zastosowana na podstawie zmiany stanu, przyczyny lub przejścia, określ ją w WORKFLOW sekcji .

Pola State (System.State) i Reason (System.Reason) są definiowane w WORKFLOW sekcji . Można określić większość reguł pól, które mają być stosowane do pola podczas zmiany stanu, wyboru przyczyny lub dla określonego przejścia. Aby dowiedzieć się więcej, zobacz Zmienianie przepływu pracy dla typu elementu roboczego.

W przeciwnym razie określ regułę, która ma być oceniana tylko podczas zmiany stanu. Te reguły są definiowane w WORKFLOW sekcji w STATEobszarze elementów , REASONlub TRANSITION . Wszystkie reguły, z wyjątkiem HELPTEXT, mogą być stosowane w elemecie FIELD (Przepływ pracy).

Reguły pól są addytywne. Oznacza to, że można określić cztery zestawy reguł dla tego samego pola, które zostaną ocenione przez aparat reguł.

• Reguły specyficzne dla typu elementu roboczego mają zastosowanie niezależnie od lokalizacji elementu roboczego w modelu stanu. Na przykład reguła <REQUIRED \> wykonuje następujące sprawdzanie:

  "MyField Value" != NULL

• Reguły specyficzne dla stanu są ograniczone do wystąpienia elementu roboczego, gdy jest w określonym stanie. Reguła specyficzna dla stanu jest wymuszana, gdy spełniony jest następujący warunek:

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

• Reguły specyficzne dla przejścia określone dla określonego przejścia są ograniczone do elementu roboczego, który przechodzi określone przejście. Te reguły są wymuszane, gdy spełnione są następujące warunki:

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

• Reguły specyficzne dla przyczyny określone dla określonego powodu są ograniczone do określonej przyczyny określonego przejścia. Są one przetwarzane, gdy spełnione są następujące warunki:

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

Poniższy przykład ogranicza modyfikację pola ważności klienta, gdy element roboczy jest w stanie Aktywny.

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

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.

Proces dziedziczenia

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.

Lokalny proces XML

Te reguły obsługują ustawienie domyślne, kopiowanie wartości z jednego pola do innego lub wymuszanie wartości pola w celu dopasowania do określonego wzorca. Aby zapoznać się ze strukturą składni i przykładami, zobacz Definiowanie wartości domyślnej lub kopiowanie wartości do pola.

Element XML

Użycie

COPY

Kopiuje określoną wartość do pola, gdy użytkownik tworzy lub modyfikuje element roboczy.

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

DEFAULT

Określa wartość pola, które jest puste, gdy użytkownik tworzy lub modyfikuje element roboczy. Jeśli pole ma już wartość, reguła DEFAULT jest ignorowana. Reguły domyślne są wykonywane tylko wtedy, gdy Is wartość pola jest obecnie pusta. Obsługiwane wartości obejmują bieżący czas (), bieżący użytkownik (from = "clock"from = "currentuser"), wartość literału (from = "value" value = "literal") lub wartość innego pola (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

Określa zegar serwera lub bieżący użytkownik, aby zdefiniować wartość pola.

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

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.

Proces dziedziczenia

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 .

Lokalny proces XML

Element XML

Użycie

ALLOWEDVALUES

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.

CANNOTLOSEVALUE

Uniemożliwia użytkownikom wyczyszczenie pola wartości po określeniu wartości. Ten element przechowuje bieżącą wartość pola i nie może zostać wyczyszczone ani puste.

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

FROZEN

Uniemożliwia użytkownikom zmianę wartości pola po jego utworzeniu. Gdy tylko użytkownik zapisze element roboczy z wartością w tym polu, nie można już modyfikować wartości. Nie można zmienić pola zamrożonego na dowolną niepustą wartość po zatwierdzeniu zmian. Można jednak ręcznie wyczyścić pole, zapisać element roboczy, a następnie określić inną wartość.

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

EMPTY

Czyści pole dowolnej wartości, która zawiera, a następnie powoduje, że pole jest tylko do odczytu, gdy użytkownik zapisuje element roboczy. Nie należy używać z READONLYprogramem EMPTY .
EMPTY Jest używany głównie podczas przejścia stanu do wyczyszczenia pól, które mają zastosowanie do stanu, do którego przechodzi element.

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

MATCH

Wymusza wprowadzanie wpisów do pola Ciąg w celu zachowania zgodności z określonym wzorcem znaków lub liczb. Jeśli zdefiniujesz wiele MATCH elementów, wartość jest uważana za prawidłową, jeśli pasuje do dowolnego określonego wzorca. Jeśli co najmniej jeden element zakończy się pomyślnie, pole ma prawidłową wartość.

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

NOTSAMEAS

Uniemożliwia przypisanie pola tej samej wartości co pole, które zostało przypisane do innego pola.

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

PROHIBITEDVALUES

Definiuje listę niedozwolonych wartości dla pola. Jeśli wiele ALLOWEDVALUES reguł i/lub PROHIBITEDVALUES ma zastosowanie do określonego pola, pełna lista prawidłowych wartości jest przecięciem wszystkich dozwolonych list wartości — lub wszystkiego, jeśli nie ma dozwolonych list wartości — minus — czyli ustawiania różnicy — unii wszystkich niedozwolonych list wartości.

READONLY

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.
Nie należy używać READONLY z elementem EMPTY , ponieważ EMPTY powoduje również, że pole jest tylko do odczytu. Połączenie tych elementów może przynieść niespójne wyniki.
Ponadto można ustawić, aby pole było wyświetlane jako tylko do odczytu z formularza elementu roboczego przy użyciu atrybutu Control elementu ReadOnly . Pole może być zapisywane przez innych klientów, ale nie za pośrednictwem formularza elementu roboczego.

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

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.

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

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

Proces dziedziczenia

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.

Lokalny proces XML

Listy wyboru definiuje się przy użyciu elementów XML wymienionych w poniższej tabeli. Aby zapoznać się ze strukturą składni i przykładami, zobacz Definiowanie list wyboru.

Można łączyć listy i rozwijać lub listy kontraktów. Ponadto 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 użytkownika lub grupy.

Element XML

Opis

ALLOWEDVALUES

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.

ALLOWEXISTINGVALUE

Definiuje pole, aby zezwolić na istniejące wartości. Ten element umożliwia używanie wartości pól, które już istnieją, nawet jeśli są nieprawidłowe. Wszystkie nowe wartości pól muszą być prawidłowe.

PROHIBITEDVALUES

Definiuje listę niedozwolonych wartości dla pola.

SUGGESTEDVALUES

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.

Pola tożsamości i błędy walidacji

Aby uniknąć błędów walidacji, które w przeciwnym razie wystąpią, gdy członkowie opuszczają zespół i nie są już zarejestrowani jako współautorzy projektu, uwzględnij element ALLOWEXISTINGVALUE dla pola Przypisane do .

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

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.

Proces dziedziczenia

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.

Lokalny proces XML

Następujące elementy XML są używane do ustawiania warunków, dla których są oceniane inne reguły. Można określić wiele reguł warunkowych na pole. Można jednak określić tylko jedno pole jazdy dla reguły warunkowej. Nie można zagnieżdżać reguł warunkowych. Obsługiwane akcje dla każdego modelu procesów obejmują te wymienione w poniższej tabeli.

Aby zapoznać się ze strukturą składni i przykładami, zobacz Przypisywanie wartości i reguł opartych na warunkowych regułach. 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.

Element XML

Użycie

WHEN

Określa co najmniej jedną regułę, która ma być stosowana do bieżącego pola, gdy inne pole ma określoną wartość. Element nadrzędny definiuje bieżące pole.
Gdy określone pole ma określoną wartość, reguły w tym elemencie są stosowane do bieżącego pola.

WHENCHANGED

Określa warunek, w którym należy zastosować co najmniej jedną regułę do bieżącego pola. Reguły dotyczą bieżącego pola, gdy wartość innego pola zostanie zmieniona w wersji elementu roboczego. Element nadrzędny definiuje bieżące pole.

WHENNOT

Określa warunek, w którym należy zastosować co najmniej jedną regułę do bieżącego pola. Reguły dotyczą bieżącego pola, gdy wartość innego pola ulegnie zmianie. Element nadrzędny definiuje bieżące pole.
Jeśli określone pole nie zawiera określonej wartości, reguły w tym elemencie są stosowane do bieżącego pola.

WHENNOTCHANGED

Określa warunek, w którym należy zastosować co najmniej jedną regułę do bieżącego pola. Reguły dotyczą bieżącego pola, gdy wartość innego pola nie zostanie zmieniona w poprawce elementu roboczego. Element nadrzędny definiuje bieżące pole.

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 dowiedzieć się więcej, zobacz Reguły domyślne i aparat reguł.

Proces dziedziczenia

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

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

Lokalny proces XML

Aby ograniczyć regułę na podstawie członkostwa bieżącego użytkownika, należy określić for atrybuty lub not w elemencie reguły. Należy określić zakres reguły. 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ć.

Scenariusz

Użycie

Ustaw pole wymagane tylko dla określonej grupy

Użyj for polecenia , aby zastosować regułę do grupy. W tym przykładzie każdy użytkownik w grupie Analitycy juniorzy musi ukończyć pole Drugie zatwierdzanie.

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

Ograniczanie modyfikacji pola do grupy użytkowników

Użyj polecenia not , aby wykluczyć grupę z reguły. W tym przykładzie zdefiniowano pole Opis klasyfikacji jako tylko do odczytu dla wszystkich z wyjątkiem tych użytkowników w grupie Komitet klasyfikacji.

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

Ustaw pole wymagane dla niektórych użytkowników, a nie dla innych

Użyj kombinacji i fornot , aby jednocześnie zastosować regułę do niektórych, a nie dla innych. W tym przykładzie zdefiniowano ważność jako pole wymagane dla użytkowników w grupie Członkowie projektu, ale nie dla tych w grupie Project Administracja s. Jeśli użytkownik znajduje się w obu grupach, for instrukcja zostanie wymuszona, a pole będzie wymagane.

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

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.

Proces dziedziczenia

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 programu Project Ustawienia> Permissions> lub Grupy organizacji Ustawienia> Permissions>, 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 dowiedzieć się więcej, zobacz Zmienianie uprawnień na poziomie projektu lub Zmienianie uprawnień na poziomie kolekcji projektów.

Lokalny proces XML

Przykłady tokenów obejmują następujące elementy:

• [Project], na przykład [Project]\Contributors, [Project]\Fabrikam Team, [Project]\Project Approvers token [Project] określa grupę zdefiniowaną dla projektu. Może to odpowiadać zespołowi, domyślnej lub niestandardowej grupie zabezpieczeń albo grupie usługi Active Directory, która została dodana do projektu.
• [GLOBAL], aby odwołać się do grupy o zakresie kolekcji, na przykład [GLOBAL]\Project Collection Administracja istrators Użyj [GLOBAL] do odwołania się do grupy zabezpieczeń o zakresie kolekcji, takiej jak grupa kolekcji projektów Administracja istrators lub grupa systemu Windows dodana do kolekcji. Na przykład: .

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

• [Team Foundation] aby odwołać się do grupy o zakresie serwera, na przykład [Team Foundation]\Team Foundation Administracja istrators Użyj [Team Foundation] do odwołowania się do grupy o zakresie serwera, takiej jak wbudowana grupa lub grupa systemu Windows dodaną do grupy na poziomie serwera. Na przykład: .

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

• [DomainName] w celu odwołowania się do grupy o zakresie serwera, na przykład [Team Foundation]\Team Foundation Administracja istrators nazwa konta kwalifikowanego przez domenę, na przykład pokazaną w poniższym przykładzie, może służyć do odwołowania się do użytkownika domeny lub grupy. Niektóre reguły obsługują tylko grupy i nie obsługują odwoływania się do użytkowników domeny.

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

Uwaga

[Project], [GLOBAL] i [Team Foundation] są używane jako to. Nie zastępujesz ich nazwą projektu, kolekcji ani nazwy serwera.

Aby dowiedzieć się więcej o zakresach dostępnych dla projektu lub kolekcji, przejdź do strony Grupy Ustawienia> Permissions> lub Kolekcje Ustawienia> Permissions>Grupy. Filtruj 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 dowiedzieć się więcej, zobacz Zmienianie uprawnień na poziomie projektu lub Zmienianie uprawnień na poziomie kolekcji projektów.

Wszyscy użytkownicy i grupy muszą być kwalifikowani przez jeden z tych tokenów. Na przykład poniższy kod XML jest nieprawidłowy, ponieważ nie kwalifikuje określonej grupy z prawidłowym tokenem.

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

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.

Proces dziedziczenia

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.

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

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

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

4. Dla wszystkich pól z regułą warunkową When, która jest zgodna, zastosuj reguły, aby ustawić lub skopiować wartość pola.

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

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

7. Zezwól użytkownikowi na rozpoczęcie edytowania.

8. Użytkownik zmienia wartość pola, a następnie przenosi fokus z pola.

9. Przetwarzaj dowolne reguły When dla tego pola zgodnego z nową wartością.

10. Przetwórz dowolną regułę When Not dla tego pola, które jest zgodne z nową wartością.

11. Przetwarzaj dowolne reguły po zmianie dla tego pola zgodnego z nową wartością.

12. Zwracanie możliwości edytowania użytkownikowi.

13. Użytkownik zapisuje zmiany w magazynie danych.

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

Lokalny proces XML

Reguły są zwykle przetwarzane w sekwencji, w której są wymienione. Jednak w przypadku używania elementów WHEN, DEFAULT i COPY mogą mieć zastosowanie dodatkowe zachowania. 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.

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

2. Wypełnij wartości domyślne pól. W przypadku wszystkich pól zastosuj wszystkie reguły DOMYŚLNE określone poza lub REGUŁY WHEN .

3. Kopiuj wartości pól. W przypadku wszystkich pól należy użyć dowolnych reguł KOPIOWANIa , które znajdują się poza klauzulami WHEN .

4. Dla wszystkich pól z regułą WHEN , która jest zgodna, najpierw wykonaj polecenie DEFAULT , a następnie skopiuj reguły wewnątrz.

5. Dla wszystkich pól z regułą WHENNOT zgodną najpierw wykonaj domyślne, a następnie skopiuj reguły wewnątrz.

   System zawsze przetwarza reguły WHEN przed regułami WHENNOT .

6. Dla wszystkich pól, które miały zmienione wartości od kroku 1 i które zawierają reguły WHENCHANGED, najpierw wykonaj domyślne, a następnie skopiuj reguły wewnątrz.

7. Zezwól użytkownikowi na rozpoczęcie edytowania.

8. Użytkownik zmienia wartość pola, a następnie przenosi fokus z pola.

9. Zgłoś wszelkie reguły WHEN dla tego pola, które pasują do nowej wartości.

10. Zgłoś wszelkie reguły WHENNOT dla tego pola, które pasują do nowej wartości.

11. Zgłoś wszystkie reguły WHENCHANGED dla tego pola, które pasują do nowej wartości.

12. Zwracanie możliwości edytowania użytkownikowi.

13. Użytkownik zapisuje zmiany w bazie danych.

14. Dla wszystkich pól wykonaj operacje SERVERDEFAULT zdefiniowane dla pola bezpośrednio lub pośrednio w ramach reguły WHEN lub WHENNOT .

Wpisy naciśnięć klawiszy i ocena reguły

System ustawia nową wartość pola za każdym razem, gdy użytkownik wprowadza naciśnięcie klawiszy w polu za pośrednictwem formularza elementu roboczego. Oznacza to, że reguła warunkowa może wystąpić nieoczekiwanie za każdym razem, gdy zostaną spełnione warunki wstępne reguły.

W poniższym przykładzie XML system opróżni MyCorp.SubStatus, wpisując "Zatwierdzone ponownie" w polu Stan, ponieważ reguła WHEN występuje, gdy tylko użytkownik wpisze literę "e" w zatwierdzonej, nawet jeśli docelowa wartość końcowa nie jest "Zatwierdź". Z tego powodu należy dokładnie zastanowić się, kiedy używasz reguł warunkowych.

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

Powiązane artykuły

• Przykładowe scenariusze reguł
• Indeks pola elementu roboczego
• Pola i atrybuty elementu roboczego
• Zmienianie uprawnień na poziomie projektu
• Zmienianie uprawnień na poziomie kolekcji projektów
• Uprawnienia i grupy
• Proces dziedziczony
  • Dodawanie reguły niestandardowej do typu elementu roboczego
  • Stosowanie reguł do stanów przepływu pracy
• Lokalny proces XML
  • Definiowanie wartości domyślnej lub kopiowanie wartości do pola
  • Definiowanie list wyboru
  • Przypisywanie wartości i reguł opartych na warunkowych