SharePoint : XmlFormView (Part 2)

Un petit post pour noter la présence d'un effet de bord repéré lors de l'utilisation de la webpart XmlFormView détaillée précédemment.

Problème :

Le problème porte sur les pièce jointes. Cette webpart ne permet pas dans sa version classique de pouvoir télécharger une pièce jointe dans le formulaire.

Cause :

Cela est du à un problème d'encodage qui n'est pas défini dans le contrôle du formulaire. (Pourtant cela marche lorsque le formulaire est ouvert depuis la page classique "FormServer.aspx".

Résolution :

Suivre les étapes suivantes pour corriger cet effet: 

- Ajouter en dessous de cette webpart une nouvelle webpart de type Edition de contenu (CEWP). 

- Cliquer "Modifier le composant WebPart partagé",

- Cliquer sur le bouton "Editeur de code source" et ajouter la ligner suivante dans une balise javascript: "document.forms[0].encoding='multipart/form-data';"

Cette technique de la content editor webpart permet d'ajouter n'importe quel bout de javascript à la page. Ce qui est bien souvent utile avec SharePoint...

SharePoint : XmlFormView (Part 1)

Aujourd'hui, un petit detour sur une solution permettant de hoster un formulaire InfoPath dans des pages de votre site SharePoint: la solution XmlFormView.

Cette solution à plusieurs avantages:

- Eviter l'écran "Chargement de votre formulaire" étant donné que le formulaire est déja chargé dans la page.

- Auto ajustement en largeur et longueur (contrairement à une visionneuse de page),

- Intégration dans la page en gardant la présentation de votre site SharePoint,

- Possiblilité de développer un formulaire InfoPath et de l'incorporer au site comme une simple page aspx.

Le problème est que cette webpart est cachée dans SharePoint.

Pour pouvoir l'utiliser, il faut aller modifier le web.config associé à votre application web et rajouter la balise suivante:

"SafeControl Assembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.Office.InfoPath.Server.Controls" TypeName="*" Safe="True""

Ensuite, il faut activer cette webpart sur la collection de sites:

- Aller dans la galerie des webpart de votre site ("Actions/Paramètres du sites/Composant webpart"),

- Cliquer sur "Nouveau".

- Sélectionner "Microsoft.Office.InfoPath.Server.Controls.XmlFormView",

- Cliquer sur compléter la galerie.

La webpart est à présent accessible et utilisable dans la liste des webpart.

Il suffit de renseigner le XsnLocation dans le paramètrage de la webpart et vous êtes parti.

Enjoy!!!

Microsoft Techdays

Les techdays arrivent à grand pas et se dérouleront les 8, 9 et 10 février 2010 au Palais des Congrès de Paris. L’occasion d’avoir une bonne vision d’ensemble des nouveautés Microsoft.

Pour les intéressés voici le programme concocté pour ce cru 2010:
http://www.microsoft.com/france/mstechdays/programmes/default.aspx

Toutes les dernière technologies seront au rendez-vous dont une session bien sympathique concernant “Office 2010, SharePoint 2010 et Office Web Apps”.

Que du lourd en perspective!

INFOPATH : Deployer en wsp

Je suis tombé très récemment sur un outil de déploiement de formulaire nommé "InfoPathFormsManager" sur CodePlex à l'URL suivate "http://shareinfopathforms.codeplex.com/".

Un grand merci à l'éditeur qui a conçu un très bel outil.

Ce projet peut-être très utile dans le cas de formulaires FormServer à déployer par l'administration centrale.
Il permet de déployer son formulaire en tant que wsp.

Les avantages sont les suivants:
- Ne pas avoir de guid au niveau du nom de la solution dans l'administration centrale (ce qui mine de rien devient très pénible sur un serveur de production!!!).
- Regrouper les livrables en un seul wsp de manière à garder un gestionnaire des solutions propre (par exemple formulaire, workflow, eventhandler, timerjob,...).
- Possibilité de publier plusieurs formulaires en un seul wsp. (utile quand on a près de 200 formulaires!).

Pour le reste tout fonctionnera comme une solution usuelle, il faudra activer la fonctionnalité sur la collection de site puis rattacher le content-type sur la bibliothèque de formulaire souhaitée...

Le seul inconvénient que je vois est que durant l'upgrade d'une solution wsp, le formulaire ne sera plus accessible (à faire tard le soir ou tôt le matin!).
Alors qu'usuellement les solutions InfoPath permettent de travailler avec l'ancienne version le temps que la nouvelle soit publiée (gestion des versions).

InfoPath : Module administration

Pour cette nouvelle année, mon premier post ira à une erreur InfoPath qui peux vite taper sur le système!

Lorsque vous publiez un formulaire InfoPath en contrôle total, le message suivant peut apparaitre à son ouverture:
"Impossible d'ouvrir le modèle de formulaire car l'administrateur système a désactivé l'ouverture des modèles de formulaire exigeant l'autorisation totale."

Cette erreur est à la fois simple et complexe!!!
En fait cela provient d'une restriction mise en place par l'administrateur système de l'entreprise (généralement ce n'est pas utilisé dans les petites structures). Il s'agit plus précisément d'une règle prédéfinie dans les modules d'administration d'Office 2007.

Voici le lien pour télécharger ces modules d'administration (un pour chaque logiciel d'office) qui s'importent dans la "gpedit":
http://www.laboratoire-microsoft.org/news-23249-telechargez-les-modeles-d-administration-pour-office-2007-fichiers-adm.html

Ces modules d'administration permettent de désactiver certaines fonctionnalités du logiciel.
Comme ici avec le contrôle total d'InfoPath ayant la clé "Active/désactive l'option Autoriser l'exécution des formulaires entièrement fiables sur mon ordinateur.".

La mise en place de cette stratégie créera une nouvelle clé dans la regedit.
Il s'agit de la DWORD nommée "RunFullTrustSolutions" et qui se trouve à l'emplacement suivant "HKEY_USERS/leuser/Software/Policies/Microsoft/Office/12.0/InfoPath/Security".