Catégorie : SharePoint

CAML (WSS) : Requête avec un champ "DateTime"

Iso machin
Pour qu’une date soit exploitable dans une requête CAML, il faut qu’elle soit d’un format ISO spécifique.
Convertir la date à l’aide de cette outil du framework SharePoint :
SPUtility.CreateISO8601DateTimeFromSystemDateTime(maDate);
La requête suivante fonctionnera sans problème :
maQuery = "<Where><Geq><FieldRef Name='ChampDate' /><Value Type='DateTime'>" + SPUtility.CreateISO8601DateTimeFromSystemDateTime(maDate) + </Value></Geq></Where>";

SPQuery sur SPList.GetItems retourne tous les éléments !

Cauet rit.
Dans le bout de code suivant :

SPQuery qry = new SPQuery();
qry.Query = "<Query><Where><Eq><FieldRef Name='Champ1' /><Value Type='Number'>0</Value></Eq></Where></Query>";

SPListItemCollection myData = mySPList.GetItems(qry);
« myData » contiendra l’ensemble des enregistrements de la liste « mySPList », sans tenir compte de ma requête « Where ».
Ceci vient de la requête CAML mal formée : il faut enlever les balises « <Query></Query> ». En effet, l’objet SPQuery de charge lui-même de les ajouter.
Source : http://sharepointxperience.blogspot.com/2007/10/spquery-returns-all-items.html

SharePoint : Bug natif dans le modèle de liste "Forum de discussion"

Un paquet de CAML !
Quelque soient les droits des utilisateurs dans un forum de discussion SharePoint, le lien « Afficher les propriétés » apparait pour chaque message. Or ce lien redirige vers les propriétés du message, où il est possible de le modifier, le supprimer…
Résultat : l’utilisateur va se retrouver devant une page d’erreur quand il tentera ces actions.
Pour corriger ce dysfonctionnement natif, le mieux et de créer son propre modèle de liste DiscussionList (en copiant-collant l’original), et de corriger le fichier %FEATURE%DiscussionsListDiscussschema.xml
Dans notre cas, on va simplement afficher ce lien uniquement aux utilisateurs qui sont l’auteur du message. A la ligne 351du fichier, il faut remplacer le code défécteux par celui-ci (entre le </Switch> de la ligne 351 et le <IfHasRights> de la ligne 354) :
          <HTML><![CDATA[<td style="border-style:none" nowrap="TRUE"><div>]]></HTML>
