INFOPATH : Prochaine version de SharePoint

La bonne nouvelle du jour nous provient du blog Office qui confirme qu'InfoPath sera toujours présent dans SharePoint vNext (Aka SharePoint 2016). Il sera de même toujours disponible dans Office 365.

 

Voici l'article officiel:

http://blogs.office.com/2014/01/31/update-on-infopath-and-sharepoint-forms/

 

Il faut voir dans cette annonce un retard (voir un abandon) dans la solution alternative proposée par Microsoft lors de la SharePoint Conference nommée "FoSL" (Form on SharePoint List).

Ceci a été confirmé dans la roadmap d'Office 365 fournie par MS:

http://roadmap.office.com/en-us#C-164-5095

 

Microsoft souhaite proposer une réelle alternative à InfoPath dans SharePoint. En effet, il est utilisé par la plupart des entreprises disposant de la CAL entreprise de SharePoint. De plus, la possibilité depuis SP2010 de personnaliser les formulaires de listes a accru ce succès.

Il faudra donc encore attendre un peu de temps afin de disposer d'un outil permettant de migrer ces formulaire vers une nouvelle technologie.

 

En revanche, InfoPath 2013 restera bien la dernière version du produit et sera donc compatible avec SP2016.

INFOPATH 2013 : Rediriger un formulaire

Une demande récurrente dans la conception des formulaires InfoPath Forms Services est la possibilité de rediriger le formulaire vers une URL spécifique lors de l'enregistrement, la fermeture ou l'annulation du formulaire.

 

Il existe une méthode "classique" qui consiste à modifier l'adresse dans le paramètre "Source" de l'url du formulaire. Lorsque le formulaire se ferme, vous êtes automatiquement redirigé vers la valeur précisée dans le paramètre source.

Cette technique fonctionne très bien uniquement lorsque que vous restez sur votre tenant SharePoint.

Si vous devez préciser une URL externe, il sera nécessaire de passer par une page intermédiaire stockée dans SP. Afin de contourner le problème de limitation d'une redirection vers une url externe, vous pouvez suivre les étapes suivantes:

• Créer un fichier ".aspx" sur votre PC,
• Dans ce fichier, insérer uniquement une balise JavaScript et insérer le code de redirection suivant : "window.location="monurl":

• Télécharger ce fichier dans une bibliothèque SharePoint en l'approuvant ou le publiant si nécessaire,
• Faire pointer le paramètre "Source" de l'url de votre formulaire vers l'adresse de ce fichier.

 

