Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

SharePoint Grib's Lair

Journal technique de Sébastien PICAMELOT

Comment étendre les données utilisateur SharePoint ?

Background

J'ai récemment cherché à stocker des métadonnées concernant la fréquentation des utilisateurs sur une collection de site. Récupérer des données statistiques sur la fréquentation se fait à l'aide de la méthode GetUsageData() :

SPWeb.GetUsageData (SPUsageReportType, SPUsagePeriodType)
SPWeb.GetUsageData (SPUsageReportType, SPUsagePeriodType, Int32, DateTime)

Seulement voilà, cette méthode est propre à la classe SPWeb. Récupérer des statistiques globales au niveau du SPSite demande donc une agrégation de données en parcourant la liste des sites. Et dans ce cas, aller chercher toutes les données et les filtrer en temps réel n'est pas vraiment performant. J'ai donc choisi de réaliser un Job SharePoint afin d'agréger toutes les données la nuit, puis de les stocker quelque part... mais où ?

Problématique

Bien que ce ne soit pas l'option que j'ai retenue, j'ai tout d'abord pensé aux données utilisateurs déjà présentes sur la collection de site. Petit rappel : les sites SharePoint exposent des données relatives aux utilisateurs de ses sites. Ces données sont accessibles à l'aide du contrôle welcome.ascx placé sur la masterpage default.master.

UserControl welcome.ascx


Ce contrôle permet d'accéder à la page userdisp.aspx (du dossier SharePoint LAYOUTS) affichant les données concernant les utilisateurs.

Page UserDisp d'origine

Le lien avec le modèle objet semble évident, et j'imagine ne pas être le seul à penser instinctivement « SPUser ». Il m'est donc venu la question suivante : peut-on étendre la classe SPUser ?

L'enquête

Après avoir cherché un peu sur Internet et sur le MSDN, il apparait que non. Mais il me semblait pourtant bien avoir vue une structure différente de cette page sur deux environnements différents... et après vérification, il est bien possible d'avoir une structure différente pour décrire les utilisateurs.
J'ai donc investigué à l'aide de Reflector à partir de la classe UserDisplayPage (dont « hérite » la page UserDisplay.aspx) et je suis tombé sur cette ligne là :

this.UserListForm.ListId = base.Web.SiteUserInfoList.ID;

Et je m'en suis voulu de ne pas y avoir pensé plus tôt. Si vous avez parcouru les listes de vos sites avec le modèle objet, ou bien à l'aide d'un outil comme le CAML Query Builder ou un logiciel comme Access, vous avez surement du remarqué une List nommée « UserInfo »ou « Liste d'informations utilisateur ». Et c'est dans cette liste que sont stockées toutes les données affichées sur la page UserDisp.aspx. 

Les tests

Un rapide test avec le modèle objet pour rajouter des champs :

SPFieldCollection fields = web.Lists["Liste d'informations utilisateur"].Fields;
fields.Add("URL du blog", SPFieldType.URL, false);
StringCollection choices = new StringCollection();
choices.Add("http://www.sharepointofview.fr/gat");
choices.Add("http://blogs.developpeur.org/phil");
choices.Add("http://blogs.developpeur.org/themit");
choices.Add("http://blogs.sharepointofview.fr/julien");
choices.Add("http://blogs.developpeur.org/fabrice69");
string fieldName = fields.Add("Blogosphere", SPFieldType.MultiChoice, false, true, choices); 
 

Et voilà le résultat sur la page useredit.aspx : 

La page UserEdit.aspx après les modifications

... et sur la page userDisp.aspx

La page UserDisp.aspx après les modifications

Conclusions

Bref, sans pour autant étendre un SPUser, la notion d'utilisateur de site est bien élargie. A noter toutefois :

  • que la sécurité sur ces données utilisateur est basée sur celle des listes, donc pas nécessairement adaptée pour stocker du contenu personnel (pour cela, préférez les profils MOSS)
  • que ces données sont propres à la collection de sites. La structure réservée aux données utilisateur reste donc différente dans les autres collections de site.
  • que cette structure permet de stocker des pièces jointes.

