Une fois n’est pas coutume, et comme c’est depuis plusieurs années maintenant que je fais du SharePoint, j’en profite pour partager avec vous une astuce utilisant l’inclusion conditionnelle de script et contenu au sein de SharePoint 2010.

Ici, on souhaite cacher le ruban de SharePoint en mode anonyme ce qui peut s’avérer être très utile dans le cadre d’un site de publication dans un contexte WCM.

SharePoint Foundation 2010 and SharePoint Server : cacher le ruban en injectant du script en conditionnel

Evidemment, cet article répond à un cas très précis qui peut facilement être généralisé à de multiples usages.

 

A travers ce court billet, nous allons aborder deux approches :

  • La première utilisant un Delegate Control qui inclut le script masquant le ruban en code-behind
  • La seconde implique l’utilisation des contrôles SPSecurityTrimmedControl pour inclure du contenu de manière conditionnelle et c’est clairement celle ici abordée et à proposer pour un profil designer et un usage simple

 

Approche 1 : Delegate control

L’idée relativement simple consiste à utiliser un DelegateControl qui au moment du OnLoad vérifie si l’utilisateur courant est authentifié et inclure dans le cas contraire le script qui va se charger de masquer le ruban.

Pour le détail complet, veuillez vous rendre sur le site suivant :

http://articles.consultpoint.net/Pages/Using-Delegate-Controls.aspx

En très simplifié, on définit un DelegateControl qui sera utilisé dans la MasterPage et qui va inclure le script si l’utilisateur n’est pas authentifié à travers le code-behind.

protected void Page_Load(object sender, EventArgs e)
{
    if (SPContext.Current.Web.CurrentUser == null)
    {
        string scriptfile = 
"/_controltemplates/SPRibbonVisibility/RibbonVisibility.js"; ScriptManager.RegisterClientScriptInclude(this, typeof(RibbonVisibilityControl), "SPRibbonVisibility", scriptfile); } }

Il serait par ailleurs recommandé d’effectuer l’opération inverse, à savoir, en cas d’authentification, inclure les scripts affichant le menu plutôt que d’effectuer l’inverse. Voir même de remplacer le contrôle en proposant un DelegateControl dédié à l’affichage de ce menu uniquement dans des cas authentifié.

 

Approche 2 : Utilisation du SPSecurityTrimmedControl

La seconde approche n’implique pas de développement de DelegateControl ni de définition de Feature ce qui peut dans certains cas se révéler très intéressant.

Elle utilise un contrôle de type SPSecurityTrimmedControl qui permet d’injecter du contenu HTML de manière conditionnel en fonction du niveau de permissions de l’utilisateur en cours.

Ainsi, si on se base sur l’exemple décrit plus tôt, on peut tout à fait modifier le script RibbonVisibility.js comme suit afin d’afficher l’élément caché en CSS :

$(document).ready(function () {
    $("#s4-ribbonrow").show();
});

Ensuite, il suffit de référencer le script uniquement pour les utilisateurs authentifiés ayant des droits de vue sur le web courant, pour cela, on peut utiliser la déclaration suivante mettant en œuvre la propriété suivante : AuthenticationRestrictions :

<SharePoint:SPSecurityTrimmedControl 
ID="SPSecurityTrimmedControlRibbon" runat="server" AuthenticationRestrictions="AuthenticatedUsersOnly"> <script src="/_layouts/Sample.Masters/Scripts/jQuery.ribbonVisibility.js" type="text/javascript"></script> </SharePoint:SPSecurityTrimmedControl>

De cette manière, le script n’est inclus que pour les utilisateurs authentifiés et ayant les permissions de vue, ce qui dans le cas d’un site de publication WCM, implique que pour les utilisateurs anonymes aucun script inutile est chargé.

Une autre déclaration possible pourrait être la suivante en utilisant la propriété PermissionsString beaucoup plus granulaire en prenant en compte les permissions sur les éléments tel que le web courant :

<SharePoint:SPSecurityTrimmedControl ID="SPSecurityTrimmedControlRibbon" 
                                        runat="server" 
                                        PermissionsString="Open">
    <script src="/_layouts/Sample.Masters/Scripts/jQuery.ribbonVisibility.js" 
            type="text/javascript"></script>
</SharePoint:SPSecurityTrimmedControl> 

 

UPDATE :

Comme Renaud me le faisait remarquer, on peut également dans le cas d’exemple mis en œuvre ici uniquement, utiliser habilement le SPSecurityTrimmedControl et directement placer le contrôle Ribbon dans le contenu à insérer.

D’ailleurs, il existe un projet dédié à l’administration de l’affichage de ce ruban à l’adresse suivante : http://spribbonvisibility.codeplex.com/

 

Conclusions

Dans ce cas d’exemple, les deux solutions sont utilisables et c’est véritablement en fonction des besoins et des contraintes de projet que l’on choisit une solution plutôt que l’autre.

Le profil ayant à charge de réaliser ce type de manipulation est également à considérer, en effet, il devient relativement plus complexe de demander de réaliser et définir un DelegateControl pour SharePoint de la part d’une ressource au profil davantage Designer/Intégrateur que développeur SharePoint, même si la tâche n’est pas complexe en soit, elle implique d’avoir à saisir les différents éléments liés au déploiement, aux systèmes de Features de SharePoint et bien d’autres problématiques de composants.

En bref, il faut très clairement adapter la solution en fonction de ces paramètres qui ne sont pour la plupart du temps, pas uniquement liés au contexte technique.