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