<IfEqual>
<Expr1>
<Column Name="Author"/>
</Expr1>
<Expr2>
<UserID></UserID>
</Expr2>
<Then>
<HTML><![CDATA[<a id="DisplayLink]]></HTML>
<Field Name="ID" />
<HTML><![CDATA[" href="]]></HTML>
<URL Cmd="EDIT" />
<HTML><![CDATA[" ONCLICK="GoToLink(this);return false;" target="_self">]]></HTML>
<HTML><![CDATA[<NOBR>Afficher les propriétés</NOBR></a>]]></HTML>
</IfHasRights>
</Then>
</IfEqual>


Bien sûr, tout ceci peut être libre de toute fantaisie !

XSL / Sharepoint : "L'affichage spécifié n'est pas valide"

C’est pas du 16/9ème ?
… ou encore en anglais : « The specified view is invalid ».
Cette erreur peut intervir lorqu’on créé une DataFormWebPart (DFWP) sous le SharePoint Designer (en partant d’une webpart native (ListViewWebPart), et en la convertissant en vue XSL).
Lorsqu’on va exporter cette webpart, et l’intégrer dans une page, l’erreur va survenir. Il va alors falloir aller dans la page de maintenance et supprimer la WP.
Certains forums donneront cette solution : Editer le fichier *.webpart dans un bloc-note, et supprimer la propriété « viewflag« . Mais cette action à des effets de bord bien plus perfides.
Je pense (pour l’instant) que la meilleure chose à faire et de partir d’une source de données (au lieu d’une webpart native) pour créer sa DFWP.
 

XSL / Sharepoint : Doublons des entrées dans les filtres (DataFormWebParts)

La chose faite d’houblon.
Dans le cas de DataFormWebParts à sources de données aggrégées, il se peut que les filtres des en-têtes contiennent plusieurs fois les mêmes valeurs.
Ce petit bug d’affichage est corrigible en allant manipuler le code XSL de la page (via le SharePoint Designer).
Dans le template nommé « dvt.filterfield« , trouver une boucle for-each qui appelle le template « filteroption » :
     <xsl:call-template name="dvt.filteroption">
<xsl:with-param name="name" select="$fieldname" />
<xsl:with-param name="value" select="." />
<xsl:with-param name="type" select="$fieldtype" />
</xsl:call-template>

La boucle qui appelle ce template est censée faire un « distinct » sur les données à lister, mais ça ne fonctionne pas toujours.
Les données sont cependant triées, on va donc autoriser l’affichage de la donnée à chaque fois qu’on change de valeur dans la boucle. Pour cela, il suffit d’encadrer cet appel par la condition suivante :
     <xsl:variable name="OptionValue" select="ddwrt:NameChanged(string(.), 0)" />
<xsl:if test="string-length($OptionValue)">

          <xsl:call-template name="dvt.filteroption">
<xsl:with-param name="name" select="$fieldname" />
<xsl:with-param name="value" select="." />
<xsl:with-param name="type" select="$fieldtype" />           </xsl:call-template>
     </xsl:if>
 
NB : NameChanged teste si une valeur change depuis sa dernière affectation.

XSL / XPath / Sharepoint : Problème du double encodage des données.

L’esperluette m’a tué
J’ai rencontré ce problème en créant une « DataFormWebPart » sous le Sharepoint Designer. Les données finales affichées (HTML) étaient doublement encodées par rapport à la source de données.
Prenons cet élément d’une liste SharePoint :
L'iPad est nul
A travers une DataFormWebPart créée sous le sharepoint Designer, il ressortira ainsi
L&quot;iPad est nul
 
Cause : il y a eu double encodage : L'iPad est nul -> L&quot;iPad est nul -> L&amp;quot;iPad est nul
Et sur le navigateur, le résultat est celui-ci : L&quot;iPad est nul
 
Le problème vient du XSL, au moment d’afficher la valeur :
<xsl:value-of select="@Valeur"/>
Il faut ajouter l’attribut suivant : disable-output-escaping= »yes »:
<xsl:value-of select="@Valeur" disable-output-escaping="yes" />
 
Sans aller dans les tréfonds du code XLS, le Sharepoint designer peut aider à la tache :

  • Se mettre en mode « création »
  • Survoler l’un des éléments de la webpart
  • Changer le type d’affichage (passer le « texte brut » à « texte enrichi »).

 
 
 

MOSS 2007 : Multi-linguisme

Do you speak moss the most ?
Comment créer un site en plusieurs langues sous MOSS ?
Voici les étapes à suivre, pour la création d’un site simple, à partir de zéro :

  • Définir toutes les langues qui seront utilisées, et installer les Language Pack adéquats dans la ferme SharePoint.
  • Créer son app. web + la collection de site associée (de modèle publication). C’est au moment de la création de la collection de site que la langue principale est choisie.
  • Dans le site : Créer une première étiquette de variation (la principale, par ex le français).
  • Générer la hiérarchie.
  • Construire son site sur la variation principale.
  • Puis enfin créer les étiquette de variantes (en choisissant les langues adéquates) et générer la hiérarchie.
  • Reste à traduire les contenus dans les n variations créées.

Quelques remarques :

  • Une variation n’est qu’un sous-site synchronisé avec un site principal (la variation principale).
  • Par synchronisation, il faut comprendre que si il y a une modification, les auteurs des sous-sites variants seront alertés (workflow).

Pour en savoir plus sur les variations, voir cet article en deux parties :
Les variations – Page 1
Les variations – Page 2
Egalement trouvé sur un forum, cette bonne synthèse .

MOSS : Un bon outil de stats

Voici un outil très simple à déployer et qui permet d’avoir des stats bien plus sympa que l’outil natif de MOSS :
http://www.mapilab.com/download/
(c’est un freeware, il suffit de s’inscrire)
Entre autres :

  • Exports PDF
  • Stats sur les recherches les plus fréquentes
  • Temps de consultations
  • Présentations sous forme de courbes, tableaux (avec tris et groupement…)
  • etc……..

MOSS 2007 : Activer les statistiques d’un site

Comment accéder à de magnifiques rapports d’utilisation du site ? (camemberts, diagrammes…)
Voici les 3 manipulations à effectuer pour activer les statistiques sur un site MOSS :

  • Activer le journal de traitement de l’analyse
  •  » Admin centrale Sharepoint > Opération > Traitement de l’analyse de l’utilisation « 
  • Cocher  » Activer le journal « 
  • Emplacement : Donner (pourquoi pas) le même répertoire que les logs wss.
  • Nombre de fichiers : Nb de serveurs de BDD * 3 (préconisation MS).
  • Cocher  » Activer le traitement « .
  • Donner un intervalle de temps d’au moins 1/2 heure, le midi ou le soir.
  •  » OK « 

Dans les services partagés du site :

  • Cliquer sur « Rapports d’utilisation » dans la section « Rapports d’utilisation d’Office SharePoint ».
  • Cocher les deux cases, et faire « OK »

L’URL de la page qui va contenir les stats du site est :
http://mon_site/_layouts/SPUsageWeb.aspx