Je viens de subir un cas assez étonnant, survenant sur une instance de collection de site uniquement (et affectant donc le site racine et l’ensemble de ses sous-sites). Aucune idée de ce qui a pu générer cela … mais voici néanmoins un petit état des lieux de ma démarche.
Etat des lieux :
- L’ensemble de fonctionnalités de collection de site faisant référence aux flux de travail étaient activés (Flux de travail, Flux de travail à trois, états, Flux de travail approbation de destruction, Flux de travail d’approbation de publication, Flux de travail SharePoint 2007, Options Web Analytics avancées).
- /_layouts/wrkmng.aspx me confirme bien que l’ensemble des flux de travail sont « Actifs » (Administration de la collection de sites > Flux de travail).
Deux états de faits :
- Lorsque j’essayais d’associer un flux de travail (via un compte administrateur de la collection de site) sur une bibliothèque de documents je n’ai à ma disposition que les flux de travail trois états et l’approbation de destruction de disponible. J’ai difficilement trouvé une source à mon soucis, mais pas de solution à l’horizon : Only Deposition Workflow is avaliable in SharePoint 2010
- Lorsque je m’amusais à ouvrir le site racine via SPD je n’ai aucun « Globaly Reusable Workflow / Flux de travail réutilisable globalement » de disponible.
J’ai pu reproduire ce mode de fonctionnement (sauf côté SPD) en désactivant les flux de travail définis par l’utilisateur (Centrale d’administration > Paramètres généraux de l’application web > Flux de travail). Comme indiqué en introduction, seule une collection de sites était touchée par ces soucis.
J’ai, une énième fois, désactivé l’ensemble des fonctionnalités de collections de sites liées aux flux de travail (voir ci-dessus). A la réactivation de n’importe laquelle des fonctionnalités suscitée, j’ai eu le droit au message d’erreur suivant :
Une liste, une enquête, un forum de discussion ou une bibliothèque de documents avec le titre spécifié existe déjà dans ce site Web. Veuillez choisir un autre titre.
Il était clair que l’activation de ces fonctionnalités étaient interrompus par un processus de création. L’ordre de désactivation a t’il généré cette erreur ? aucune idée. Néanmoins, en fouillant un peu ici et là, j’ai rapidement pu retrouver mes petits. A priori, tout se trouve concentré au niveau de la bibliothèque _catalogs/wfpub. Via SPD j’ai rapidement pu constater que, même si celui-ci existait, il n’était pas considéré comme étant une bibliothèque de documents SharePoint (et son icône associé). Une fois ce dernier renommé (en wfpub_old), les fonctionnalités ont de nouveau pu être redéployées. Par la même, les flux de travail étaient à nouveau activable.
Rien ne me permet d’affirmer la cause de ces dysfonctionnements. Je n’ai pas non plus poussé le vice à chercher/trouver les causes de tout cela, mais à force d’habitude, une certaine connaissance des méandres de SharePoint permet de s’affranchir de problèmes qui peuvent, à priori, sembler bloquants voir difficilement surmontables.
Dans le cadre d’un projet de site de publication (Internet voir Intranet/Extranet), une demande revient invariablement : gérer l’affichage du ruban Office.
En effet, et ce malgré des droits gérés au plus juste, vous aurez quoi qu’il arrive un minimum d’informations affichées dans la zone du ruban Office. En l’occurence :
- Bien évidemment, le ruban Office (incluant ses différents onglets)
- Le bouton « Actions du site »
- Le fil d’Ariane (Breadcrumb)
- Le bouton de paramètres utilisateurs/déconnexion
- Des choses plus « exotiques » comme le bouton du développeur dashboard ou le bouton de modification de pages
Partons du principe que tous les éléments cités n’ont pas à être affichés sur notre site de publication pour les non-administrateurs (on pourrait aussi exclure les personnes non-authentifiés dans le cas d’un site Web exposé en anonyme).
Pour nous permettre de masquer les éléments suivants les droits des utilisateurs, nous allons donc utiliser la propriété PermissionsString via un contrôle SPSecurityTrimmedControl (l’article énumère les types de permissions possible). Pour l’exercice, nous allons englober le contrôle SPRibbon comme suit (n’oubliez pas la balise fermante après </SharePoint:SPRibbon) :
<SharePoint:SPSecurityTrimmedControl runat="server" PermissionsString="ManageWeb">
Dans le cas présent, nous pouvons constater que seul le bloc lié au ruban est encore visible.
Supprimez ce que nous venons de faire, essayons-donc de passer un niveau en dessous. Le PermissionsString pouvant être appliqué directement au contrôle SPRibbon, il nous suffit de modifier la page maître de notre site de publication comme suit :
<SharePoint:SPRibbon runat="server" PlaceholderElementId="RibbonContainer" CssFile="" PermissionsString="ManageWeb">
Dans ce cas, l’ajout de cette propriété permet effectivement de ne pas charger le bandeau.
Essayons maintenant de faire disparaître ce bandeau supérieur. Pour se faire utilisons un SPSecurityTrimmedControl sur le div englobant le ruban. A savoir, <div id= »s4-ribbonrow »>.
Vous devriez vite constater que les barre défilement de votre site réagissent bizarrement, empêchant par la même vos utilisateurs de faire défiler vos pages Web. Cela est dû au fait que la balise <DIV> s4-ribbonrow ne soit plus chargée. Sans rentrer dans les différents détails de chargement inhérent aux classes CSS appliquées, nous allons essayer de feinter en utilisant un hack CSS.
Supprimez ce que nous venons de faire, et ajouter le bout de code suivant après le </DIV> de s4-ribbonrow :
<style type="text/css">
div#s4-ribbonrow {
display:none;
}
</style>
On retrouve le même rendu fonctionnel qu’auparavant, sauf que cette fois ci, les barres de défilement fonctionnent parfaitement. Seul soucis, vous aurez le même rendu en vous connectant avec un utilisateur ayant des droits. Pour palier à ce soucis, ajoutez après le code précédent, les lignes suivantes :
<SharePoint:SPSecurityTrimmedControl runat="server" PermissionsString="ManageWeb">
<style type="text/css">
div#s4-ribbonrow {
display:block;
}
</style>
</SharePoint:SPSecurityTrimmedControl>
Si on résume la manipulation, pour nous permettre de ne pas casser la logique de navigation de SharePoint, nous cachons seulement le ruban, que nous ré-affichons ensuite aux administrateurs.
Vous pouvez également, histoire de donner quelques autres pistes, utiliser un contrôle LoginView. Il s’agit d’une méthode qui peut paraître plus simple d’utilisation que le SPSecurityTrimmedControl, car celui-ci introduit une notion de template d’utilisateurs (LoggedInTemplate, etc.).
Dernière petite astuce. Pour en revenir aux barres défilement, si vous souhaitez vous libérer de l’ancrage du ruban en haut de page, procédez à la manipulation suivante :
- ajouter le hack CSS suivant (il faut qu’il puisse écraser la référence du CSS corev4) : body.v4master { overflow:auto; }
- supprimez la référence scroll= »no » de la balise <BODY>
- puis supprimez la référence ID= »s4-workspace” de sa balise <DIV>
Voilà, maintenant vous devriez avoir quelques bases nécessaires sur la gestion de l’affichage du ruban. Cet article est loin de faire le tour du sujet, mais permet de prendre conscience de différentes techniques et méthodes utilisées pour gérer le ruban Office … et indirectement, personnaliser vos interfaces SharePoint.
Le message est assez explicite, n’essayez pas de comprendre la notion « virtuel », ça ne fait référence qu’à votre Web Application (WA).
Donc pour résumer les alertes sont justes désactivées sur votre WA. Pour les réactiver, deux solutions :
- Via l’interface graphique de la centrale d’administration
- « Gestion des applications » > « Gérer les applications Web »
- « Paramètres généraux » > « Paramètres généraux » de votre WA
- « Alertes » > « Activer »
- Via stsadm
- stsadm -o setproperty -propertyname alerts-enabled -propertyvalue true -url <URL de votre WA>
Si vous avez toujours des problèmes d’envois des alertes, jetez un coup d’oeil du côté du Timer Job d’envoi immédiat des alertes (job-immediate-alerts).
Le workflow Out-of-the-Box intitulé « Approbation – SharePoint 2010″ permet de piloter l’approbation de contenu d’un élément, en mettant à jour son état d’approbation. Ce workflow nous met à dispositions une batterie d’options permettant de couvrir un ensemble de cas. En l’occurence, à l’association de ce flux de travail à une liste SharePoint (ou bibliothèque, etc), plusieurs options de démarrage sont donc disponibles :
- Autoriser le démarrage manuel de ce flux de travail par un utilisateur authentifié disposant des autorisations de modification d’éléments.
- Démarrer le flux de travail lorsqu’un nouvel élément est créé.
- Démarrer le flux de travail lorsqu’un élément est modifié.
Fait étonnant : lorsque l’on sélectionne le démarrage du flux de travail à la modification d’un élément, l’état d’approbation n’arrive jamais en état d’approbation « Approuvé ». Cela mérite une explication.
Lorsqu’on observe (voir capture ci-contre) les options de fin de tâche du flux de travail – via SharePoint Designer. On observe plusieurs choses :
- Il existe une conditionnelle qui teste si l’option de démarrage »démarrer le flux de travail lorsqu’un élément est modifié » n’est pas définie (égale à « Non »).
- Cette conditionnelle n’a pas d’embranchement « Sinon ». Autrement dit, si vous avez activé l’option de démarrage lié à une modification, les actions incluses dans la conditionnelle ne pourront jamais s’exécuter.
- La définition de l’état d’approbation du document en « Approuvé » (différente du statut du workflow) est définie dans cette conditionnelle.
Utiliser cette fonctionnalité nécessite donc une intervention manuelle de chaque approbateur pour approuver chaque élément (en plus du worklow et des tâches associées).
Pour palier à ce soucis il va nous falloir modifier le workflow « Approbation – SharePoint 2010″. Voici un petit mode oépratoire pour rapidement mettre en oeuvre une solution :
- Ouvrez le site sur lequel vous voulez implémenter ce workflow via SharePoint Designer 2010.
- Rendez-vous dans le menu des flux de travail, faites un clic sur « Approbation – SharePoint 2010″ et « Copier puis Modifier ».
- Cliquez sur « Modifier le flux de travail »
- Cliquez sur le processus du flux de travail : l’élément directement à droite de « Démarrer le processus »
- Cliquez sur « Modifier le comportement du processus de tâche global »
- Modifiez le workflow pour que la rubrique « Lorsque le processus de tâche se termine » ressemble à l’exemple suivant (voir catpure d’écran ci-dessous)
- Enregistrez. Publiez. Ajoutez un workflow comme à l’accoutumé, via le menu des flux de travail de votre liste ou bibliothèque SharePoint.
Les affichages personnels c’est à la fois le bien et le mal, surtout lorsque ça touche à la sacro-sainte default.aspx
« Génial on peut modifier notre page à la demande ».
« Mais où sont passés mes Web Parts ? Ca plante encore votre bousin »
Néanmoins deux petites astuces pour pouvoir vous sauver de toutes les situations :
- …/maPage.aspx?PageView=Shared : permet d’afficher l’affichage partagé
- …/maPage?PageView=Personal : à l’inverse, permet d’afficher l’affichage personnel de l’utilisateur
- …/maPage?contents=1 : permet d’afficher la page de maintenance des composants WebParts de la page. Permet, entre autre choses, de restaurer les WebParts supprimés ou fermés. Pour avoir accès à cette interface il faut un niveau d’autorisation vous octroyant « Mettre à jour des composants Web Parts personnels » (à ne pas mettre entre toutes les mains).
