Partager via


Conventions d'affectation de noms pour les objets de suivi des éléments de travail

Tous les objets de suivi des éléments de travail sont associés à un ou plusieurs noms. La plupart d'entre eux ont des noms complets conviviaux et tous, sauf les types d'éléments de travail et les listes globales, sont associés à des noms de référence. Un nom convivial est un identificateur unique, visible par l'utilisateur pour un champ que vous utilisez pour garantir la cohérence dans l'ensemble des projets d'équipe et des types d'éléments de travail dans une collection de projets. Le nom de référence est utilisé en interne par Team Foundation Server et ne peut pas être changé après qu'il a été défini.

Le tableau suivant résume les conditions d'affectation de noms à satisfaire pour chaque objet de suivi des éléments de travail.

Objet de suivi des éléments de travail

Nom de la référence

Nom convivial

Type d'élément de travail

Non applicable

Le nom de chaque type d'élément de travail peut contenir jusqu'à 255 caractères Unicode et doit être unique dans un projet d'équipe.

Champ d'élément de travail

Obligatoire. Consultez Spécifications des noms de références.

Les noms de champ peuvent contenir jusqu'à 128 caractères Unicode et doivent être uniques dans une collection de projets d'équipe.

Type de lien

Obligatoire. Consultez Spécifications des noms de références.

Vous définissez deux noms conviviaux pour chaque type de lien : le nom direct et le nom inverse. Ces noms peuvent contenir jusqu'à 128 caractères Unicode et doivent être uniques pour tous les types de lien définis pour une collection de projets d'équipe.

Catégorie

Obligatoire. Consultez Spécifications des noms de références.

Les noms conviviaux de catégorie peuvent contenir jusqu'à 128 caractères Unicode et doivent être uniques dans une collection de projets d'équipe.

Liste globale

Non applicable

Le nom de chaque liste globale peut contenir jusqu'à 254 caractères Unicode et doit être unique dans une collection de projets d'équipe.

Contenu de la rubrique

  • Spécifications des noms conviviaux

  • Spécifications des noms de référence

  • Spécifications de portabilité et des noms de référence de champ

  • Exemples de noms de référence de champ

Spécifications des noms conviviaux

En plus des spécifications résumées dans le tableau répertorié précédemment dans cette rubrique, les noms conviviaux que vous définissez doivent satisfaire aux spécifications suivantes :

  • Les noms ne doivent pas être vides.

  • Les noms ne peuvent pas contenir d'espaces blancs de début ou de fin.

  • Les noms ne peuvent pas contenir de barres obliques inverses (\).

  • Les noms de champ ne peuvent pas contenir les caractères suivants : barre oblique inverse (\), point (.) et crochets d'ouverture et de fermeture ([]).

  • Les noms ne peuvent pas contenir deux ou plusieurs espaces blancs consécutifs.

Spécifications des noms de référence

Vous devez définir un nom de référence à chaque fois que vous ajoutez ou créez un champ d'élément de travail, un type de lien ou une catégorie. Tous les noms de référence peuvent contenir jusqu'à 70 caractères Unicode.

Vous pouvez définir un nom de référence à l'aide des caractères alphanumériques, des traits de soulignement et des traits d'union. Chaque nom de référence doit contenir au moins un point (.), mais aucun point ne peut apparaître au début ou à la fin d'un nom. Un nom de référence ne peut pas commencer par un chiffre ou un trait de soulignement, ni contenir plusieurs traits d'union consécutifs tels que (--).

Portabilité et noms de référence de champ

Le langage de définition du type d'élément de travail inclut le concept du nom de référence de champ. Les noms de référence de champ peuvent vous aider à déplacer des définitions entre des collections du projet Team Foundation ainsi que permettre aux intégrations tierces de rechercher et référencer des champs spécifiques. Ces noms sont globalement uniques, tout comme un espace de noms dans l'application .NET Framework est globalement unique.

Les noms de référence de champ ne peuvent pas être renommés. Par exemple, si vous avez remplacé le nom de champ "Titre" par "En-tête", le nom de référence de ce champ reste le même. Les intégrations et les représentations internes des champs doivent utiliser le nom de référence de champ au lieu de dépendre du nom de champ lui-même.

L'espace de noms System est utilisé uniquement pour définir tous les champs système de base qui sont obligatoires pour les fonctions système Team Foundation. Team Foundation Server vous empêche de créer votre propre champ System.X, car cette opération peut compromettre les fonctionnalités de Team Foundation Server.

L'espace de noms Microsoft est utilisé pour définir des champs définis dans une définition de type d'élément de travail d'un modèle de processus Microsoft Solutions Framework (MSF). Team Foundation Server ne vous empêche pas de créer votre propre champ Microsoft.X. Toutefois, cette pratique est vivement déconseillée, car elle risque de compromettre les fonctionnalités de Team Foundation Server.

Les clients et les partenaires peuvent créer leurs propres espaces de noms de champs pour des types d'élément de travail personnalisés.

Pour des descriptions de champs système et de champs définis par MSF for Agile Software Development - v5.0, consultez Utilisation de champs système et de champs définis par les modèles de processus MSF.

Exemples de noms de référence de champ

Les exemples suivants affichent des noms de références de champs valides dans différents espaces de noms.

Exemples d'espaces de noms système

System.Id

System.Title

System.CreatedBy

System.CreationDate

System.ChangedBy

System.ChangedDate

System.State

System.Reason

Exemples d'espace de noms Microsoft

Microsoft.Common.Status

Microsoft.Common.Priority

Microsoft.Scheduling.Duration

Microsoft.Scheduling.PercentComplete

Microsoft.Testing.TestCaseName

Exemples dans d'autres espaces de noms

Les clients et les partenaires peuvent également définir leurs propres espaces de noms pour prendre en charge leurs types d'éléments de travail personnalisés. Par exemple, la société fictive Trey Research peut définir les types d'éléments de travail personnalisés suivants :

TreyResearch.Common.Severity

TreyResearch.Common.Phase

TreyResearch.RiskManagement.RiskType

TreyResearch.RiskManagement.Resolution

Éditeur fictif de logiciel A. Datum Corporation peut définir les types d'éléments de travail suivants :

A_Datum.Common.BusinessPriority

A_Datum.Bug.FoundInPhase

A_Datum.Bug.FixInPhase

Voir aussi

Référence

Élément FIELD (Définition)

Concepts

Personnalisation des données de suivi de projet, de formulaires, de flux de travail et d'autres objets