Przykładowe scenariusze reguł niestandardowych

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Ten artykuł zawiera przykłady niestandardowych definicji reguł. Wszystkie reguły niestandardowe są definiowane dla typu elementu roboczego. Dostępne są przykłady dotyczące zarówno modeli procesów odziedziczonych, jak i lokalnych procesów XML.

Przed dodaniem reguł niestandardowych przeczytaj artykuł Reguły i ocena reguł oraz Dodaj regułę do typu elementu roboczego (proces dziedziczenia)..

Definiowanie wymaganego pola zależnego

Można określić, że pole jest wymagane tylko wtedy, gdy inne pole zawiera określoną wartość. W poniższym przykładzie, gdy klient zgłasza problem, niestandardowe pole Zgłaszane przez klienta ma wartość True, a pole Ważność staje się wymagane. Jeśli problem nie jest zgłaszany przez klienta, wartość pola Ważność nie jest wymagana .

Proces dziedziczenia

Lokalny proces XML

Należy określić instrukcję WHEN reguły dla definicji pola w FIELDS sekcji definicji typu elementu roboczego.

<FIELDS>
   ...
   <FIELD refname="MyCorp.Severity" name="Customer Severity" type="String">  
       <ALLOWEDVALUES>  
           <LISTITEM value="Blocking" />  
           <LISTITEM value="Major" />  
           <LISTITEM value="Minor" />  
       </ALLOWEDVALUES>  
       <WHEN field="MyCorp.CustomerReported" value="true">  
           <REQUIRED />  
       </WHEN>  
   </FIELD> 
   ...
</FIELDS>     

Wyczyść wartość pola zależnego

W poniższym przykładzie pokazano definiowanie reguły niestandardowej w celu wyczyszczenia wartości punktów historii po wprowadzeniu zmiany do daty rozpoczęcia.

Proces dziedziczenia

Lokalny proces XML

Należy określić instrukcję WHENCHANGED reguły dla definicji pola w FIELDS sekcji definicji typu elementu roboczego.

<FIELDS>
 ...
   <FIELD name="Story Points" refname="Microsoft.VSTS.Scheduling.StoryPoints" type="Double" reportable="measure" formula="sum">
       <HELPTEXT>The size of work estimated for implementing this user story</HELPTEXT>
       <WHENCHANGED field="Microsoft.VSTS.Scheduling.StartDate">  
           <EMPTY />  
       </WHENCHANGED>
   </FIELD>
   ...
</FIELDS>     

Ustawianie wartości pola zależnego

Poniższe przykłady ilustrują sposób mapowania wartości pola Rozmiar w zależności od wartości wybranej dla pola niestandardowego Tee-Shirt Size .

Proces dziedziczenia

Lista wyboru Rozmiar koszulek tee-shirt składa się z czterech wartości Small, Medium, Large i X-Large. Cztery reguły niestandardowe są definiowane w celu przypisania pola Rozmiar po zmianie pola Rozmiar koszulki na określoną wartość. Aby uprościć użycie, wartość domyślna rozmiaru koszulki jest mała.

Okno dialogowe Edytowanie pola dla pola Rozmiar koszulki

Reguła niestandardowa

Cztery reguły niestandardowe

Lokalny proces XML

Należy określić wartość pola Rozmiar w FIELDS sekcji definicji typu elementu roboczego. Użyjesz serii instrukcji WHEN reguł, aby utworzyć mapowanie, ustawiając wartość pola Rozmiar przy użyciu COPY value="value" reguły.

