Применение правила к полю рабочего элемента
В зависимости от типа данных поля можно задать различные ограничения для вводимых в этом поле данных. Можно указать значения для списка выбора (раскрывающееся меню), задать значения по умолчанию, очистить записи или ограничить внесение изменений. Используя условные правила, можно применять правила к полю на основании зависимостей между значениями разных полей. Кроме того, можно ограничить набор пользователей, которым разрешено изменять поле, либо установить в качестве области действия правила некоторую группу.
Все эти элементы правил можно определить в определении типа рабочих элементов FIELD с учетом некоторых ограничений, распространяющихся на системные поля. Кроме того, за исключением HELPTEXT, эти правила можно задать для применения время перехода рабочего процесса либо в качестве элементов внутри элемента FIELD (глобальный рабочий процесс).
.png "Правила поля XML-элемента для отслеживания рабочего элемента")
Вы можете определить любые правила для поля в соответствии с ограничениями, описанными в этом разделе.
Текст справки. Укажите текст подсказки, появляющийся в форме рабочего элемента для поля. Список выбора. Укажите раскрывающееся меню или список выбора с разрешенными, рекомендуемыми или запрещенными значениями. |
Правила назначения значений. Определите поведение и ограничения среды выполнения.
|
Условные правила. Задайте условия применения набора правил к родительскому полю. Указание условий на основе роли пользователя. Примените правила в зависимости от пользователя, который создает или изменяет рабочий элемент. Использование токенов для указания группы. Укажите домен или область группы, использующей допустимый токен. |
Какие правила можно применить к системным полям? Как избежать ошибок проверки для полей личных имен? Существует ли способ определить список выбора с несколькими выбираемыми позициями? |
Где следует применять правило поля? Как оцениваются правила? В каком порядке? Как результаты нажатий клавиш на форме влияют на оценку правил? |
Как изменить поля "Состояние" и "Причина"? Как поместить в поле значение, получаемое путем сложения значений двух других полей? Когда нужно определять правила полей с использованием глобального рабочего процесса? |
Правила полей являются тем компонентом, с помощью которого можно настроить отслеживание рабочих элементов. Дополнительные сведения см. в разделе Настройка объектов отслеживания работ для поддержки командных процессов.
Дополнительные сведения о добавлении правил полей в файл определения типов рабочих элементов см. в разделе Определение полей рабочих элементов.
Текст справки
Вы можете настроить текст справки или текст подсказок, отображаемый при наведении указателя на поле на форме рабочего элемента. Можно настроить и локализовать текст справки для поля, которое отображается в других рабочих элементах и других командных проектах. Длина текста справки не может превышать 255 символов в формате Юникод.
В следующем примере демонстрируется назначение текста справки настраиваемому полю «Business Justification»:
<FIELD name=”Business Justification” refname="Fabrikam.BusinessJustification" type="String">
<HELPTEXT>Only required when you set the Urgencyfield to Need Immediately. </HELPTEXT>
</FIELD>
Чтобы ввести указания длиннее 255 символов, см. раздел Предоставление текста справки, гиперссылок или веб-содержимого в форму рабочего элемента.
Примечание
Наличие HELPTEXT увеличивает объем хранимых данных и может негативно влиять на масштабируемость.Если вы ведете несколько сотен командных проектов в одном экземпляре TFS, используйте правила HELPTEXT крайне осмотрительно.
Правила списка выбора
Правила списка выбора определяют значения, которые пользователь может или не может выбрать для строкового поля. Значения, определенные в списке выбора, отображаются на форме рабочего элемента и в редакторе запросов. Списки можно комбинировать, расширять и сокращать. Кроме того, можно использовать атрибуты for и not, чтобы применять или игнорировать эти правила в зависимости от того, кто изменяет рабочий элемент.
Правило |
Использование |
|---|---|
ALLOWEDVALUES |
Ограничивает значения, которые пользователь может выбрать с учетом указанных значений. |
ALLOWEXISTINGVALUE |
Позволяет полю сохранить существующее значение, даже если оно уже отсутствует в списке выбора. Это правило рекомендуется использовать при изменении значений поля в списке выбора, а также для списков выбора, содержащих личные имена. |
GLOBALLIST |
Указывает имя глобального списка, который содержит значения, сохраняемые для командного проекта или коллекции проектов. |
PROHIBITEDVALUES |
Предотвращает назначение заданных значений. Рабочий элемент нельзя сохранить, если поле содержит запрещенное значение. |
SUGGESTEDVALUES |
Определяет не являющийся исчерпывающим список значений, доступных пользователям для выбора. Пользователи могут указать значения, отличные от приведенных в списке. |
Примеры использования списков выбора см. в разделе Определение списков выбора.
Правила назначения значений
Правила назначения значений определяют константы и режим работы во время выполнения, например задают значения по умолчанию, очищают поля, делают поля обязательными для заполнения и т. п. С помощью атрибутов for и not можно применять или игнорировать эти правила в зависимости от того, кто изменяет рабочий элемент.
Очистка, установка значения по умолчанию, копирование значения или принудительное соответствие значений шаблону
Эти правила поддерживают установку значений по умолчанию, копирование значений из одного поля в другое или принудительное обеспечение соответствия значения поля заданному шаблону.
Правило |
Использование |
|---|---|
COPY |
Копирует указанное значение в поле, когда пользователь создает или изменяет рабочий элемент. |
DEFAULT |
Задает значение для поля, которое пусто во время создания или изменения рабочего элемента пользователем. Если поле уже содержит значение, правило DEFAULT игнорируется. |
EMPTY |
Очищает поле от любого содержащегося значения, а когда пользователь сохраняет рабочий элемент, делает это поле доступным только для чтения. Не следует использовать EMPTY совместно с READONLY. EMPTY используется в основном во время перехода между состояниями и служит для очистки полей, применяемых к состоянию, в которое переходит элемент. |
MATCH |
Принудительно требует от записей в строковом поле соответствия заданному шаблону чисел и букв. |
SERVERDEFAULT |
Копирует имя текущего пользователя или показания часов сервера в поле, когда пользователь сохраняет рабочий элемент. На форме эти поля обычно доступны только для чтения. |
Структуру синтаксиса и примеры см. в разделе Определение значения по умолчанию или копирование значения в поле.
Обязательные поля, доступ только для чтения и ограничение назначаемых полю значений
Эти правила позволяют задать ограничения для указания или изменения значения поля.
Правило |
Использование |
|---|---|
CANNOTLOSEVALUE |
Не позволяет пользователям очистить поле после указания в нем значения. |
FROZEN |
Не позволяет пользователям изменить поле, содержащее значение. Как только пользователь сохраняет рабочий элемент со значением в данном поле, изменить это значение уже нельзя. |
NOTSAMEAS |
Не позволяет назначить полю то же значение, которое уже было назначено другому полю. |
READONLY |
Полностью запрещает изменение поля. Возможно, это правило потребуется применить при определенных условиях. Например, после закрытия рабочего элемента необходимо сделать поле доступным только для чтения, чтобы сохранить данные для отчетов. Не используйте READONLY совместно с элементом EMPTY, так как EMPTY также делает поле доступным только для чтения. Совместное использование этих элементов дает несогласованные результаты. Кроме того, поле можно сделать доступным только для чтения в форме рабочего элемента с помощью атрибута Control element ReadOnly. Клиенты могут выполнять запись в поле, но не через форму рабочего элемента. |
REQUIRED |
Требует от пользователя задать значение для поля. Пользователи не могут сохранить рабочий элемент, пока не назначат значения всем обязательным полям. |
Структуру синтаксиса см. в разделе Справочник по всем XML-элементам FIELD.
Ограничение прав на создание или изменение рабочего элемента
Вы можете управлять тем, кто именно может создать или изменить рабочий элемент, применив элемент VALIDUSER к полям с личными именами. Задавая этот элемент, вы указываете пользователя или группу пользователей, которые могут быть назначены данному полю в виде значения. Вы можете задать этот элемент, чтобы использовать необязательный атрибут group, который требует, чтобы назначенный полю человек был явным или неявным членом заданной вами группы. По умолчанию в этом поле можно указать всех членов группы Допустимые пользователи Team Foundation.
Элемент VALIDUSER допустимо использовать только для полей строкового типа. Можно разрешить или запретить применение правила к пользователю, изменяющему рабочий элемент, указав пользователя или группу в атрибутах for или not.
<VALIDUSER group="groupName" for="userName" not="userName" />
Правило VALIDUSER можно использовать только при ссылке на поля с личными именами. Приведенные ниже системные поля являются примерами полей с личными именами:
Активировал (System.ActivatedBy)
Кому назначено (System.AssignedTo)
Авторизован как (System.AuthorizedAs)
Кем изменено (System.ChangedBy)
Кем закрыт (System.ClosedBy)
Кем создано (System.CreatedBy)
Кроме системных полей, вы можете создать настраиваемое строковое поле и использовать его в качестве поля личных имен. Вы также можете синхронизировать настраиваемые поля личных имен с Active Directory (укажите syncnamechanges="true").
Поля рабочих элементов не различают удостоверения пользователя из разных доменов. Таким образом, «Fabrikam\ctsoapo» и «Contoso\ctsoapo» считаются одним и тем же пользователем при вводе в поле, использующем правило VALIDUSER.
Условные правила
Условные правила позволяют задать набор правил, который будет применен к родительскому полю. Можно задать условия двух типов: когда другому полю назначается (или не назначается) заданное значение и когда значение другого поля изменяется (или не изменяется). Внутри элемента условного правила можно включить список выбора и назначить правила значений.
Правило |
Использование |
|---|---|
WHEN |
Указывает правила, применяемые к родительскому полю, если другому полю назначается заданное значение. |
WHENNOT |
Указывает правила, применяемые к родительскому полю, если другому полю не назначается заданное значение. |
WHENCHANGED |
Указывает правила, применяемые к родительскому полю, когда значение заданного поля изменяется. |
WHENNOTCHANGED |
Указывает правила, применяемые к родительскому полю, когда значение заданного поля не изменяется. |
Можно указать несколько условных правил на одно поле. Однако для условного правила можно задать только одно управляющее поле. Условные правила нельзя вкладывать. Структуру синтаксиса и примеры см. в разделе Назначение условных значений и правил.
Применение и пропуск правил в зависимости от того, кто создает или изменяет рабочий элемент
Вы можете определить, применяется ли список выбора или правило значения к группе пользователей, с помощью атрибутов for или not. Ограничение области действия правила группой Чтобы правило применялось к нескольким группам, необходимо создать родительскую группу TFS, включающую в себя нужный набор групп.
Назначение поля в качестве обязательного только для заданной группы:
Используйте для, чтобы применить правило к группе. В этом примере требуется, чтобы любой пользователь из группы «Junior Analysts» заполнил поле «Second Approver».
<FIELD name="Second Approver"> <REQUIRED for="Example1\Junior Analysts"/> </FIELD>Предоставление прав на изменение поля отдельной группе пользователей:
Используйте not, чтобы исключить группу из правила. В этом примере поле «Triage Description» становится доступным только для чтения для всех пользователей, кроме членов группы «Triage Committee».
<FIELD name="Triage Description"> <READONLY not="[Project]\Triage Committee" /> </FIELD>Назначение поля в качестве обязательного для отдельного набора пользователей:
Используйте сочетание for и not, чтобы одновременно применить правило к определенному набору пользователей. В данном примере поле «Severity» становится обязательным для пользователей из группы «Project Members», но не для членов группы «Project Admins».
<FIELD name="Severity"> <REQUIRED for="[Project]\Project Members" not="[Global]\Project Admins"/> </FIELD>Поскольку Deny имеет приоритет над Allow, то при нахождении пользователя в обеих группах применяется оператор «not», и поле не будет обязательным.
Использование токенов для ссылок на группы
При ограничении области действия правила некоторой группой необходимо указать домен или область действия этой группы. Для некоторых значений можно использовать токены.
Поля личных имен могут принимать значения, ссылающиеся как на пользователей, так и на группы. Атрибуты полей for и not применяются к группам. При указании значений для этих элементов можно использовать следующие токены.
Ограничение области действия командным проектом — [Project] :
Токен [Project] используется для указания группы, определенной для командного проекта. Это может быть группа, встроенная группа TFS, например [Project]\Contributors, настраиваемая группа TFS, созданная на уровне проекта, либо группа Windows, добавленная в группу TFS. Например:
Команда: [Project]\Fabrikam Team
При создании команды создается группа TFS, которая содержит назначенных этой команде членов.
Группа командного проекта: [Project]\Contributors
Группа Windows, добавленная в командный проект: [Project]\ Triage Committee
Совет. Вы можете просмотреть список допустимых групп, открыв страницу безопасности в контексте администрирования Team Web Access (TWA).
Ограничение области действия коллекцией проектов — [CollectionName]:
Используйте [CollectionName] для ссылки на ограниченную коллекцией группу TFS, такую как группа «Администраторы коллекции проектов» или группа Windows, добавленная вами в коллекцию. Например:
<FIELD name="Title"> <READONLY for="[DefaultCollection]\Project Collection Valid Users"/> </FIELD>Ограничение области действия экземпляром сервера — [GLOBAL]:
Используйте токен [GLOBAL] для ссылки на ограниченную сервером группу TFS, такую как встроенная группа или группа Windows, добавленная вами в группу на уровне сервера. Например:
<FIELD name="Title"> <READONLY for="[Global]\Team Foundation Valid Users"/> </FIELD>Указание учетной записи или группы с квалификатором домена:
Имя учетной записи с квалификатором домена, например такое, как в следующем примере, можно использовать для ссылки на пользователя домена или группу. Обратите внимание, что некоторые правила поддерживают только группы и не поддерживают ссылки на пользователей домена.
<LISTITEM value="FABRIKAM\Christie Church’s Direct Reports"/>
Все пользователи и группы должны квалифицировать по одному из этих токенов. Например, следующий XML-код недействителен, так как не соответствует указанной группе по допустимому токену.
<FIELD name="Title">
<READONLY for="Dev Team"/>
</FIELD>
Вопросы и ответы
Вопрос. Какие правила можно применить к системным полям?
Ответ. Системные поля имеют имена ссылки Sytem.имя, например System.Title и System.State. TFS запрещает настройку этих полей, за исключением следующих случаев:
Правило HELPTEXT можно назначить всем полям.
Правило READONLY можно назначить полям «Состояние» и «Причина».
Большинство правил можно назначить системным полям «Заголовок», «Кому назначено», «Описание» или «Кем изменено».
Вопрос. Как избежать ошибок проверки для полей личных имен?
Ответ. Чтобы избежать ошибок проверки, которые возникают, если члены команды покидают ее и больше не регистрируются в качестве участников проекта, включите для поля «Кому назначено» элемент 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>
Вопрос. Существует ли способ определить список выбора с несколькими выбираемыми позициями?
Ответ. Эта возможность не имеет собственной поддержки, однако можно попытаться адаптировать исходный код в проекте CodePlex: Пользовательские элементы управления для отслеживания рабочих элементов TFS.
Вопрос. Как изменить поля состояния и причины?
Ответ. Поля состояния и причины в разделе WORKFLOW определения типа рабочих элементов. Для большинства правил полей можно задать применение к полю во время смены состояния, выбора причины или выполнения определенного перехода. Дополнительные сведения см. в разделе Изменение рабочего процесса для типа рабочего элемента.
Вопрос. Где следует применять правило поля?
Ответ. Когда нужно, чтобы правило применялось на протяжении всего срока действия рабочего элемента, укажите его с определением FIELD. Например, поле для ошибки, которая появилась недавно, остается нужным вплоть до устранения этой ошибки.
В противном случае, укажите, чтобы оценка правила производилась только при смене состояния. Эти правила определяются в элементах STATE, REASON или TRANSITION раздела WORKFLOW. Все правила, кроме HELPTEXT, можно применить в элементе FIELD (рабочий процесс).
Правила полей являются аддитивными. Это значит, что вы можете указать четыре набора правил для одного поля, и все они будут оцениваться подсистемой правил рабочего элемента.
Зависящие от типа правила рабочего элемента применяются независимо от расположения рабочего элемента в его модели состояний. Например, правило <REQUIRED /> выполняет следующую проверку:
"MyField Value" != NULL
Областью действия зависящих от состояния правил является рабочий элемент, находящийся в определенном состоянии. Зависящее от состояния правила применяются при выполнении следующего условия:
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>
Вопрос. Как оцениваются правила?В каком порядке?
Ответ. Правила обычно обрабатываются в том порядке, в котором они указаны. Однако при использовании элементом WHEN*, DEFAULT и COPY может иметь место иной порядок.
Лучше разобраться в том, как оцениваются правила, можно, применив к полю сразу несколько правил. Оценку правил нельзя назвать полностью детерминированной. В этом разделе описаны возможные режимы работы и взаимодействия, проявляющиеся при использовании правил WHEN*, DEFAULT и COPY.
В следующих пунктах показана правильная последовательность взаимодействия, реализуемого TFS совместно с пользователем формы рабочего элемента. Пользователь выполняет только действия 1, 8 и 13.
Пользователь в клиенте Team Foundation, например Visual Studio, Team Explorer, Team Web Access или Team Explorer Everywhere, создает новый или изменяет существующий рабочий элемент.
Заполните значения по умолчанию для полей. Для всех полей используйте любые правила DEFAULT, не связанные с правилами WHEN*.
Скопируйте значения полей. Для всех полей используйте любые правила COPY, не связанные с предложениями WHEN*.
Для всех полей с соответствующим правилом WHEN сначала используйте DEFAULT, а затем скопируйте правила с помощью COPY.
Для всех полей с соответствующим правилом WHENNOT сначала используйте DEFAULT, а затем скопируйте правила с помощью COPY.
TFS всегда обрабатывает правила WHEN перед правилами WHENNOT.
Для всех полей, значения которых изменились с момента выполнения действия 1, с правилами WHENCHANGED сначала используйте DEFAULT, а затем скопируйте правила с помощью COPY.
Позвольте пользователю начать редактирование.
Пользователь изменяет значение поля и затем убирает фокус с поля.
Вызовите для поля правила WHEN, соответствующие новому значению.
Вызовите для поля правила WHENNOT, соответствующие новому значению.
Вызовите для поля правила WHENCHANGED, соответствующие новому значению.
Возвратите пользователю возможность редактирования.
Пользователь сохраняет изменения в базу данных.
Для всех полей выполните операции SERVERDEFAULT, как прямо, так и косвенно определенные для поля в правиле WHEN или WHENNOT.
Вопрос. Как результаты нажатий клавиш на форме влияют на оценку правил?
Ответ. Система задает новое значение для поля каждый раз, когда пользователь нажимает клавишу в поле, с помощью формы рабочего элемента интерфейса пользователя. Это означает, что условное правило может выполняться внезапно при соблюдении заданных условий.
В следующем примере XML-кода SubStatus будет опустошаться по мере ввода вами фразы «Approved Again» в поле состояния, так как правило WHEN* выполняется при вводе буквы «e» в слове «Approved», даже если конечная форма слова отличается от «Approve». Поэтому использование условных правил следует тщательно обдумывать.
<FIELD refname="MyCorp.SubStatus" />
<WHEN field="MyCorp.Status" value="Approve" >
<EMPTY />
</WHEN>
</FIELD>
Вопрос. Как поместить в поле значение, получаемое сложением значений двух других полей?
Ответ. Эта возможность пока не имеет собственной поддержки.
Вопрос. Когда нужно определять правила с использованием глобального рабочего процесса?
Ответ. Используйте глобальный рабочий процесс только тогда, когда требуется работать с большим числом полей с одинаковыми определениями и правилами в разных командных проектах. По аналогии с глобальными списками использование глобального рабочего процесса помогает минимизировать трудозатраты, когда требуется обновлять определения полей. Для получения дополнительной информации см. Настройка глобального рабочего процесса.
См. также
Основные понятия
Справочник по всем XML-элементам WITD