Modifier la structure des données décrivant un SPUser se fait donc très simplement... il fallait juste y penser Wink

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: jeudi 10 avril 2008 01:11 par Gribouillon

Commentaires

Arnault Nouvel a dit :

Bien vu !

ca donne plein d'idées tout ca :)

# avril 10, 2008 10:29

ROMELARD Fabrice a dit :

Interessant, mais la limitation des informations au niveau de chaque collection pose tout de suite un blocage en production reelle.

Dans une de nos fermes WSS (on depasse allegrement les 300 collections) et un ancien client prevoyait une ferme a plus de 10000 collections courantes. Autant dire que le modele objet devient tres vite impossible.

Pour ma part, les informations des utilisateurs sont synchronisees depuis la base de profils SPS 2003 connectee a l'AD et un script SAL de synchro vers chaque ferme WSS V3.

Ca fonctionne parfaitement (moins dune minute pour la mise a jour des dizaines de miliers de comptes).

Mais c'est interessant de savoir que c'est extensible.

Fabrice

# avril 11, 2008 00:21

Gribouillon a dit :

Pour une simple description des utilisateurs il y a peu de cas où c'est utilisable, je suis bien du même avis (même si on peut imaginer une appli WSS stockant et se servant de données utilisateurs plus riches que celles de base)

Ce qui m'a plus intéressé en revanche, c'est la possibilité de stocker ces informations dans une sorte de Sites Collection centrale. Bref, un référentiel qui permettrait à des webparts d'autres collections de sites ou à des jobs d'aller se nourrir de données à partir de cette liste d'utilisateurs faussement centralisée. Certes, lorsqu'on dispose de MOSS, les profils utilisateurs sont bien souvent plus appropriés... mais pas toujours (pas de gestion des pièces jointes par exemple). Et lorsqu'on ne dispose que de WSS, c'est encore plus évident.

Cette possibilité n'est donc pas ultime en soit, mais elle est à mon avis bonne à connaître si un de ces deux cas se présente.

# avril 11, 2008 01:19

ROMELARD Fabrice a dit :

Tout à fait d'accord pour la connaissance du sujet et encore plus dans la gestion des collaborateurs dans une collection racine (pour des client ne possedant pas MOSS, mais que WSS), nous sommes donc sur la même longueur d'onde :)

Pour ceux que je sujet interesse (pas toi mais les lecteurs), je les invite à lire l'article sur le sujet qui explique justement la gestion des utilisateurs suivant la plateforme choisie :

http://www.asp-php.net/tutorial/asp.net/sharepoint-user-profile.php

Fabrice

# avril 11, 2008 10:44

Gribouillon a dit :

Oups... je crois bien que j'avais raté ton article à l'époque. Mais quand on voit la tête des requêtes, la table (liste) UserInfo ne fait aucun doute.

# avril 11, 2008 12:03
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- VMMap en mode instrumentation sur système 64bit : attention à la plateforme cible du build .NET par CoqBlog le il y a 9 heures et 29 minutes

- Etendre le Team Web Access de TFS 2012 – Step 0 par Philippe Didiergeorges Aka Philess le 05-23-2013, 23:48

- Simuler facilement l’envoi de mail par Blog de Jérémy Jeanson le 05-22-2013, 12:52

- ProcDump 6.0 : support du filtrage sur messages d'exceptions .NET, des filtres multiples et du ciblage par nom de service par CoqBlog le 05-20-2013, 14:50

- Votez pour le TOP 10 des influenceurs SharePoint francophones ! par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 12:59

- [Conf’SharePoint] Dernier rappel ! :-) par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 09:09

- [ #SharePoint 2013 ] les modèles de sites standards… par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 09:03

- 10 erreurs de compréhension concernant SharePoint… par Le blog de Patrick [MVP SharePoint] le 05-20-2013, 08:27

- Conf’SharePoint : 10 bonnes raisons pour ne pas la rater par Le petit blog de Pierre / Pierre's little blog le 05-14-2013, 02:24

- [Event] Soirée de lancement Agile .NET France à Lyon par Blog Agile/ALM de Vincent THAVONEKHAM le 05-13-2013, 01:29