<FIELDS>
   ...
   <FIELD name="Tee-Shirt Size" refname="Fabrikam.TShirt.Size" type="String">
        <HELPTEXT>Estimate of overall size for work to be done; Small (2), Medium (6), Large (18), X-Large (30).</HELPTEXT>
        <ALLOWEDVALUES expanditems="true">
          <LISTITEM value="Large" />
          <LISTITEM value="Medium" />
          <LISTITEM value="Small" />
          <LISTITEM value="X-Large" />
        </ALLOWEDVALUES>
   </FIELD> 
   <FIELD name="Size" refname="Fabrikam.Size" type="Integer">
        <HELPTEXT>Integer estimate of overall size for work to be done; Automatically fill in based on Tee-Shirt Size. Allow any value.</HELPTEXT>
        <WHEN field="Fabrikam.TShirt.Size" value="Small">
          <COPY value="2" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="Medium">
          <COPY value="6" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="Large">
          <COPY value="18" />
        </WHEN>
        <WHEN field="Fabrikam.TShirt.Size" value="X-Large">
          <COPY value="30" />
        </WHEN>
   </FIELD>
   ...
 </FIELDS> 

Wymaganie wartości pola po zmianie stanu

W poniższym przykładzie pokazano, jak można wymagać specyfikacji pola Pozostała praca, gdy stan przepływu pracy zadania zmieni się na Aktywny.

Proces dziedziczenia

Lokalny proces XML

Gdy wartość pola Stan dla elementu roboczego jest ustawiona na Wartość Aktywna, a element roboczy jest zapisywany, wartości pól Aktywowane przez i Przypisane do są automatycznie ustawiane na nazwę bieżącego użytkownika. Ten użytkownik musi być członkiem grupy Team Foundation Server Valid Users. Wartość pola Aktywowana data jest również ustawiana automatycznie. W poniższym przykładzie przedstawiono elementy wymuszające tę regułę:

<WORKFLOW>
. . .  
    <STATE value="Active">
        <FIELDS>
            <FIELD refname="Microsoft.VSTS.Scheduling.RemainingWork">
              <REQUIRED />
            </FIELD>
        </FIELDS>
    </STATE>
. . .  
</WORKFLOW>

Wyczyść wartość pola po zamknięciu stanu

Aby zautomatyzować czyszczenie pola Praca pozostała po zamknięciu zadania, zdefiniuj regułę niestandardową zgodnie ze wskazaniem.

Proces dziedziczenia

Lokalny proces XML

<WORKFLOW>
. . .  
      <STATE value="Closed">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Scheduling.RemainingWork">
              <EMPTY />
            </FIELD>
          </FIELDS>
      </STATE>
. . .  
</WORKFLOW>

Ograniczanie tworzenia elementów roboczych według grupy

Reguła niestandardowa, która ogranicza przejście do kategorii Proponowany stan typu elementu roboczego skutecznie nie zezwala na tworzenie elementów roboczych tego typu. Stosując regułę do określonej grupy, skutecznie nie zezwalasz tej grupie na tworzenie elementów roboczych tego typu.

Proces dziedziczenia

Poniższa reguła niestandardowa ogranicza zespołowi projektu możliwość tworzenia elementów roboczych, ponieważ kategoria Proponowany stan jest mapowana na stan Nowy przepływ pracy.

Lokalny proces XML

Poniższa reguła niestandardowa ogranicza zespół Fabrikam Review Team (dla atrybutu) od tworzenia elementów roboczych, uniemożliwiając przejście do stanu Nowy przepływ pracy.

<WORKFLOW>
... 
<TRANSITION from=" " to="New"  
   for="[Project]\Developers" 
   not="[Project]\Fabrikam Review Team"  
   . . .  
</TRANSITION> 
...  
</WORKFLOW>

Ograniczanie modyfikacji elementów roboczych według grupy

W przypadku procesu dziedziczenia można uniemożliwić użytkownikom modyfikowanie elementu roboczego, ustawiając uprawnienie odmowy dla grupy na ścieżce obszaru. W przypadku lokalnego procesu XML można umieścić ograniczenia dotyczące każdego stanu przepływu pracy dla grupy, która uniemożliwia zapisywanie elementu roboczego w dowolnym stanie.

Proces dziedziczenia

