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 Reguły i ocena reguł oraz Jak dodać 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łoszone przez klienta ma wartość True, a pole Ważność staje się wymagane. Jeśli problem nie jest zgłaszany przez klienta, wartość pola Dotkliwość nie jest wymagana.
Wyczyść wartość pola zależnego
W poniższym przykładzie pokazano, jak zdefiniować regułę niestandardową do wyczyszczenia wartości dla Punktów historii po dokonaniu zmiany w Dacie rozpoczęcia.
Ustawianie wartości pola zależnego
Poniższe przykłady ilustrują sposób mapowania wartości pola Size w zależności od wartości wybranej dla pola niestandardowego Rozmiar koszulki.
Lista rozwijana Rozmiar T-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 edytowania pola Rozmiar koszulki
Reguła niestandardowa
Cztery reguły niestandardowe
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.
Wyczyść wartość pola po zamknięciu stanu
Aby zautomatyzować czyszczenie pola Praca pozostała po zamknięciu zadania, zdefiniuj regułę niestandardową zgodnie ze wskazaniem.
Ogranicz tworzenie elementów roboczych przez grupę
Reguła niestandardowa, która ogranicza przejście do kategorii stanu Proponowany dla typu elementu roboczego, skutecznie uniemożliwia 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.
Poniższa reguła niestandardowa ogranicza zespół projektowy w tworzeniu elementów roboczych, ponieważ kategoria stanu Proponowany jest mapowana na stan Nowy w przepływie pracy.
Ograniczenie modyfikacji elementów roboczych przez grupę
W przypadku procesu dziedziczenia można uniemożliwić użytkownikom modyfikowanie elementu roboczego, ustawiając odmowę uprawnień dla grupy w ścieżce dostępu do 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.
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 Ścieżki obszaru dla tej grupy, jak pokazano na poniższym obrazku. Więcej szczegółów znajdziesz w Ustawianie uprawnień i dostępu do śledzenia pracy, Tworzenie węzłów podrzędnych oraz modyfikacja elementów roboczych w ścieżce obszaru
Ograniczanie przejść stanu
W przypadku procesów dziedziczonych przejścia stanu z dowolnego do dowolnego są definiowane automatycznie. Dzięki temu użytkownicy mogą zaawansować stan przepływu pracy od nowego do ukończonego, ale także cofnąć się 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, 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 Reguły i ocena reguł, reguły generowane automatycznie oraz Jak stany przepływu pracy i kategorie stanów są używane 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.
W przypadku procesu dziedziczonego można dodać regułę, która ogranicza zmianę stanu. Na przykład poniższa reguła ogranicza przechodzenie ze stanu zamkniętego do dwóch pozostałych stanów: Nowego i Aktywnego.
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.
Ukrywanie lub ograniczanie modyfikacji pola na podstawie użytkownika lub grupy
Po wybraniu Current user is a member of group... lub Current user is not a member of group... możesz ukryć pole, oznaczyć pole jako tylko do odczytu lub ustawić pole jako wymagane.
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 nie możesz zaktualizować elementu roboczego, mogłeś napotkać jedną z tych reguł. Jeśli uważasz, że napotkałeś problem, który Cię nie dotyczy, zapoznaj się z problemami z buforowaniem formularza elementu roboczego w IndexDB.
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.
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, które mogą wystąpić przy ocenie reguł, należy określać grupy zabezpieczeń usługi Azure DevOps, a nie grupy zabezpieczeń Microsoft Entra ID lub Active Directory. Aby uzyskać więcej informacji, zobacz Domyślne reguły i silnik 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 user story stanie się dostępne 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.
