규칙 및 규칙 평가

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

규칙은 값 할당을 작업 항목 필드로 설정하거나 제한하는 데 사용됩니다. 프로세스 또는 프로젝트에 대해 정의된 사용자 지정 규칙과 자동 생성 규칙의 두 가지 주요 규칙 유형이 있습니다. 자동 생성된 규칙은 표준 방식으로 작동해야 하는 영역에 대한 사용자 지정 규칙을 추가할 필요성을 최소화합니다.

비즈니스 사용 사례를 지원하기 위해 사용자 지정 규칙을 정의합니다. 필드의 데이터 유형에 따라 해당 필드에 입력할 수 있는 데이터에 대한 다양한 제한을 설정할 수 있습니다. 선택 목록(드롭다운 메뉴)의 값을 지정하거나, 기본값을 설정하거나, 항목을 지우거나, 변경을 제한할 수 있습니다. 조건부 규칙을 사용하면 서로 다른 필드 값 간의 종속성에 따라 필드에 규칙을 적용할 수 있습니다. 또한 필드를 수정할 수 있는 사람을 제한하거나, 그룹에 적용되도록 규칙의 범위를 지정할 수 있습니다.

다음을 이해하려면 이 문서를 읽어보세요.

• 시스템에서 자동 생성된 규칙을 적용하는 방법
• 시스템 필드의 사용자 지정 규칙 정의에 적용되는 제한 사항
• 적용할 수 있는 다양한 유형의 사용자 지정 규칙
• 규칙 평가 방법
• 상속 프로세스에 대해 정의된 규칙과 온-프레미스 XML 프로세스 간의 차이점
• 정의하는 사용자 지정 규칙 수를 최소화해야 하는 이유

사용자 지정 규칙을 정의하기 전에 비즈니스 요구 사항에 맞게 Azure Boards를 사용자 지정하는 방법에 대한 광범위한 이해를 얻기 위해 Azure Boards 구성 및 사용자 지정을 읽어보세요.

팁

WIT에 대해 정의하는 규칙 수를 최소화합니다. WIT에 대해 여러 규칙을 만들 수 있지만 추가 규칙은 사용자가 작업 항목을 추가하고 수정할 때 성능에 부정적인 영향을 미칠 수 있습니다. 사용자가 작업 항목을 저장할 때 시스템은 해당 작업 항목 형식에 대한 필드와 연결된 모든 규칙의 유효성을 검사합니다. 특정 조건에서 규칙 유효성 검사 식은 SQL이 평가하기에는 너무 복잡합니다.

자동 생성된 규칙

자동 생성된 규칙은 표준 방식으로 작동해야 하는 영역에 대한 사용자 지정 규칙을 추가할 필요성을 최소화합니다.

상태 전환 규칙

상속된 프로세스는 워크플로에 추가된 각 사용자 지정 작업 항목 유형 및 사용자 지정 상태에 대해 모든 상태 전환 규칙의 전체 집합을 동적으로 생성합니다. 모든 상태에서 모든 상태로의 전환은 유효합니다.

온-프레미스 XML 프로세스의 경우 작업 항목 형식 정의 섹션 내에서 WORKFLOW 유효한 전환을 지정해야 합니다.

상태 전환 및 날짜/날짜 필드 규칙

By/Date 필드는 만든 날짜/ 날짜, 활성화 기준/날짜, 해결 날짜별, 종료 날짜/날짜에 해당합니다.

상속된 프로세스의 경우 작업 항목을 한 상태에서 다른 상태로 전환하면 이러한 필드가 자동으로 설정되거나 지워집니다. 변경된 날짜/날짜 필드는 각 작업 항목 저장으로 업데이트되고 상태 전환과 관련이 없으므로 포함되지 않습니다.

이러한 필드를 제어하는 기본 규칙 및 동작은 다음과 같습니다.

1. 닫힌 상태는 항상 완료된 상태 범주에 포함됩니다.
2. 완료된 상태 범주는 구성할 수 없으며 하나의 상태와만 연결됩니다.
3. 이 닫힌 상태는 항상 Agile 및 CMMI 프로세스에 대해 닫 히고 스크럼 및 기본 프로세스에 대해 항상 완료 됩니다.
4. 이러한 규칙의 자동 생성은 지역화된 상태 이름을 규칙 조건에 포함하므로 로캘의 영향을 받습니다. 시스템은 다른 로캘에 대해 서로 다른 규칙을 생성합니다.
5. 이러한 필드에 대해 자동으로 생성된 규칙은 이러한 필드를 포함하는 작업 항목 유형에 대해서만 지정됩니다. 작업 항목 유형에 이러한 필드 중 하나 이상을 포함하지 않을 수 있습니다.
6. 이러한 규칙은 작업 항목 유형에 사용자 지정 상태가 있거나 작업 항목 유형이 사용자 지정 작업 항목 유형인 경우에 필요합니다.
7. 이러한 규칙은 상속된 프로세스에만 적용됩니다. 호스트된 XML 또는 온-프레미스 XML 프로세스에 대해 생성되지 않습니다.

워크플로 상태는 보드의 워크플로를 지원하기 위해 상태 범주와 연결됩니다. 자세한 내용은 백로그 및 보드에서 워크플로 상태 및 상태 범주를 사용하는 방법을 참조 하세요.

상태 변경 날짜 필드 규칙