Nie można zdefiniować reguły niestandardowej ograniczającej modyfikację elementów roboczych określonego typu. Ograniczenie można określić tylko według stanu. Jeśli użytkownik nie zmieni stanu, może zmodyfikować inne pola, chyba że wszystkie pola zostaną wprowadzone tylko do odczytu dla grupy.

Zamiast tego, jeśli chcesz ograniczyć grupę użytkowników do modyfikowania wybranych elementów roboczych dowolnego typu, możesz przypisać te elementy robocze do ścieżki obszaru. Zdefiniuj grupę zabezpieczeń, a następnie ustaw ograniczenia edytowania elementów roboczych dla tej grupy Ścieżka obszaru, jak pokazano na poniższej ilustracji. Aby dowiedzieć się więcej, zobacz Ustawianie uprawnień i dostępu do śledzenia pracy, Tworzenie węzłów podrzędnych i modyfikowanie elementów roboczych w ścieżce obszaru

Lokalny proces XML

Poniższa reguła niestandardowa ogranicza zespół Fabrikam Review Team (dla atrybutu) modyfikowania scenariuszy użytkowników, nie zezwalając na wszystkie stany przepływu pracy zdefiniowane dla typu elementu roboczego scenariusza użytkownika. Ponieważ żaden stan przepływu pracy nie jest prawidłowy dla określonego zespołu, członkowie tego zespołu nie mogą zapisywać elementu roboczego z wszelkimi zmianami.

<WORKFLOW>
... 
 <STATE value="New">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Active">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Resolved">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
<STATE value="Closed">  
   not="[Project]\Fabrikam Review Team"  
</STATE>  
...  
</WORKFLOW>

Ograniczanie przejść stanu

W przypadku procesów dziedziczych przejścia stanu dowolne-dowolne są definiowane automatycznie. Dzięki temu użytkownicy mogą przejść do stanu przepływu pracy od nowego do ukończonego, ale także przejść do tyłu w razie potrzeby. Podczas definiowania reguł niestandardowych w celu ograniczenia przejścia należy pamiętać, że jeśli użytkownik popełni błąd podczas aktualizowania przepływu pracy, może nie być w stanie go poprawić. Mogą na przykład zaktualizować stan, przenosząc kartę elementu roboczego do późniejszego etapu na tablicy Kanban, ale nie przenosząc jej z powrotem.

Napiwek

Rozważ ograniczenie przejścia stanu dla niektórych, ale nie wszystkich użytkowników. W ten sposób, jeśli użytkownik popełni błąd, może poprosić innego członka zespołu o zresetowanie wartości State w celu obejścia ograniczenia.

Przed zdefiniowaniem reguł przejścia stanu zapoznaj się z tematem Reguły i ocena reguł, Reguły generowane automatycznie oraz Jak są używane stany przepływu pracy i kategorie stanów w listach prac i tablicach.

Ograniczanie modyfikacji zamkniętych elementów roboczych

W zależności od procesów biznesowych możesz uniemożliwić użytkownikom kontynuowanie modyfikowania lub aktualizowania elementów roboczych, które zostały zamknięte lub ukończone. Reguły można dodawać do typów elementów roboczych, aby uniemożliwić użytkownikom ponowne otwieranie zamkniętych elementów roboczych.

Proces dziedziczenia

W przypadku procesu dziedziczonego można dodać regułę, która ogranicza przejście stanu. Na przykład poniższa reguła ogranicza przejście z zamkniętego do dwóch pozostałych stanów: Nowy i Aktywny.

Uwaga

Warunek A work item state moved from ... jest dostępny dla usługi Azure DevOps Server 2020 i nowszych wersji.

Uwaga

W zależności od określonej akcji reguły przycisk Zapisz w formularzu elementu roboczego może być wyłączony lub zostanie wyświetlony komunikat o błędzie, gdy użytkownik z ograniczeniami próbuje zmodyfikować element roboczy.

Lokalny proces XML

