Résumé
Pour garantir une utilisation cohérente des propriétés personnalisées ou des champs, Microsoft Office Outlook 2003 Service Pack 2 (SP2) et les versions ultérieures d’Outlook limitent certaines des façons dont les propriétés personnalisées peuvent être introduites dans les magasins de données Outlook. Par exemple, les propriétés personnalisées peuvent être introduites de manière spécifique dans les fichiers de dossiers personnels Outlook (.pst).
INTRODUCTION
Cet article effectue les opérations suivantes :
-
Fournit une vue d’ensemble des propriétés personnalisées.
-
Explique comment le comportement des propriétés personnalisées a été modifié dans Outlook 2003 SP2 et dans les versions ultérieures d’Outlook.
-
Présente certaines bonnes pratiques pour créer des propriétés et certaines méthodes que nous ne recommandons pas.
Informations supplémentaires
À propos des propriétés personnalisées
Les propriétés personnalisées sont utilisées par les programmes de messagerie, tels qu’Outlook, pour ajouter des informations supplémentaires à un message. En règle générale, ces informations supplémentaires sont utilisées par un programme de messagerie à des fins spécifiques. Toutefois, il existe d’autres façons d’utiliser des propriétés personnalisées. Par exemple, des propriétés personnalisées peuvent être ajoutées à des messages ou des éléments si vous utilisez des formulaires personnalisés Outlook et que ces formulaires contiennent des champs personnalisés. Les propriétés personnalisées sont fréquemment utilisées pour ajouter des informations supplémentaires à des fins de suivi. Les propriétés personnalisées sont également utilisées pour ajouter des données qu’un utilisateur n’a pas besoin de voir. Une solution personnalisée peut également ajouter des propriétés personnalisées à des éléments standard. Une solution personnalisée ajoute par programmation des propriétés personnalisées à un message ou à un élément sans nécessiter de formulaire personnalisé.
Les propriétés personnalisées peuvent être conservées au format de fichier .msg et au format de fichier .oft dans Outlook. En outre, les propriétés personnalisées peuvent être conservées dans les messages électroniques envoyés sur Internet si l’expéditeur utilise l’option Envoyer à l’aide du format Texte enrichi Outlook . Cette option encapsule la section MAPI du message au format TNEF (Transport Neutral Encapsulation Format), puis le TNEF est décodé à la réception du message.
Un expéditeur peut envoyer un e-mail qui a des propriétés personnalisées dans les scénarios suivants :
-
Un formulaire personnalisé unique est envoyé. Dans les formulaires ponctuels, le formulaire est incorporé dans le message. Le formulaire n’est pas publié ailleurs. Pour plus d’informations sur les formulaires ponctuels, consultez l’article suivant :
Enregistrer un formulaire avec l’élément (formulaires ponctuels)
-
Un formulaire personnalisé publié est envoyé. Dans ce cas, le formulaire personnalisé n’est pas envoyé, car il n’est pas incorporé dans le message. Toutefois, toutes les propriétés personnalisées utilisées sur le formulaire sont toujours incluses dans le message.
Remarque Il existe de nombreuses façons de faire référence aux propriétés personnalisées, selon le contexte dans lequel les propriétés personnalisées sont utilisées. Dans l’interface utilisateur Outlook, par exemple dans le sélecteur de champs, les propriétés personnalisées sont appelées champs définis par l’utilisateur ou champs personnalisés. Dans la bibliothèque d’objets Outlook, les propriétés personnalisées peuvent être appelées propriétés utilisateur ou propriétés définies par l’utilisateur après la collection UserProperties. Dans MAPI, les champs personnalisés sont appelés propriétés nommées. MAPI fournit une fonctionnalité permettant d’effectuer les opérations suivantes :
-
Attribuer des noms aux propriétés
-
Mapper les noms à des identificateurs uniques
-
Rendre le mappage persistant
Pour plus d’informations sur la façon dont les propriétés nommées sont implémentées dans MAPI, visitez le site web MSDN suivant :
http://msdn2.microsoft.com/en-us/library/ms529055.aspx Remarque Dans un environnement Exchange, le terme « magasin » tel qu’utilisé dans cet article fait référence à une banque de boîtes aux lettres entière (base de données). Le terme ne fait pas référence au magasin de boîtes aux lettres d’un utilisateur individuel. Il peut y avoir une ou plusieurs bases de données de boîte aux lettres Exchange dans un organization.
Changements de comportement dans Outlook
L’implémentation de MAPI dans Outlook a été modifiée pour contrôler la façon dont les propriétés personnalisées peuvent être créées. Pour garantir une utilisation cohérente des propriétés personnalisées, les propriétés personnalisées doivent déjà être utilisées dans le organization ou sur le client Outlook. Dès que des propriétés personnalisées sont utilisées ou inscrites, les propriétés personnalisées peuvent être transmises librement à d’autres clients Outlook ou aux serveurs qui exécutent Exchange Server. Les propriétés personnalisées peuvent également être envoyées via Internet.
Les messages électroniques sont généralement envoyés au format MIME sur Internet. Lorsqu’Outlook reçoit un message électronique Internet, le message est converti en représentation MAPI. Voici des exemples de protocoles de messagerie Internet :
-
POP
-
IMAP
-
HTTP (Outlook.com)
Par défaut, Outlook n’autorise plus la messagerie Internet à créer des propriétés personnalisées. Seules les propriétés déjà créées dans le magasin de remise de courrier par défaut sont conservées pour les messages électroniques entrants. Cette modification affecte principalement les messages envoyés dans TNEF encapsulé (Winmail.dat), où l’expéditeur a utilisé l’option Envoyer à l’aide du format Texte enrichi Outlook . Toutefois, les messages Internet qui contiennent des propriétés d’en-tête de message X sont également affectés.
Remarque Les messages qui contiennent des propriétés personnalisées envoyées dans un organization Exchange ne sont pas affectés par ces modifications.
Les propriétés personnalisées peuvent également être enregistrées dans des fichiers .msg et .oft. Si un utilisateur ouvre un fichier .msg qui a des propriétés personnalisées, ces propriétés personnalisées ne sont pas enregistrées dans le magasin par défaut lorsque le message est enregistré, transféré, et ainsi de suite. En règle générale, les fichiers .oft sont utilisés pour sauvegarder les formulaires personnalisés Outlook. Avec les fichiers .oft, le nouveau comportement s’applique à tous les types d’éléments. Le formulaire personnalisé ne s’ouvre pas. Au lieu de cela, le message s’affiche dans le formulaire par défaut pour ce type d’élément particulier.
En résumé, cette modification de la conception peut entraîner deux choses :
-
Outlook ignore les propriétés personnalisées non existantes. Si aucune propriété personnalisée n’existe dans le magasin de remise, la propriété n’est pas créée et sa valeur est perdue. Si la propriété personnalisée existe déjà dans le magasin de remise, sa valeur est conservée. Cette modification s’applique aux éléments suivants :
-
Messages électroniques Internet qui ont TNEF et leurs messages incorporés.
-
Messages S/MIME.
-
Fichiers .msg lorsque vous déposez le fichier .msg dans une fenêtre d’élément Outlook pour ajouter le fichier à un autre élément. Cette modification s’applique également aux fichiers .msg lorsque vous déposez le fichier .msg dans la fenêtre main Outlook pour ajouter le fichier à un dossier ou dans la fenêtre Microsoft Word lorsque vous utilisez Word comme éditeur de messagerie.
-
Fichiers .msg qu’un utilisateur double-clique ou clique avec le bouton droit pour ouvrir.
-
-
Outlook ignore la définition de formulaire unique. Si un formulaire unique spécifie une propriété personnalisée et que cette propriété personnalisée n’existe pas dans le magasin de remise, le formulaire unique n’est pas affiché. Au lieu de cela, l’utilisateur verra le formulaire par défaut pour ce type d’élément particulier. Cette modification s’applique aux messages électroniques Internet qui contiennent une définition de formulaire unique encapsulée dans TNEF. Cette modification s’applique également aux fichiers .oft qu’un utilisateur double-clique ou clique avec le bouton droit pour ouvrir.
Bonnes pratiques et autres façons de créer des propriétés
Vous pouvez concevoir et développer des solutions personnalisées de différentes façons. Certaines de ces approches sont considérées comme des meilleures pratiques. D’autres approches peuvent également fonctionner, mais nous ne recommandons pas ces approches pour une ou plusieurs raisons.
Bonne pratique : Ajouter des champs personnalisés par programmation
Différentes API peuvent être utilisées pour ajouter par programmation des champs personnalisés aux éléments. Pour ce faire, utilisez la méthode UserProperties.Add dans la bibliothèque d’objets Outlook (« Outlook.Application »). Le code suivant illustre cette bonne pratique.
Set myProp = myItem.UserProperties.Add("MyPropName", olText)
Vous pouvez également utiliser la bibliothèque d’objets CDO (« MAPI. Session « ) pour ajouter des champs personnalisés. Pour plus d’informations, reportez-vous au site web MSDN à l’adresse suivante :
http://msdn2.microsoft.com/en-us/library/ms527518.aspx Pour les développeurs C++, mapI étendu peut être utilisé pour ajouter des propriétés nommées. Pour plus d’informations, reportez-vous au site web MSDN à l’adresse suivante :
Bonne pratique : utiliser des formulaires personnalisés publiés qui contiennent des champs personnalisés
Outlook approuve en grande partie les formulaires personnalisés publiés. Toutefois, Outlook n’approuve pas les formulaires non publiés ou les formulaires ponctuels. Cela inclut les fichiers .oft. Par conséquent, lorsque vous concevez une solution de formulaire personnalisé, nous vous recommandons vivement de publier le formulaire personnalisé. Vous devez concevoir le formulaire afin qu’il ne devienne pas un formulaire unique. Tant qu’un formulaire est publié, le formulaire n’est pas affecté par la modification dans Outlook.
Lorsque vous publiez un fichier .oft dans un autre magasin, le magasin par défaut vous permet de créer des propriétés dans ce magasin. En outre, lorsque vous créez un formulaire personnalisé qui a des propriétés personnalisées et que vous le publiez dans la bibliothèque ou le dossier de formulaires approprié, les propriétés personnalisées sont créées dans les magasins affectés.
Bonne pratique : déploiement par programmation de formulaires personnalisés
Si vous développez un formulaire personnalisé Outlook qui sera utilisé par d’autres personnes, vous pouvez utiliser peu d’approches. L’approche que vous utilisez dépend de plusieurs facteurs. Ces facteurs incluent le type de formulaire, qui utilisera le formulaire, où le formulaire sera utilisé, et ainsi de suite. En règle générale, si un formulaire personnalisé est utilisé par de nombreuses personnes, nous vous recommandons de publier le formulaire dans la bibliothèque de formulaires d’organisation. Toutefois, si ce n’est pas possible, vous pouvez publier le formulaire dans un dossier partagé ou dans la bibliothèque de formulaires personnels de certains utilisateurs. Vous pouvez installer par programmation un formulaire personnalisé à l’aide de la méthode CreateItemFromTemplate dans la bibliothèque d’objets Outlook. Vous utilisez la méthode CreateItemFromTemplate pour ouvrir un fichier .oft, puis vous publiez le formulaire à l’aide de la méthode PublishForm. Dans ce cas, un fichier .oft n’est pas affecté par les modifications des propriétés personnalisées.
Non recommandé : déployer ou envoyer des fichiers .oft pour les utilisateurs à ouvrir
Vous pouvez enregistrer des formulaires personnalisés Outlook en tant que fichiers .oft. Ces formulaires peuvent contenir des champs personnalisés, des modifications d’interface utilisateur et du code Microsoft Visual Basic Scripting Edition (VBScript) personnalisé pour ajouter des fonctionnalités au formulaire. Bien qu’Outlook contienne déjà des fonctionnalités qui empêchent l’exécution du code VBScript dans les fichiers .oft, Outlook limite désormais également l’utilisation des fichiers .oft. Si un fichier .oft contient des propriétés personnalisées et que l’utilisateur n’a pas déjà utilisé ces propriétés personnalisées, les propriétés personnalisées ne se trouvent pas dans le magasin par défaut de l’utilisateur. Outlook ne restitue pas le formulaire personnalisé lorsque l’utilisateur double-clique sur le fichier. Toutefois, pour qu’Outlook ouvre un formulaire personnalisé stocké sous la forme d’un fichier .oft, cliquez sur Fichier, sur Nouveau, puis sur Choisir un formulaire. Vous pouvez ensuite remplacer l’emplacement par Modèles utilisateur dans le système de fichiers, puis cliquer sur Parcourir pour ouvrir le fichier .oft. Le formulaire s’ouvre et vous pouvez enregistrer les propriétés personnalisées dans le magasin par défaut.
Non recommandé : utiliser la clé de Registre AllowNamedProps
Certaines organisations peuvent avoir des raisons valables de disposer de certaines propriétés personnalisées tout au long de la organization. Si plusieurs magasins sont utilisés, vous pouvez vous assurer qu’un ensemble de propriétés personnalisées peut être ajouté à tous les magasins. Par conséquent, Outlook 2003 SP2 et les versions ultérieures prennent en charge les clés de Registre côté client qui spécifient les propriétés personnalisées qui peuvent être créées. Pour spécifier les propriétés personnalisées qui doivent être activées, les propriétés personnalisées sont définies sous la clé de Registre suivante : HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Outlook\AllowedNamedProps\
Remarque Dans cette clé de Registre, <version> est un espace réservé pour la version d’Outlook que vous utilisez. Pour Outlook 2003, le numéro de version est 11.0. Pour Outlook 2007, le numéro de version est 12.0. Le numéro de version augmentera dans les versions ultérieures d’Outlook.
La structure de clé de Registre globale pour une entrée dans le Registre est la suivante :
> GUID <
> nom de la propriété <
« Kind » (dword)
« ID » (dword)
« Type » (dword) Les espaces réservés suivants sont utilisés dans la structure de clé de Registre :
-
<GUID> : contient le GUID qui spécifie le jeu de propriétés. Les champs personnalisés Outlook, ou propriétés, que vous utilisez sur un formulaire personnalisé Outlook ont tous le GUID {00020329-0000-0000-C000-000000000000046}. Dans MAPI, le GUID est appelé PS_PULIC_STRINGS. Toutefois, les programmes MAPI personnalisés peuvent avoir leurs propres GUID pour les propriétés personnalisées.
-
<nom de la propriété> : spécifie le nom de la propriété. Si la propriété est nommée par une chaîne, la <Nom de la propriété> est le nom de chaîne réel de la propriété. Si la propriété est nommée par un ID, la valeur de cette clé de Registre est ignorée. Toutefois, vous devez donner un nom unique à la propriété afin qu’elle puisse être stockée dans le registre. Si la clé Kind a la valeur 1 ou est <> 0, le nom de la clé de Registre détermine le nom de la propriété. Si la clé Kind n’est pas égale à 1, ce nom de clé de Registre est ignoré.
-
« Kind » (dword) : spécifie si la propriété est nommée par un ID ou par une chaîne. Si la valeur est 0, la propriété est nommée par un ID. Le nom est une valeur numérique spécifiée par un ID. Si la valeur est 1, la propriété est nommée par une chaîne. Ce paramètre est le paramètre par défaut lorsque « Kind » n’est pas présent.
-
« ID » (dword) : contient le nom d’ID d’une propriété nommée par un ID. Ces informations sont requises si la clé kind est définie sur 0. Si la clé Kind est définie sur 1, ces informations sont ignorées.
-
« Type » (dword) : spécifie le type de propriété.
Cette clé de Registre est obligatoire, mais la clé de Registre n’est pas utilisée actuellement. Le tableau suivant répertorie les valeurs possibles de cette clé de Registre en fonction du type MAPI.
MAPI Type |
Valeur |
Description |
---|---|---|
PT_UNSPECIFIED |
0 |
Réservé à l’utilisation de l’interface (le type n’est pas important pour l’appelant) |
PT_NULL |
1 |
Valeur de la propriété NULL |
PT_I2 |
2 |
Valeur 16 bits signée |
PT_LONG |
3 |
Valeur 32 bits signée |
PT_R4 |
4 |
Virgule flottante de 4 octets |
PT_DOUBLE |
5 |
Double à virgule flottante |
PT_CURRENCY |
6 |
Int 64 bits signé (décimal avec 4 chiffres à droite de pt décimal) |
PT_APPTIME |
7 |
Heure de l’application |
PT_ERROR |
10 |
Valeur d’erreur 32 bits |
PT_BOOLEAN |
11 |
Boolean 16 bits (valeur différente de zéro) |
PT_OBJECT |
13 |
Objet incorporé dans une propriété |
PT_I8 |
20 |
Entier signé de 8 octets |
PT_STRING8 |
30 |
Chaîne 8 bits terminée par null |
PT_UNICODE |
31 |
Chaîne Unicode terminée par null |
PT_SYSTIME |
64 |
FILETIME entier 64 bits avec le nombre de périodes 100ns depuis le 1er janvier 1601 |
PT_CLSID |
72 |
OLE GUID |
PT_BINARY |
258 |
Non interprété (tableau d’octets compté) |
PT_MV_UNSPECIFIED |
4096 |
|
PT_MV_NULL |
4097 |
|
PT_MV_I2 |
4098 |
|
PT_MV_LONG |
4099 |
|
PT_MV_R4 |
4100 |
|
PT_MV_DOUBLE |
4101 |
|
PT_MV_CURRENCY |
4102 |
|
PT_MV_APPTIME |
4103 |
|
PT_MV_ERROR |
4106 |
|
PT_MV_BOOLEAN |
4107 |
|
PT_MV_OBJECT |
4109 |
|
PT_MV_I8 |
4116 |
|
PT_MV_STRING8 |
4126 |
|
PT_MV_UNICODE |
4127 |
|
PT_MV_SYSTIME |
4160 |
|
PT_MV_CLSID |
4168 |
|
PT_MV_BINARY |
4354 |
Voici un exemple de définition d’une propriété nommée par chaîne :
Nom : « MyStringFieldName1 »
Type : PT_LONG
[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\AllowedNamedProps\{00020329-0000-0000-C000-000000000046}\MyStringFieldName1] « Type"=dword:00000003
Voici un exemple de définition d’une propriété nommée par ID :
ID : 0x0330
Type : PT_LONG
[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\AllowedNamedProps\{00020329-0000-0000-C000-000000000046}\MyMAPIProp1] « Kind"=dword:00000000 « ID"=dword:00000330 « Type"=dword:00000003
Pour ces deux exemples, le registre ressemble à ce qui suit dans l’Éditeur du Registre :
{00020329-0000-0000-C000-000000000046}
MyStringFieldName1
Type = 3
MyStringFieldName2
Type = 3
{00020329-0000-0000-C000-000000000046}
MyMAPIProp1
Type = 0
ID = 330
Type = 3
MyMAPIProp2
Type = 0
ID = 331
Type = 3
Non recommandé : réactivez la possibilité de créer des propriétés
Trois clés de Registre peuvent être déployées sur les ordinateurs clients pour désactiver le blocage des propriétés personnalisées et rétablir le comportement précédent d’Outlook. Ces clés de Registre sont prises en charge par les stratégies de groupe. Les clés de Registre suivantes peuvent rétablir le comportement précédent d’Outlook 2003 :
Remarque Les clés de Registre suivantes ne rétablissent pas outlook 2007 à son comportement précédent.
-
AllowTNEFtoCreateProps (HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\Mail] « AllowTNEFtoCreateProps"=dword:00000000) : si la valeur est 0, TNEF/MIME ne peut pas créer de propriétés personnalisées non Outlook. Cette valeur est la valeur par défaut. Si la valeur est 1, TNEF/MIME peut créer des propriétés personnalisées non Outlook.
-
AllowMSGFilestoCreateProps : si la valeur est 0, les fichiers .msg et .oft ne peuvent pas créer de propriétés personnalisées autres qu’Outlook. Cette valeur est la valeur par défaut. Si la valeur est 1, les fichiers .msg et .oft peuvent créer des propriétés personnalisées non Outlook.
-
DisallowTNEFPreservation : pour faciliter la migration vers ce nouveau comportement, Outlook conserve le TNEF d’origine lorsque les propriétés personnalisées ne sont pas créées. Le TNEF d’origine est enregistré dans un flux binaire sur l’élément enregistré. Outlook utilise la balise de propriété suivante pour enregistrer le flux :
PR_TNEF_UNPROCESSED_PROPS PROG_TAG(PT_BINARY, 0x0e9C). The HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\Mail] « DisallowTNEFPreservation « =dword:0000000000
Le paramètre de registre contrôle si Outlook crée la propriété PR_TNEF_UNPROCESSED_PROPS.
Remarque La propriété PR_TNEF_UNPROCESSED_PROPS est supprimée d’un message lorsque vous incorporez un message dans un autre message en tant que pièce jointe. La propriété PR_TNEF_UNPROCESSED_PROPS est également supprimée lorsque vous transférez un message ou répondez à un message.