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

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01