이러한 규칙은 특정 상태에 종속되지 않으므로 기술적으로 닫힌 날짜/마감 날짜 규칙보다 훨씬 간단합니다. 모든 작업 항목 유형에 대해 동일한 규칙이 항상 작동합니다. 일부 OOB 작업 항목 형식에는 상태 변경 날짜 필드가 없기 때문에 자동으로 생성되어야 하므로 사용자가 이 필드를 사용자 지정 작업 항목 형식에 추가할 때 이러한 규칙도 자동으로 생성되어야 합니다. 닫힌 날짜/마감 날짜 규칙에 대한 동일한 원칙도 여기에 적용됩니다.

사용자 지정 규칙

모든 사용자 지정 규칙은 선택 사항입니다. 상속된 프로세스의 경우 조건과 작업으로 구성된 규칙을 지정합니다. 온-프레미스 XML 프로세스의 경우 필드 또는 워크플로 내에서 규칙을 지정합니다.

두 프로세스 사이에는 일대일 매핑이 없습니다. 경우에 따라 XML 요소 규칙은 규칙으로 정의되지 않고 상속된 프로세스에 대한 편집 필드 대화 상자 내에서 정의됩니다. 와 MATCHNOTSAMEAS같은 FROZEN다른 XML 요소는 상속된 프로세스에서 지원되지 않습니다.

다음을 참고하십시오.

• 규칙은 양식과 상호 작용할 때뿐만 아니라 다른 도구를 통해 상호 작용할 때도 항상 적용됩니다. 예를 들어 필드를 읽기 전용으로 설정하면 작업 항목 양식뿐만 아니라 API 및 Excel Azure DevOps Server 추가 기능을 통해서도 규칙이 적용됩니다.
• 상속된 프로세스 항목은 전체 규칙을 만들기 위한 조건 및 작업을 지정합니다. XML 요소는 이러한 차이를 만들지 않습니다.
• 필드 규칙은 다른 두 필드의 합계인 값을 할당하거나 다른 수학 계산을 수행하는 것을 지원하지 않습니다. 그러나 TFS Aggregator(웹 서비스) Marketplace 확장을 통해 요구 사항에 맞는 솔루션을 찾을 수 있습니다. 작업 및 기타 필드 롤업도 참조하세요.
• Marketplace 확장을 사용하여 필드에 사용자 지정 규칙을 적용하는 추가 솔루션(예: 작업 항목 양식 컨트롤 라이브러리 확장)을 찾을 수 있습니다.

규칙 컴퍼지션

상속 프로세스

상속된 프로세스의 경우 각 규칙은 조건 및 작업이라는 두 부분으로 구성됩니다. 조건은 규칙을 적용하기 위해 충족해야 하는 상황을 정의합니다. 작업은 수행할 작업을 정의합니다. 대부분의 규칙에서는 규칙당 최대 2개의 조건과 10개의 작업을 지정할 수 있습니다. 모든 사용자 지정 규칙을 실행하려면 모든 조건을 충족해야 합니다.

예를 들어 상태 및 다른 필드에 할당된 값에 따라 필요한 필드를 만들 수 있습니다. 예시:

   (Condition) When a work item State is활동적인
   (Condition) And when the value of값 영역 = 사업
   (Action) Then make required스토리 포인트

참고 항목

현재 상태 전환 규칙에는 하나의 조건만 지원됩니다. 상태에 따라 규칙을 적용하는 경우 워크플로 상태에 규칙 적용을 참조 하세요.

다음 표에는 선택한 조건과 함께 사용할 수 있는 작업이 요약되어 있습니다.

Condition

지원되는 작업

필드 값을 설정하거나 필수 또는 읽기 전용으로 설정

상태에 따라 전환 제한

사용자 또는 그룹 멤버 자격에 따라 필드 특성을 설정하거나 상태 전환을 제한합니다.

온-프레미스 XML 프로세스

온-프레미스 XML 프로세스는 XML 요소를 사용하는 규칙을 정의합니다. 이러한 모든 규칙 요소는 작업 항목 형식 정의의 FIELD 정의 내에서 정의할 수 있습니다. 또한 요소를 제외하고 워크플로 전환 중 또는 (전역 워크플로) 요소 내 FIELD 의 HELPTEXT 자식 요소로 적용할 규칙을 지정할 수 있습니다.

참고 항목

이 VALIDUSER 요소는 TFS 2018 이상 버전에서 지원되지 않습니다.

필드 규칙을 적용할 위치

작업 항목의 수명 동안 필드에 규칙을 적용하려면 섹션 내에서 FIELD 규칙을 지정합니다. 예를 들어 버그가 닫히기 전까지는 새 버그와 활성 상태인 버그에 필요한 필드가 필요합니다. 그렇지 않은 경우 상태, 이유 또는 전환의 변경 내용에 따라 적용하려면 섹션 내에서 WORKFLOW 지정합니다.

상태 (System.State) 및 이유 (System.Reason) 필드는 섹션 내에서 WORKFLOW 정의됩니다. 상태 변경, 이유 선택 또는 특정 전환 중에 필드에 적용할 대부분의 필드 규칙을 지정할 수 있습니다. 자세한 내용은 작업 항목 유형에 대한 워크플로 변경을 참조 하세요.

그렇지 않은 경우 상태 변경 중에만 평가할 규칙을 지정합니다. 이러한 규칙은 , REASON또는 TRANSITION 요소 아래의 WORKFLOW STATE섹션 내에 정의됩니다. 을 제외한 HELPTEXT모든 규칙은 (Workflow) 요소 내에 FIELD 적용할 수 있습니다.