W przypadku wdrożeń lokalnych można dodawać reguły do typu elementu roboczego, aby zapobiec ponownemu otwieraniu po zamknięciu elementu roboczego. Na przykład następujące reguły przejścia przepływu pracy umożliwiają testerom ponowne otwarcie elementu roboczego, ale nie członków grupy Deweloperzy.

<WORKFLOW>
. . .  
<TRANSITION from="Closed" to="New"  
   for="[Project]\Testers"  
   not="[Project]\Developers" 
   . . .  
</TRANSITION 
<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers" 
   . . .  
</TRANSITION 
. . .  
</WORKFLOW>

Ukrywanie lub ograniczanie modyfikacji pola na podstawie użytkownika lub grupy

Po wybraniu Current user is a member of group... pola lub Current user is not a member of group...możesz ukryć pole, ustawić pole tylko do odczytu lub wprowadzić wymagane pole.

Na przykład poniższy warunek wskazuje, że pole Uzasadnienie jest ukryte dla członków, którzy nie należą do grupy Fabrikam Fiber\Voice.

Uwaga

Elementy robocze podlegają regułom zastosowanym do nich. Reguły warunkowe oparte na członkostwie użytkowników lub grup są buforowane dla przeglądarki internetowej. Jeśli znajdziesz się ograniczony do aktualizowania elementu roboczego, być może napotkano jedną z tych reguł. Jeśli uważasz, że napotkano problem, który nie ma zastosowania, zobacz Problemy z buforowaniem usługi IndexDB formularza elementu roboczego.

Ogranicz modyfikowanie wybranych pól na podstawie użytkownika lub grupy

Można dostosować typy elementów roboczych, aby ograniczyć, kto może modyfikować określone pole dla typu elementu roboczego.

Proces dziedziczenia

Korzystając z jednego z następujących dwóch warunków, możesz ustawić pola wyboru wymagane dla użytkownika grupy zabezpieczeń lub którzy nie są członkami grupy zabezpieczeń.

• current user is a member of a group...
• current user is not a member of a group...

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

Można na przykład ustawić pola Tytuł lub Stan tylko do odczytu dla wybranych użytkowników lub grup.

Na przykład pole Priorytet dla typu elementu roboczego Historia użytkownika staje się tylko do odczytu dla członków grupy Fabrikam Fiber\Voice. Gdy użytkownik tej grupy otworzy historię użytkownika, nie może zmienić wartości w polu Priorytet.

Lokalny proces XML

W przypadku lokalnego modelu procesów XML można dostosować typy elementów roboczych w celu obsługi tych żądań ograniczeń:

• Ogranicz, kto może tworzyć lub modyfikować element roboczy
• Ogranicz, kto może tworzyć określone typy elementów roboczych, takie jak Epiki lub Funkcje

Można na przykład ograniczyć modyfikowanie elementów roboczych, dodając regułę do typu elementu roboczego, zwykle w sekcji PRZEPŁYW PRACY .

Dostęp do obiektów śledzenia pracy można ograniczyć na jeden z dwóch sposobów:

• Ustaw regułę pola warunku, regułę pola opartą na warunku lub kombinację tych dwóch, które mają zastosowanie do grupy. Możesz ograniczyć wprowadzanie zmian do pola, określając regułę kwalifikującą się i stosując ją dla określonej grupy. Reguły warunkowe mogą zawierać elementy CANNOTLOSEVALUE, EMPTY, FROZEN, NOTSAMEAS, READONLY i REQUIRED .
• Dodając sieci WITs do grupy Ukryte kategorie, można uniemożliwić tworzenie ich przez większość współautorów projektu. Możesz utworzyć hiperlink do szablonu , który otwiera formularz elementu roboczego i udostępnić ten link tym członkom zespołu, którzy mają je utworzyć.

Powiązane artykuły

• Stosowanie reguł do stanów przepływu pracy (proces dziedziczenia)
• Reguły i ocena reguł