Note : Si vous concevez un fichier HTML (à la place d'une page ASPX), celui-ci ne sera pas être ouvert directement par SharePoint et il vous sera demandé de le télécharger. Ce comportement reste tout de même modifiable en changeant le mode de sécurité de l'application web de 'Strict' à 'Permissif' (attention cette option n'est pas disponible sur Office 365).

 

 

Ceci est une version basique fonctionnant sur SharePoint 2013 et Office 365. Il serait possible d'être plus intelligent et dynamique en réalisant des redirections en fonction:

• de valeurs du formulaire (interrogation via JSOM),
• du type de formulaires,
• du type d'utilisateurs,...

Pour cela, il suffira uniquement de passer les paramètres souhaités à la page de redirection qui comprendra l'intelligence métier.

INFOPATH : Publication de champs dans SharePoint

Lors de l'utilisation de formulaires InfoPath, il est possible de "promouvoir" certains champs dans SharePoint. Ces informations pourront ainsi apparaître dans les vues SharePoint car ils seront automatiquement ajoutés en tant que champ de la liste ou bibliothèque SP.

Pour se faire, il existe 2 méthodes:

• Passer par l'interface de publication de formulaires (Fichiers > Publier),
• Passer par les "Options du formulaire" puis l'onglet "Promotion de propriétés".

Une fonctionnalité sympathique est de pouvoir définir la possibilité de modifier la valeur d'un champ du formulaire InfoPath via le formulaire d'édition natif de SharePoint ou le mode feuille de données. Cela peut-être très utile:

• Lorsque la modification ne nécessite pas de rouvrir le formulaire.
• Lorsque vous souhaitez mettre en place des flux de travail (Workflow) devant modifier la valeur du champ du formulaire (par exemple : date de validation, etc).

Pour cela, il suffira de cocher via l'interface de publication de formulaires la case "Allow users to edit data in this field" (attention, cette option n'est pas disponible via l'interface de promotion des propriétés dans les options du formulaire).

INFOPATH 2013 : Retour à la ligne

De nombreux utilisateurs d'InfoPath souhaitent formater les zones de texte multiligne en y insérant des retours-chariot à leur convenance. Malheureusement, cette fonctionnalité n'est pas disponible nativement dans InfoPath.

Mais la bonne nouvelle c'est qu'elle peut-être facilement réalisée en utilisant une simple connexion de données InfoPath.

 

 

Pour se faire, il faudra créer le fichier XML suivant:

Il indique la définition des caractères spéciaux permettant de réaliser le retour-chariot.

 

Ensuite, via le menu "Données", il faudra ajouter ce fichier en fichier de ressources (il sera ainsi intégré dans le formulaire) :

 

Puis, créer une connexion de données basée sur ce fichier local afin qu'InfoPath puisse l'utiliser via XPath:

 

 

 

Une fois la connexion de données réalisée, vous obtiendrez une nouvelle source secondaire:

 

 

 

Il ne restera plus qu'à utiliser la concaténation suivante sur le contrôle de zone de texte multiligne (par exemple en utilisant la valeur par défaut):

 

 

 

Le résultat sera le suivant: La zone de texte multiligne effectue un retour à la ligne comme nous souhaitons.



INFOPATH 2013 : Fonctionnalité valeurs par défaut

Aujourd'hui un article sur une fonctionnalité souvent méconnue et inexploitée dans InfoPath (de 2007 à 2013) : l'utilisation de valeurs par défaut.

 

Cette fonctionnalité en apparence anodine est bien pratique et permet d'éviter d'ajouter du code personnalisé dans vos formulaires.

Par exemple, pour faire echo à une question posée récemment: Comment dire à InfoPath de créer automatiquement X lignes dans un tableau extensible à l'ouverture du formulaire.

 

La solution de facilité consisterait à réaliser un bon de code managé pour réaliser ce besoin. Néanmoins ce problème peut-être adressé via les fonctionnalités natives d'InfoPath. Pour se faire, il faudra insérer votre tableau ou section extensible dans la structure du formulaire puis suivre les étapes suivantes:

• Se positionner dans l'onglet "Données" dans InfoPath Designer,
• Sélectionner "Valeur par défaut" comme ci-dessous:

• Se positionner sur la donnée extensible puis réaliser un clic droit pour ajouter autant de lignes que vous le souhaitez au démarrage de votre formulaire (par exemple ici je souhaitais charger le formulaire avec 3 lignes dans mon tableau extensible).

 

• Et voila, le tour est joué! Le formulaire disposera ainsi de 3 lignes par défaut à l'ouverture du formulaire (il vous suffira d'aller dans les options de la zone extensible afin de préciser le comportement souhaité : l'utilisateur peut ajouter, supprimer des lignes,...):

 

INFOPATH 2013 : Gestion des pièces jointes

Aujourd'hui un post sur un problème récurrent rencontré par les utilisateurs d'InfoPath et plus généralement InfoPath Forms Services : La gestion des pièces jointes.

 

Nativement, les pièces jointes téléchargées via le formulaire sont stockées dans le XML de l'instance. 

Cela implique généralement une quadruple problématique pour les utilisateurs :

1. Le formulaire est alourdi par cette pièce jointe encodée dans le XML,
2. Le temps de chargement du formulaire est grandement dégradé,
3. La gestion de la sécurité du document (droit de modification, lecture ou confidentiel) ne peut pas être décorrélée de celle du formulaire,
4. Les pièces jointes insérées dans le formulaire ne sont pas indexées via le moteur de recherche.

Note : Les formulaires de "liste" modifiés via  InfoPath ne sont pas concernés par le sujet car ils héritent du fonctionnement natif des listes SharePoint.

 

En tant que solution de contournement à ces problématiques, je conseille généralement (lorsque le besoin s'y prête) de réaliser un peu de code managé permettant de changer légèrement le fonctionnement du contrôle.

Le fonctionnement devient ainsi le suivant:

1. La pièce jointe est téléchargée dans le formulaire,
2. L'évènement "Changed" est déclenché dans le code managé dès l'ajout du fichier dans le contrôle,
3. Le code associé à cet évènement dépose la pièce jointe dans une bibliothèque de document SharePoint (possibilité de stocker dans un fichier dédié, nettoyage du nom de fichier, gestion des autorisations,...),
4. Alimentation d'une section extensible pour afficher la liste des fichiers associés à l'intérieur du formulaire,
5. Suppression du fichier dans le contrôle de pièce jointe du formulaire.

 

 

Voici le rendu:

 

Nous pouvons voir que :

• Le contrôle des pièces jointes reste vide. Le données ne sont pas stockées dans l'instance de formulaire elle-même => Optimisation du temps d'ouverture et de traitement,
• Les fichiers sont ajoutés dans une bibliothèque SharePoint (ce qui permet de les regrouper, gérer leur sécurité, les rendre indexable,...) => Plus grande flexibilité sur les règles de gestion métier,
• La suppression de fichiers depuis le formulaire via le petit bouton rouge (nécessitant quelques lignes de code managé sur le clic du bouton) est aussi prévue.

N'hésitez pas à me contacter si besoin.

INFOPATH 2013 : Vue sur formulaire de liste

Aujourd'hui un article sur les formulaires de listes version InfoPath très souvent utilisés dans SP2013.
En effet, il est possible de modifier les formulaires de liste natifs SharePoint par leur équivalent en version InfoPath. Pour cela, il suffit de cliquer sur le bouton "Personnaliser le formulaire" présent dans l'onglet "Liste" du ruban.

 

Les avantages de ces formulaires vis à vis des formulaires natifs de SharePoint sont nombreux et nous pouvons retenir les arguments suivants:

• Facilité de personnalisation du rendu de l'information (tableaux, conditions de formattage, validation de contrôles,...).
• Facilité de conception (cascading sur des zones de listes déroulantes, réception de données,...).

Il est aussi utile de pouvoir distinguer la personnalisation de ces affichages selon que l'on soit en édition ou en lecture sur l'élément de liste ("Edit" vs "Display").
Par défaut, InfoPath créé une vue "Edit" qui gère à la fois les 2 modes.

Pour séparer les affichages selon le mode d'utilisation (conception ou affichage), il suffit de se laisser guider par le concepteur d'InfoPath parfaitement intégré à SharePoint :

• Créer une nouvelle vue via l'onglet "Création de page" ou "Page Design" :

 

 

• Se positionner sur le menu "Fichier" puis aller dans "Options du formulaire" ou "Advanced form options" :

 

• Sélectionner votre vue d'affichage dans la zone de liste déroulante comme ci-dessous :

INFOPATH : Saisir plusieurs éléments de listes

Aujourd'hui un article sur une fonctionnalité souvent méconnue de SharePoint.

Lors de l'utilisation de listes SharePoint, il est possible de réaliser un formulaire permettant de saisir plusieurs éléments en une seule fois. Cela peut être réalisé simplement via InfoPath.
En revanche, il n'est pas possible d'utiliser cette fonctionnalité en cliquant sur "Modifier le formulaire" depuis une liste SharePoint. Pour se faire, il faudra créer le formulaire directement depuis InfoPath en sélectionnant le modèle "Liste SharePoint":

 

 

 

Ensuite, lors de la création de la connexion à la liste, il faudra sélectionner "Gérer plusieurs éléments de liste avec ce formulaire":

 

 

Ainsi, vous pourrez vérifier que les éléments sont incorporés dans une section extensible:

Il sera ainsi possible de saisir plusieurs éléments en une seule fois.
 

INFOPATH 2013 : Arrondir les décimales

Aujourd'hui un article sur un besoin récurrents des utilisateurs d'InfoPath. Lors de l'utilisation de champs décimaux, il est primordial de limiter le nombre de caractère après la virgule (notamment lors de saisie de montants monétaires).

Pour cela, il n'existe pas de fonction "Out Of The Box "mais il existe la bonne vieille méthode de l'arrondi. Il faudra ajouter une règle sur votre champ décimal afin de réaffecter la valeur:

arrondi(. * 100) * 0,01

 

où le point désigne en XPath le champ sur lequel s'applique la règle

 

Si vous souhaitez conserver 2 chiffres après la virgule maximum, il sera nécessaire de:

• Multiplier votre champ par 100,
• Appliquer la fonction arrondi sur cette nouvelle valeur afin de n'avoir aucune décimale. Cette fonction arrondi en effet un nombre à l'entier le plus proche,
• Diviser la valeur obtenue par 100 (ou multiplier par 0.01).

 

Voici le rendu final de la règle sur votre champ décimal:

 

INFOPATH 203 : Personnalisation formulaire de liste

Aujourd'hui un petit post relatif à InfoPath 2013 dans SharePoint suite à un problème remonté par un utilisateur.

 

Problème :

Une liste personnalisée est créée dans une collection de sites dans SharePoint 2013.

Ensuite, le formulaire de liste est modifiée via InfoPath 2013 (via l'action "Customize form" dans le ruban de la liste). Le formulaire est publié dans la bibliothèque afin de prendre en compte la publication.

Lors de la tentative suivante de modification du formulaire de liste à l'aide d'InfoPath, le message d'erreur suivant apparait à l'ouverture du formulaire:

 

InfoPath cannot open the following form:

http://intranet/sites/Processus/Lists/MaListeCustom/Item/template.xsn

The file is not a valid XML document.
DTD is prohibited.

 

Solution :

Techniquement, cette erreur survient lorsque vous utilisez une collection de sites SharePoint (ici "sites/Processus") non située à la racine de la web application.

Si vous souhaitez corriger cette erreur, il faudra obligatoirement créer une collection de sites à la racine de la web application ("/"). Cela vous permettra de pouvoir modifier à nouveau le formulaire de liste (même si cette collection de sites racine ne sert à rien).

Cela fait partie du comportement par défaut d'InfoPath Forms Services depuis SharePoint 2007, qui nécessite pour la publication de disposer d'une collection de sites racine.
La résolution est simple mais vous permettra d'économiser de nombreuses heures de debug...

 

INFOPATH 2013 : Gestion des pièces jointes

Un problème récurrent d'InfoPath Forms Services (en mode web) réside dans sa gestion des pièces jointes.

En effet, par conception, les pièces jointes insérées dans un formulaire InfoPath web sont encodées en mode base64 et stockées à l'intérieur de l'instance XML.

Autant dire que le XML enregistré est à peu de chose prêt de la taille des pièces jointes insérées dans l'instance.

Ceci entraines des lenteurs à l'enregistrement des données et à l'ouverture du formulaire. Dans le cas de grandes pièces jointes, cela entrainera même des erreurs de timeout.

Il est cependant possible de modifier la configuration d'InfoPath Forms Services dans l'administration centrale afin de corriger ce problème.

 

Cependant, il est à noter que si vous devez concevoir un formulaire simple (moins d'une 30aine de champs), il est possible de s'orienter vers un formulaire de liste SharePoint personnalisé avec le concepteur InfoPath:

 

 

 

L'avantage majeur est que le contrôle de gestion des pièces jointes est complètement intégré à SharePoint car il utilise le contrôle natif permettant d'insérer les pièces jointes dans la section "Attachment" de l'élément de liste SharePoint :

 

Ainsi l'élément de liste n'est pas impacté par la taille de la pièce jointe.
 

SHAREPOINT 2013 : Futur InfoPath

Comme beaucoup de personnes l'ont constaté, la nouvelle version d'Office 2013 et de SharePoint 2013 n'apportent quasiment aucune nouveauté au niveau des formulaires INFOPATH.

Il n'en fallait pas plus pour que de nombreuses personnes s'interrogent sur le futur d'InfoPath dans SharePoint. Va t'il passer à la trapinette comme le regretté Silverlight?

 

Le responsable marketing produit de Microsoft 'Keenan Newton' a levé le voile dans cet article : http://blogs.office.com/b/sharepoint/archive/2013/03/04/options-to-create-forms-in-sharepoint-2013.aspx

 

Voici les outils permettant de créer des formulaires dans SharePoint:

• InfoPath : Les formulaires InfoPath peuvent toujours être utilisés et constituent actuellement la solution la plus efficace pour construire des formulaires puissants (code managé, sections extensibles, signatures numériques, pièces jointes...). Il est de même possible de la coupler à des workflow d'entreprise (SharePoint Designer,WF,...).
• Access Services : Ce produit est vendu sur le papier comme le remplaçant d'InfoPath grâce à sa facilité d'utilisation et sa compatibilité HTML5. Après quelques tests, il s'avère que cette solution est clairement très loin derrière InfoPath. La palette de contrôles disponible est ridiculement pauvre et il n'est pas possible actuellement de réaliser du code managé (retour aux macros) ou d'intégrer des workflows.
• Excel Forms : Excel web apps comprend à présent l'intégration de formulaires Excel. Cela permet de réaliser des formulaires basiques (enquêtes,...). Voir exemple ici : http://cwebbbi.wordpress.com/2012/07/23/creating-surveys-using-excel-2013-forms/
• Visual Studio : Il est possible de développer des formulaires en utilisant le nouveau concept introduit dans SharePoint 2013 : les apps. Nous ne détaillerons pas cette notion qui constitue un sujet à part entière. Cette solution nécessite des compétences en programmation et n'est donc pas adaptée à une utilisation de masse dans une entreprise.
• Solutions tierces : Les éditeurs "Nintex" ou "Formotus" pour ne citer qu'eux. Nintex est une solution complète permettant de réaliser des formulaires et des flux de travail assez simplement. Le point positif reste la possibilité de concevoir des formulaires s'adaptant aux devices (Windows Phone, Andoid, IPhone, Ipad). Le point négatif des formulaires Nintex est qu'il faut utiliser beaucoup de JQUERY pour arriver au potentiel d'InfoPath.

 

 

Autant dire qu'InfoPath dispose encore de beaux jours devant lui ! Cela n'engage que moi mais au jour d'aujourd'hui, les solutions alternatives n'apportent aucune plus value comparativement à InfoPath.

Office 365 : InfoPath GetUserProfileByName

Aujourd'hui un court article sur une limitation découverte sur InfoPath Forms Services dans le cadre d'Office 365 lors de la tentative d'utilisation d'un service web SharePoint.

 

La méthode "GetUserProfileByName" permet de retrouver facilement les informations de l'utilisateur connecté sur SharePoint en recherchant les données depuis sa fiche de profil.

L'appel de cette méthode depuis un formulaire InfoPath Forms Services génère une exception (error 5566 ou 401).

 

En effet, celui-ci n'est pas accessible depuis InfoPath dans Office 365 à cause du paramétrage de désactivation de la protection de bouclage ("DisableLoopBackCheck").

Cela fonctionne généralement sur les serveurs SharePoint On Premise car la clé de registre "DisableLoopBackCheck" est positionnée à "1".

 

Voici un article du support MS répertoriant ce problème :

http://support.microsoft.com/kb/2674193

 

Malheureusement, pour des raisons de sécurité évidentes du côté de chez Microsoft, cette contrainte semble immuable. Autant prédire qu'il y ait peu de chances que cette utilisation dans O365 soit un jour possible ...

 

Il reste donc 2 solutions de contournement aussi contraignantes l'une que l'autre:

• Réaliser un formulaire "client lourd" se connectant à ce web service car cela fonctionne avec cette méthode (Inconvénient : Les utilisateurs devront posséder InfoPath sur leur poste),
• Utiliser une liste SharePoint comprenant les informations nécessaire (Inconvénient : duplication de l'information).

INFOPATH 2013 : Enregistrement personnalisé

Aujourd'hui un petit article permettant de détailler l'enregistrement d'un formulaire dans une bibliothèque SharePoint.

 

Rappel : Pour enregistrer le formulaire à la racine de la bibliothèque, il suffit de créer une connexion de données de type "Envoi" vers la bibliothèque de votre choix.

Afin de facilité le déploiement, il est préconisé d'utiliser un fichier "udcx" (universal data connexion) permettant de ne pas laisser l'url d'enregistrement stockée en dur dans le modèle du formulaire). Pour le passage vers un environnement différent, vous aurez uniquement à modifier le contenu du fichier UDCX stocké dans une bibliothèque SharePoint de type "Bibliothèque de connexion".

 

 

Pour plusieurs raisons, notamment pour se conformer aux 'bests practices' de Microsoft, vous pouvez être amené à enregistrer le formulaire dans un répertoire spécifique de votre bibliothèque de formulaire.

Par exemple, si vous partez sur une volumétrie de 2000 formulaires par an, il est préconisé de créer un répertoire par année dans votre bibliothèque.

 

Pour enregistrer votre formulaire dans un répertoire spécifique de votre bibliothèque de formulaire, il suffira d'utiliser le code C# suivant dans l'évènement "Forms_Submit" du formulaire :

 

FileSubmitConnection fileSubmitConnection = (FileSubmitConnection)DataConnections["Envoi formulaire demo "];
fileSubmitConnection.FolderUrl = string.Concat(fileSubmitConnection.FolderUrl, "/", "MonRepertoire");

fileSubmitConnection.Execute();
e.CancelableArgs.Cancel = false;

 

Ainsi, le formulaire s'enregistrera directement dans le répertoire "MonRepertoire" de la bibliothèque de formulaires.

 

INFOPATH 2013 : Clear Cache

Lorsque vous ouvrez un formulaire InfoPath, le modèle est mis en cache sur votre machine: dans le répertoire local de l'utilisateur ("C:\Documents and Settings\[UserSession]\Local Settings\Application Data\Microsoft\InfoPath").

 

Lorsqu'une nouvelle version du formulaire est déployée (en local ou sur SharePoint), InfoPath détecte le changement et ouvre la dernière version du formulaire.

Dans certains cas, le formulaire précédemment mis en cache peut poser problème et bloquer la mise à jour automatique (par exemple lorsque les anciennes connexions de données à l'ouverture ne sont plus accessibles).

 

Pour réaliser manuellement cette action, il vous suffira de lancer la commande suivante:

 > Menu Démarrer > Exécuter > "Infopath /cache clearall"

 

Ainsi tous les formulaires présents dans le cache de l'utilisateur seront supprimés et la dernière version publiée du formulaire sera utilisée.

INFOPATH 2013 : Utiliser du code managé

Aujourd'hui un court article sur InfoPath 2013. Une nouveauté très importante pour les développeurs a fait son apparition : l'éditeur de code managé fait peau neuve !

 

Pour faire un peu d'histoire, InfoPath a connu les mises à jour suivante en terme d'éditeur de code:

• InfoPath 2003 : Editeur inexistant... Oups,
• InfoPath 2003 SP1 : Possibilité d'utiliser du code managé dans Visual Studio 2003 (ça ne rajeunit pas tout ça...),
• InfoPath 2007 : Composant "Visual Studio Tools for Applications" (VSTA) ou "Visual Studio Tools for Office" (VSTO : qui permettait d'utiliser un modèle de projet VS),
• InfoPath 2010 : Composant "Visual Studio Tools for Applications" (VSTA) alors que le modèle VSTO disparait dans le même temps... Ainsi l'interface utilisée en 2010 était celle de Visual Studio 2005!
• InfoPath 2013 : Nouveau composant "Visual Studio 11 Tools for Applications", youpi!

 

Pour pouvoir consulter cet éditeur, il faudra se placer sur l'onglet "Développeur" en mode "Conception" puis cliquer sur le bouton code :

 

Ainsi, vous pourrez apercevoir cette pop-up apparaitre:

 

 

 

Elle indique qu'il faut télécharger "Microsoft Visual Studio for Application" (le VSTA) en version 11. Celui-ci est disponible à l'adresse suivante : http://www.microsoft.com/en-us/download/details.aspx?id=30364

 

Ce nouvel outil nous permet à présent d'utiliser le Framework 4.0, ce qui est une excellente nouvelle.

 

 

Un nouveau post fera suite à la découverte des nouvelles opportunités offertes par cette nouvelle mouture.

 

INFOPATH 2013 : Managed Metadata limitation

InfoPath 2013 est à présent disponible en version preview depuis quelques jours.
L'occasion de tester cette nouvelle mouture d'InfoPath couplée à SharePoint 2013 était trop belle.

L'un des premiers tests que j'ai réalisé était la personnalisation d'un formulaire de liste avec InfoPath 2013. Cette fantastique fonctionnalité est toujours implémentée dans SharePoint 2013 et fonctionne à merveille dans 99% des cas.

Je suis malgré tout tombé sur une limitation en utilisant une liste contenant un champ de type métadonnées gérées. Il s'avère actuellement impossible de personnaliser en utilisant InfoPath le formulaire d'une liste contenant ce type de champs. En effet l'erreur suivante apparait:

où "MetaDataColumn_Remi" correspond à un type de champ Métadonnées gérées présent sur cette lsite. Le message d'erreur est donc explicite...

Nous attendrons la version finale de SharePoint Server et de Microsoft Office pour confirmer cette rare limitation.