필드 규칙은 가산적입니다. 즉, 규칙 엔진에서 모두 평가할 동일한 필드에 대해 4개의 규칙 집합을 지정할 수 있습니다.

• 작업 항목 유형별 규칙은 상태 모델에서 작업 항목의 위치에 관계없이 적용됩니다. 예를 들어 <REQUIRED \> 규칙은 다음 검사를 수행합니다.

  "MyField Value" != NULL

• 상태별 규칙은 특정 상태일 때 작업 항목 인스턴스로 범위가 지정됩니다. 다음 조건이 true이면 상태별 규칙이 적용됩니다.

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

• 특정 전환에 대해 지정하는 전환별 규칙은 특정 전환을 진행 중인 작업 항목으로 범위가 지정됩니다. 이러한 규칙은 다음 조건이 충족될 때 적용됩니다.

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

• 특정 이유로 지정하는 이유별 규칙은 특정 전환의 특정 이유로 범위가 지정됩니다. 다음 조건이 충족되면 처리됩니다.

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

다음 예제에서는 작업 항목이 활성 상태일 때 고객 심각도 필드의 수정을 제한합니다.

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

너무 많은 규칙이 정의되면 어떻게 되나요?

프로젝트별로 단일 SQL 식이 정의되어 작업 항목이 만들어지거나 업데이트할 때마다 유효성을 검사합니다. 이 식은 프로젝트에 대해 정의된 모든 작업 항목 형식에 대해 지정하는 규칙의 수에 따라 증가합니다. 필드에 대해 지정된 각 동작 한정자는 하위 식 수가 증가합니다. 중첩된 규칙, 전환에만 적용되거나 다른 필드의 값에 조건부로 지정된 규칙으로 인해 문에 IF 더 많은 조건이 추가됩니다. 식이 특정 크기 또는 복잡성에 도달하면 SQL은 더 이상 계산할 수 없으며 오류를 생성합니다. 일부 WIT를 제거하거나 일부 규칙을 제거하면 오류가 해결될 수 있습니다.

선택 목록(드롭다운 메뉴)의 값을 지정하거나, 기본값을 설정하거나, 항목을 지우거나, 변경을 제한할 수 있습니다. 조건부 규칙을 사용하면 서로 다른 필드 값 간의 종속성에 따라 필드에 규칙을 적용할 수 있습니다. 또한 필드를 수정할 수 있는 사람을 제한하거나, 그룹에 적용되도록 규칙의 범위를 지정할 수 있습니다.

작업 항목 규칙은 단일 컬렉션으로 존재하지 않습니다. 규칙은 실제로 동적으로 생성되고 다른 데이터 원본에서 병합됩니다. 병합 논리는 동일한 규칙을 통합하는 간단한 논리이지만 충돌하는 규칙을 트리밍하지는 않습니다.

규칙 무시

일반적으로 모든 작업 항목은 사용자가 작업 항목을 수정할 때 규칙 엔진에서 유효성을 검사합니다. 그러나 특정 시나리오를 지원하기 위해 작업 항목 업데이트 프로젝트 수준 권한에 대한 바이패스 규칙을 할당한 사용자는 규칙을 평가하지 않고 작업 항목을 저장할 수 있습니다.

규칙은 두 가지 방법 중 하나로 무시할 수 있습니다. 첫 번째는 작업 항목을 통해 REST API를 업데이트하고 매개 변수를 bypassRules .로 설정하는 것입니다true. 두 번째는 바이패스룰즈 모드(초기화)로 초기화하여 클라이언트 개체 모델을 사용하는 것입니다 WorkItemStore WorkItemStoreFlags.BypassRules.

시스템 필드 및 사용자 지정 규칙

시스템 필드에는 System이 있습니다.이름 참조 이름(예: System.Title 및 System.State).

다음 시스템 필드에는 영역 ID, 변경된 날짜, 만든 날짜, 만든 사람, 상태 및 이유 값이 필요합니다.

규칙 엔진은 다음과 같은 경우를 제외하고 설정 조건 또는 작업을 시스템 필드로 제한합니다.

• 상태 및 이유 필드를 읽기 전용으로 만들 수 있습니다.
• 제목, 할당 대상, 설명 및 변경된 기준 필드에 대부분의 규칙을 적용할 수 있습니다.

상속 프로세스에 대한 규칙 사용자 인터페이스의 드롭다운 메뉴에 나열된 필드가 표시되지 않는 것이 바로 이 이유입니다. 예를 들어 조건에 따라 영역 경로(System.AreaPath)를 읽기 전용으로 설정하려고 하면 영역 경로 필드를 선택할 수 없습니다. 시스템 필드를 지정할 수 있더라도 규칙 엔진에서 규칙을 저장하지 못하도록 제한할 수 있습니다.

기본 및 복사 규칙

기본 및 복사 규칙은 작업 항목 필드의 값을 수정합니다. 기본값 지정, 필드 지우기, 필드 정의 요구 등과 같은 런타임 동작 및 제약 조건을 정의합니다.

사용자 또는 그룹 멤버 자격 규칙 제한에 설명된 대로 현재 사용자의 그룹 멤버 자격에 따라 이러한 규칙의 적용을 제한할 수 있습니다.

상속 프로세스

이러한 규칙 동작의 대부분은 모든 조건의 선택과 함께 적용할 수 있습니다.

상속된 프로세스 작업

설명

Copy the value from...

현재 필드에 복사할 값이 포함된 다른 필드를 지정합니다.

Clear the value of...

포함된 모든 값의 필드를 지웁니다.

Use the current time to set the value of ...

현재 사용자의 시간 설정에 따라 필드의 시간을 설정합니다.

온-프레미스 XML 프로세스

이러한 규칙은 기본값 설정, 한 필드에서 다른 필드로 값 복사 또는 지정된 패턴과 일치하도록 필드 값 적용을 지원합니다. 구문 구조 및 예제는 기본값 정의를 참조 하거나 필드에 값을 복사합니다.

XML 요소

사용법

COPY

사용자가 작업 항목을 만들거나 수정할 때 지정된 값을 필드에 복사합니다.

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

DEFAULT

사용자가 작업 항목을 만들거나 수정할 때 비어 있는 필드의 값을 지정합니다. 필드에 이미 값 DEFAULT 이 있으면 규칙이 무시됩니다. 기본 규칙은 필드 값이 Is 현재 비어 있는 경우에만 실행됩니다. 지원되는 값에는 현재 시간(from = "clock"), 현재 사용자(from = "currentuser"), 리터럴 값(from = "value" value = "literal") 또는 다른 필드의 값(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

필드 값을 정의할 서버 클록 또는 현재 사용자를 지정합니다.

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

제약 조건 규칙

제약 조건 규칙은 필드 값을 변경하는 것을 제한합니다. 작업 항목의 유효한 상태를 정의합니다. 각 제약 조건은 단일 필드에서 작동합니다. 제약 조건은 작업 항목 저장의 서버에서 평가되며 제약 조건을 위반하면 저장 작업이 거부됩니다.

사용자 또는 그룹 멤버 자격 규칙 제한에 설명된 대로 현재 사용자의 그룹 멤버 자격에 따라 이러한 규칙의 적용을 제한할 수 있습니다.

상속 프로세스

이러한 규칙 동작의 대부분은 모든 조건의 선택과 함께 적용할 수 있습니다.

상속된 프로세스 작업

설명

Hide the field...
그룹 멤버 자격 조건을 선택한 경우에만 사용할 수 있습니다.

작업 항목 양식에 필드를 표시하지 않도록 지정하여 현재 사용자가 필드 값을 변경할 수 있는 기능을 기본적으로 제거합니다.

Make read-only

필드가 전혀 수정되지 않도록 합니다. 특정 조건에서 이 규칙을 적용할 수 있습니다. 예를 들어 작업 항목을 닫은 후에는 보고 목적으로 데이터를 보존하기 위해 필드를 읽기 전용으로 만들려고 합니다.
필드 기본값을 읽기 전용으로 지정하려면 [편집] 필드 대화 상자의 [옵션] 탭에서 지정합니다 .

Make required

사용자가 필드 값을 지정해야 합니다. 사용자는 모든 필수 필드에 값을 할당할 때까지 작업 항목을 저장할 수 없습니다.
필드 기본값을 지정하려면 [편집] 필드 대화 상자의 [옵션] 탭에서 지정합니다.

온-프레미스 XML 프로세스

XML 요소

사용법

ALLOWEDVALUES

필드에 허용되는 값 목록을 정의합니다. 허용되는 값은 작업 항목 양식의 필드 목록과 쿼리 작성기에서 선택할 수 있는 값입니다. 이러한 값 중 하나를 선택해야 합니다.

CANNOTLOSEVALUE

값이 지정되면 사용자가 값 필드를 지울 수 없습니다. 이 요소는 현재 필드 값을 유지하며 지우거나 비워 둘 수 없습니다.

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

FROZEN

값이 들어 있으면 사용자가 필드 값을 변경할 수 없습니다. 사용자가 작업 항목을 해당 필드에 값으로 저장하면 더 이상 값을 수정할 수 없습니다. 변경 내용을 커밋한 후에는 고정 필드를 비어 있지 않은 값으로 변경할 수 없습니다. 그러나 필드를 수동으로 지우고 작업 항목을 저장한 다음 다른 값을 지정할 수 있습니다.

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

EMPTY

포함된 값의 필드를 지워 사용자가 작업 항목을 저장할 때 필드를 읽기 전용으로 만듭니다. 와 함께 사용하면 EMPTY 안 됩니다 READONLY.
EMPTY는 주로 상태 전환 중에 항목이 전환되는 상태에 적용되는 필드를 지우는 데 사용됩니다.

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

MATCH

문자열 필드에 적용된 항목이 지정된 문자 또는 숫자 패턴을 따르 도록 합니다. 여러 MATCH 요소를 정의하는 경우 지정한 패턴과 일치하는 값이 유효한 것으로 간주됩니다. 하나 이상의 요소가 성공하면 필드에 유효한 값이 있습니다.

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

NOTSAMEAS

필드가 다른 필드에 할당된 값과 동일한 값을 할당하지 못하도록 합니다.

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

PROHIBITEDVALUES

필드에 대해 금지된 값 목록을 정의합니다. 특정 필드에 여러 ALLOWEDVALUES 및/또는 PROHIBITEDVALUES 규칙이 적용되는 경우 유효한 값의 전체 목록은 허용되는 모든 값 목록의 교집합이거나, 허용되는 값 목록이 없는 경우 모든 항목( 빼기, 즉 모든 금지 값 목록의 합집합)입니다.

READONLY

필드가 전혀 수정되지 않도록 합니다. 특정 조건에서 이 규칙을 적용할 수 있습니다. 예를 들어 작업 항목을 닫은 후에는 보고 목적으로 데이터를 보존하기 위해 필드를 읽기 전용으로 만들려고 합니다.
필드를 읽기 전용으로 만들기 때문에 EMPTY 요소와 함께 EMPTY 사용하지 READONLY 마세요. 이러한 요소를 결합하면 일관되지 않은 결과가 발생할 수 있습니다.
또한 요소 ReadOnly 특성을 사용하여 Control 작업 항목 양식에서 필드를 읽기 전용으로 표시할 수 있습니다. 이 필드는 다른 클라이언트에서 작성할 수 있지만 작업 항목 양식을 통해 작성할 수는 없습니다.

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

REQUIRED

사용자가 필드 값을 지정해야 합니다. 사용자는 모든 필수 필드에 값을 할당할 때까지 작업 항목을 저장할 수 없습니다.

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

목록 선택

선택 목록은 사용자가 문자열 또는 정수 필드에 대해 선택할 수 있거나 선택할 수 없는 값을 정의합니다. 선택 목록에 정의된 값은 작업 항목 양식 및 쿼리 편집기에서 나타납니다.

상속 프로세스

상속된 프로세스의 경우 선택 목록은 편집 필드 대화 상자를 통해 정의됩니다.

필드 편집 대화 상자

설명

선택 목록 필드의 정의 탭

필드에 허용되는 값 목록을 정의합니다. 허용되는 값은 작업 항목 양식의 필드 목록과 쿼리 작성기에서 선택할 수 있는 값입니다. 이러한 값 중 하나를 선택해야 합니다.

사용자가 자신의 항목을 지정할 수 있도록 옵션 탭 내에서 사용자가 자신의 값을 입력하도록 허용 확인란을 선택합니다.

필드의 제안된 값 목록을 정의합니다. 제안된 값은 작업 항목 양식의 필드 목록과 쿼리 작성기에서 선택할 수 있는 값입니다. 목록에 있는 값에 다른 값을 추가로 입력할 수 있습니다.

온-프레미스 XML 프로세스

다음 표에 나열된 XML 요소를 사용하여 선택 목록을 정의합니다. 구문 구조 및 예제는 선택 목록 정의를 참조 하세요.

목록을 결합하고 목록을 확장하거나 계약할 수 있습니다. 또한 사용자 또는 그룹 멤버 자격 규칙 제한에 설명된 대로 현재 사용자의 그룹 멤버 자격에 따라 이러한 규칙의 적용을 제한할 수 있습니다.

XML 요소

설명

ALLOWEDVALUES

필드에 허용되는 값 목록을 정의합니다. 허용되는 값은 작업 항목 양식의 필드 목록과 쿼리 작성기에서 선택할 수 있는 값입니다. 이러한 값 중 하나를 선택해야 합니다.

ALLOWEXISTINGVALUE

기존 값을 허용하는 필드를 정의합니다. 이 요소를 사용하면 유효하지 않더라도 이미 존재하는 필드 값을 사용할 수 있습니다. 모든 새 필드 값은 유효해야 합니다.

PROHIBITEDVALUES

필드에 대해 금지된 값 목록을 정의합니다.

SUGGESTEDVALUES

필드의 제안된 값 목록을 정의합니다. 제안된 값은 작업 항목 양식의 필드 목록과 쿼리 작성기에서 선택할 수 있는 값입니다. 목록에 있는 값에 다른 값을 추가로 입력할 수 있습니다.

ID 필드 및 유효성 검사 오류

멤버가 팀을 떠나 프로젝트 참가자로 더 이상 등록되지 않을 때 발생하는 유효성 검사 오류를 방지하려면 할당 대상 필드에 ALLOWEXISTINGVALUE 요소를 포함합니다.

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

조건부 필드 값 또는 변경 내용

조건부 규칙은 특정 값과 같거나 같지 않은 필드 값에 따라 작업을 지정하거나 특정 필드 값이 변경되었거나 변경되지 않은 경우 작업을 지정합니다. 일반적으로 조건부 규칙은 먼저 무조건적인 규칙에 적용됩니다. 여러 조건부 규칙이 true로 평가되면 실행 순서는 When, WhenNot, WhenChanged, WhenNotChanged입니다.

상속 프로세스

필드당 여러 조건부 규칙을 지정할 수 있습니다. 그러나 조건부 규칙당 하나의 운전 필드만 지정할 수 있습니다.

상속된 조건

설명

The value of ... (equals) [시기]

다른 필드에 특정 값이 있는 경우 현재 필드에 적용할 하나 이상의 규칙을 지정합니다.

A change was made to the value of ... [WhenChanged]

특정 필드의 값이 변경되면 하나 이상의 규칙을 현재 필드에 적용합니다.

The value of ... (not equals) [WhenNot]

다른 필드에 특정 값이 없는 경우 하나 이상의 규칙을 현재 필드에 적용합니다.

No change was made to the value of ... [WhenNotChanged]

특정 필드의 값이 변경되지 않으면 하나 이상의 규칙을 현재 필드에 적용합니다.

상속된 작업

설명

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

특정 필드에 대해 수행할 작업을 지정합니다.

온-프레미스 XML 프로세스

다음 XML 요소는 다른 규칙이 평가되는 경우에 대한 조건을 설정하는 데 사용됩니다. 필드당 여러 조건부 규칙을 지정할 수 있습니다. 그러나 조건부 규칙당 하나의 운전 필드만 지정할 수 있습니다. 조건부 규칙을 중첩할 수 없습니다. 각 프로세스 모델에 대해 지원되는 작업에는 다음 표에 나열된 작업이 포함됩니다.

구문 구조 및 예제는 조건부 기반 값 및 규칙 할당을 참조하세요. 사용자 또는 그룹 멤버 자격 규칙 제한에 설명된 대로 현재 사용자의 그룹 멤버 자격에 따라 이러한 규칙의 적용을 제한할 수 있습니다.

XML 요소

사용법

WHEN

다른 필드에 특정 값이 있는 경우 현재 필드에 적용할 하나 이상의 규칙을 지정합니다. 부모 요소는 현재 필드를 정의합니다.
지정된 필드에 지정된 값이 있으면 이 요소의 규칙이 현재 필드에 적용됩니다.

WHENCHANGED

현재 필드에 하나 이상의 규칙을 적용할 조건을 지정합니다. 이 규칙은 수정 버전에서 다른 필드의 값이 작업 항목으로 변경될 때 현재 필드에 적용됩니다. 부모 요소는 현재 필드를 정의합니다.

WHENNOT

현재 필드에 하나 이상의 규칙을 적용할 조건을 지정합니다. 규칙은 다른 필드의 값이 변경되면 현재 필드에 적용됩니다. 부모 요소는 현재 필드를 정의합니다.
지정된 필드에 지정된 값이 없으면 이 요소의 규칙이 현재 필드에 적용됩니다.

WHENNOTCHANGED

현재 필드에 하나 이상의 규칙을 적용할 조건을 지정합니다. 이 규칙은 수정 버전에서 다른 필드의 값이 작업 항목으로 변경되지 않는 경우 현재 필드에 적용됩니다. 부모 요소는 현재 필드를 정의합니다.

사용자 또는 그룹 멤버 자격 규칙 제한

현재 사용자의 멤버 자격에 따라 규칙의 적용을 제한할 수 있습니다. 후자를 지정할 수는 있지만 단일 사용자가 아닌 Azure DevOps 보안 그룹으로 규칙 범위를 지정하는 것이 좋습니다. 규칙이 여러 그룹으로 범위가 지정되도록 하려면 사용하려는 그룹 집합을 포함하는 부모 Azure DevOps 그룹을 만들어야 합니다.

프로세스 구현

팁

발생할 수 있는 규칙 평가 문제를 방지하려면 Microsoft Entra ID 또는 Active Directory 보안 그룹이 아닌 Azure DevOps 보안 그룹을 지정합니다. 자세한 내용은 기본 규칙 및 규칙 엔진을 참조하세요.

상속 프로세스

다음 표에 표시된 것처럼 현재 사용자의 멤버 자격에 따라 규칙을 제한하려면 상속된 프로세스에 대해 두 가지 조건 중 하나를 지정합니다. 이러한 규칙은 Azure DevOps 2020 이상 버전에 대해 활성화됩니다.

적용 대상:

규칙

조건

Current user is a member of group ...
Current user is not member of group ...

작업

Hide the field ...
Make read-only ...
Make required ...
Restrict the transition to state ...

온-프레미스 XML 프로세스

현재 사용자의 멤버 자격에 따라 규칙을 제한하려면 규칙 요소에서 for 특성 또는 not 특성을 지정합니다. 규칙의 범위를 지정합니다. 규칙이 여러 그룹으로 범위가 지정되도록 하려면 사용하려는 그룹 집합을 포함하는 부모 Azure DevOps 그룹을 만들어야 합니다.

시나리오

사용법

지정된 그룹에만 필요한 필드 만들기

그룹에 규칙을 적용하는 데 사용합니다 for . 이 예제에서는 Junior Analysts 그룹의 모든 사용자가 두 번째 승인자 필드를 완료해야 합니다.

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

사용자 그룹으로 필드 수정 제한

규칙에서 그룹을 제외하는 데 사용합니다 not . 이 예제에서는 심사 위원회 그룹의 사용자를 제외한 모든 사용자에 대해 심사 설명 필드를 읽기 전용으로 정의합니다.

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

일부 사용자에게 필요하고 다른 사용자에게는 필요하지 않은 필드 만들기

규칙을 조합 for not 하여 다른 사용자에게는 적용되지 않고 일부 규칙을 동시에 적용합니다. 이 예제에서는 심각도를 프로젝트 구성원 그룹의 사용자에게 필요한 필드로 정의하지만 Project Admins 그룹의 사용자는 정의하지 않습니다. 사용자가 두 그룹에 for 모두 있는 경우 문이 적용되고 필드가 필요합니다.

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

토큰을 사용하여 사용자 또는 그룹 참조

ID 또는 사람 선택기 필드는 사용자와 그룹 모두를 참조하는 값을 수락할 수 있습니다. 규칙을 그룹으로 제한하면 그룹의 도메인 또는 범위를 나타냅니다. 일부 값의 경우 토큰을 사용할 수 있습니다.

상속 프로세스

토큰의 예는 다음과 같습니다.

• [ProjectName](예: [Fabrikam], [FabrikamFiber], [MyProject]
• [OrganizationName](예: [fabrikam], [myorganization]
• [CollectionName](예: [fabrikam], [myorganization]

프로젝트 또는 조직에 사용할 수 있는 범위에 대해 알아보려면 프로젝트 설정 사용 권한 그룹 또는 조직 설정>>사용 권한>그룹 페이지로 이동하여 필요에 따라 목록을 필터링할 수 있습니다.> 예를 들어 다음 이미지는 Azure DevOps를 기반으로 필터링된 목록에 대한 처음 네 개의 항목을 보여 줍니다. 자세한 내용은 프로젝트 수준 권한 변경 또는 프로젝트 컬렉션 수준 권한 변경을 참조하세요.

온-프레미스 XML 프로세스

토큰의 예는 다음과 같습니다.

• [Project]\Contributors, [Project]\Fabrikam Team, [Project]\Project Approvers와 같은 [Project] 토큰은 프로젝트에 대해 정의된 그룹을 지정합니다. 이는 팀, 기본 또는 사용자 지정 보안 그룹 또는 프로젝트에 추가된 Active Directory 그룹에 해당할 수 있습니다.
• [GLOBAL]과 같이 컬렉션 범위 그룹을 참조하려면 [GLOBAL]\Project Collection Administrators는 [GLOBAL]을 사용하여 컬렉션 범위 보안 그룹(예: 프로젝트 컬렉션 관리자 그룹 또는 컬렉션에 추가된 Windows 그룹)을 참조합니다. 예:

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

• [Team Foundation] 서버 범위 그룹을 참조하려면[Team Foundation]\Team Foundation Administrators [Team Foundation]을 사용하여 서버 수준 그룹에 추가하는 기본 제공 그룹 또는 Windows 그룹과 같은 서버 범위 그룹을 참조합니다. 예:

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

• [DomainName] 은 서버 범위 그룹(예: [Team Foundation]\Team Foundation Administrators 도메인 정규화된 계정 이름)을 참조하는 데 사용할 수 있습니다(예: 다음 예제에 표시된 계정 이름). 도메인 사용자 또는 그룹을 참조하는 데 사용할 수 있습니다. 일부 규칙은 그룹만 지원하며 도메인 사용자 참조를 지원하지 않습니다.

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

참고 항목

[프로젝트], [GLOBAL] 및 [Team Foundation]이 있는 그대로 사용됩니다. 프로젝트, 컬렉션 또는 서버 이름의 이름으로 대체하지 않습니다.

프로젝트 또는 컬렉션에 사용할 수 있는 범위에 대해 알아보려면 프로젝트 설정 사용 권한 그룹 또는 컬렉션 설정>>사용 권한>그룹 페이지로 이동합니다.> 필요에 따라 목록을 필터링합니다. 예를 들어 다음 이미지는 Azure DevOps를 기반으로 필터링된 목록에 대한 처음 네 개의 항목을 보여 줍니다. 자세한 내용은 프로젝트 수준 권한 변경 또는 프로젝트 컬렉션 수준 권한 변경을 참조하세요.

모든 사용자 및 그룹은 이러한 토큰 중 하나로 한정되어야 합니다. 예를 들어 다음 XML은 지정된 그룹에 유효한 토큰을 사용할 수 없기 때문에 유효하지 않습니다.

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

기본 보안 그룹에 대한 자세한 내용은 사용 권한 및 그룹을 참조 하세요.

규칙 평가

작업 항목을 수정하는 사용자의 사용자 또는 그룹 멤버 자격에 따라 조건을 지정하는 규칙은 두 가지 방법 중 하나로 평가됩니다. 규칙을 평가할 때 애플리케이션은 해당 사용자가 지정된 그룹의 멤버인지 아닌지 확인하여 규칙이 현재 사용자에게 적용되는지 여부를 결정해야 합니다.

• 웹 포털, REST API 또는 azure boards 명령에서 작업 항목을 수정할 때 Microsoft Entra ID 또는 Active Directory에 대한 요청이 수행됩니다. 이 작업에 문제가 발생하지 않습니다.
• WIT 클라이언트 개체 모델을 사용하여 Visual Studio, Excel 또는 기타 사용자 지정 도구에서 작업 항목을 수정하는 경우 멤버 자격 평가 요청은 클라이언트 캐시를 기반으로 합니다. 클라이언트 캐시는 Active Directory 그룹을 인식하지 않습니다.

참고 항목

GIT를 사용하는 프로젝트에 대한 Visual Studio 2019 팀 탐색기가 REST API를 사용하도록 다시 작성되었습니다.

사용자가 다양한 클라이언트에서 작업 항목을 업데이트하는 문제를 방지하려면 Active Directory 그룹 대신 Azure DevOps 보안 그룹을 지정합니다. Active Directory 그룹에 해당하는 Azure DevOps 보안 그룹을 쉽게 만들 수 있습니다. 방법을 알아보려면 사용자 또는 그룹 추가 또는 제거, 보안 그룹 관리를 참조하세요.

참고 항목

WIT 클라이언트 OM은 더 이상 사용되지 않습니다. 2020년 1월 1일부터 Azure DevOps Services 및 Azure DevOps Server 2020에 대해 작업할 때 더 이상 지원되지 않습니다.

규칙이 평가되는 순서

규칙은 일반적으로 나열된 순서대로 처리됩니다. 그러나 모든 규칙을 평가하기 위한 전체 순서는 완전히 결정적이지 않습니다.

이 섹션에서는 조건부, 복사 및 기본 규칙을 적용할 때 예상되는 동작 및 상호 작용에 대해 설명합니다.

상속 프로세스

다음 단계에서는 Azure DevOps가 수행하는 상호 작용과 작업 항목 양식의 사용자가 수행하는 상호 작용을 올바른 순서로 보여 줍니다. 사용자가 1단계, 8단계 및 13단계만 수행합니다.

1. 웹 포털 또는 Visual Studio Team Explorer와 같은 Azure DevOps 클라이언트에서 사용자는 새 작업 항목을 만들거나 기존 작업 항목을 편집합니다.

2. 필드 기본값을 입력합니다. 모든 필드에 대해 조건부 절의 일부가 아닌 필드에 할당된 모든 기본값을 적용합니다.

3. 필드 값을 복사하거나 설정합니다. 모든 필드에 대해 모든 규칙을 적용하여 값을 복사하거나 조건부 절에 속하지 않는 필드의 값을 설정합니다.

4. 일치하는 When 조건부 규칙이 있는 모든 필드에 대해 필드 값을 설정하거나 복사하는 규칙을 적용합니다.

5. 일치하는 조건부 규칙이 아닌 경우 조건부 규칙이 있는 모든 필드에 대해 필드 값을 설정하거나 복사하는 규칙을 적용합니다.

   시스템은 항상 When Not 규칙 전에 When 규칙을 처리합니다.

6. 1단계 이후 값이 변경되고 변경된 경우 규칙이 포함된 모든 필드에 대해 필드 값을 설정하거나 복사하는 규칙을 적용합니다.

7. 사용자가 편집을 시작할 수 있도록 허용합니다.

8. 사용자가 필드 값을 변경한 다음 필드에서 포커스를 이동합니다.

9. 새 값과 일치하는 해당 필드에 대한 When 규칙을 처리합니다.

10. 새 값과 일치하는 해당 필드에 대한 When Not 규칙을 처리합니다.

11. 새 값과 일치하는 해당 필드에 대해 변경된 경우 규칙을 처리합니다.

12. 사용자에게 편집 기능을 반환합니다.

13. 사용자가 변경 내용을 데이터 저장소에 저장합니다.

14. 모든 필드에 대해 조건부 규칙에 따라 직접 또는 간접적으로 필드에 대해 정의된 모든 Use the current time to set the value of ... 작업을 적용합니다.

온-프레미스 XML 프로세스

규칙은 일반적으로 나열된 순서대로 처리됩니다. 그러나 WHEN, DEFAULT 및 COPY 요소를 사용하는 경우 추가 동작이 적용될 수 있습니다. 다음 단계에서는 Azure DevOps가 수행하는 상호 작용과 작업 항목 양식의 사용자가 수행하는 상호 작용을 올바른 순서로 보여 줍니다. 사용자가 1단계, 8단계 및 13단계만 수행합니다.

1. 웹 포털 또는 Visual Studio Team Explorer와 같은 Azure DevOps 클라이언트에서 사용자는 새 작업 항목을 만들거나 기존 작업 항목을 편집합니다.

2. 필드 기본값을 입력합니다. 모든 필드에 대해 외부 또는 WHEN 규칙에 지정된 모든 DEFAULT 규칙을 적용합니다.

3. 필드 값을 복사합니다. 모든 필드에 대해 WHEN 절 외부에 있는 COPY 규칙을 사용합니다.

4. 일치하는 WHEN 규칙이 있는 모든 필드에 대해 먼저 DEFAULT를 수행하고 내부에 규칙을 복사합니다.

5. 일치하는 WHENNOT 규칙이 있는 모든 필드에 대해 먼저 DEFAULT를 수행하고 내부에 규칙을 복사합니다.

   시스템은 항상 WHENNOT 규칙 전에 WHEN 규칙을 처리합니다.

6. 1단계 이후 값이 변경되고 WHENCHANGED 규칙이 포함된 모든 필드에 대해 먼저 DEFAULT를 수행한 다음 내부에 규칙을 복사합니다.

7. 사용자가 편집을 시작할 수 있도록 허용합니다.

8. 사용자가 필드 값을 변경한 다음 필드에서 포커스를 이동합니다.

9. 새 값과 일치하는 해당 필드에 대한 WHEN 규칙을 올립니다.

10. 새 값과 일치하는 해당 필드에 대한 WHENNOT 규칙을 발생합니다.

11. 새 값과 일치하는 해당 필드에 대한 WHENCHANGED 규칙을 발생합니다.

12. 사용자에게 편집 기능을 반환합니다.

13. 사용자가 변경 내용을 데이터베이스에 저장합니다.

14. 모든 필드에 대해 WHEN 또는 WHENNOT 규칙에 따라 직접 또는 간접적으로 필드에 대해 정의된 SERVERDEFAULT 작업을 수행합니다.

키 입력 항목 및 규칙 평가

시스템은 사용자가 작업 항목 양식을 통해 필드 내에서 키 입력을 입력할 때마다 필드에 대한 새 값을 설정합니다. 즉, 규칙의 필수 조건 조건이 충족될 때마다 조건부 규칙이 예기치 않게 발생할 수 있습니다.

다음 XML 예제에서는 사용자가 의도한 최종 값이 "승인"이 아니더라도 "e"라는 문자를 승인됨으로 입력하는 즉시 WHEN 규칙이 발생하므로 상태 필드에 "승인됨"을 입력할 때 시스템에서 MyCorp.SubStatus를 비웁니다. 이러한 이유로 조건부 규칙을 사용할 때는 신중하게 고려해야 합니다.

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

관련된 문서

• 샘플 규칙 시나리오
• 작업 항목 필드 인덱스
• 작업 항목 필드 및 특성
• 프로젝트 수준 권한 변경
• 프로젝트 컬렉션 수준 권한 변경
• 사용 권한 및 그룹
• 상속된 프로세스
  • 작업 항목 유형에 사용자 지정 규칙 추가
  • 워크플로 상태에 규칙 적용
• 온-프레미스 XML 프로세스
  • 기본값 정의 또는 필드에 값 복사
  • 선택 목록 정의
  • 조건부 기반 값 및 규칙 할당