Blog de Philippe Vialatte » SharePoint

Créer un fournisseur de menu personnalisé

Philippe Vialatte — Wed, 02 Sep 2009 07:29:00 +0000

Suite a une petite discussion sur le forum Sharepoint, je me disais que ca ferait du bien de soumettre ce petit développement a l’appréciation de tous.

Sharepoint dispose, par défaut, d’un certain nombre de fournisseurs de menus (avec WSS, par exemple, SPNavigationProvider, SPSiteMapProvider, ou SPContentMapProvider)

Il peut arriver que, pour des raisons diverses et variées, on ait besoin d’avoir un comportement différent (menus différents selon les utilisateurs, ou autres)

Une bonne façon de faire est d’étendre le Provider, pour pouvoir éventuellement ajouter des éléments. Dans le cas présent, on va aller piocher dans une liste des éléments supplémentaires, de façon a générer un menu déroulant dans WSS v3 (et oui, pas de gestion native des sous-menus).

Pour cela, on va créer une classe TopNavBarProvider (parce qu’on va s’en servir dans la …top navbar ), qui hérite de SPNavigationProvider et on va surcharger sa méthode GetChildNodes. La méthode GetChildNodes est utilisée pour récupérer les noeuds descendants du noeud courant.

public class TopNavBarProvider : SPNavigationProvider {

[SharePointPermission(SecurityAction.Demand, ObjectModel = true)]
public override SiteMapNodeCollection GetChildNodes(SiteMapNode node)

Dans cette méthode, on va aller essayer de récupérer le contenu d’une liste Menu, qui contient un titre, une url, et un parent.

On va avoir deux familles de cas :

soit on a un noeud qui est un noeud « sharepoint », a savoir le noeud racine, ou un noeud déclaré dans la barre de navigation standard
soit on a un de nos noeuds customisés (il n’est pas possible de creer des noeuds de type SPSiteMapNode)

Dans la première famille, il va falloir déterminer si le noeud est un noeud « standard », ou la racine. Si le noeud est la racine du site, il va falloir lui adjoindre tous les noeuds parents de notre liste.

if (type.FullName.EndsWith(« SPSiteMapNode »)) {
collection = base.GetChildNodes(node);
return LoadSiteMapNodes(node, web);
}

Pour ca, on va faire un test un peu sale (mais qui marche), a savoir :

private SiteMapNodeCollection LoadSiteMapNodes(SiteMapNode parentNode, SPWeb web) {

SiteMapNodeCollection collection = new SiteMapNodeCollection();

    if (parentNode.Url.EndsWith(web.Name + « /default.aspx »)) {
        foreach (CustomNode tmpNode in LoadTopLevelNodes(parentNode, web)) {
            collection.Add(GenerateSiteNode(tmpNode));
        }
    }
    return collection;
}

La fonction LoadTopLevelNodes va ressembler a ca :

Guid webId = web.ID;
Guid siteId = web.Site.ID;
List <CustomNode> tmpNodes = new List<CustomNode>();

SPSecurity.RunWithElevatedPrivileges(delegate {
using (SPSite site = new SPSite(siteId)) {
using (SPWeb tmpWeb = site.OpenWeb(webId)) {

if (!ListExists(tmpWeb, « Menu »)) return;

SPList list = tmpWeb.Lists[« Menu »];
SPQuery query = new SPQuery();

            string queryValue = «  »;
            queryValue += «  »;
            queryValue += « 1 »;
            queryValue += «  »;

query.Query = queryValue;

SPListItemCollection myItems = list.GetItems(query);

            foreach (SPListItem menu in myItems) {
               tmpNodes.Add(new CustomNode(menu, tmpWeb.Url));
            }
        }
    }
});

Si on travaille avec un noeud courant qui n’est pas de type SPSiteMapNode, on se retrouve avec soit le cas d’un noeud parent, soit le cas d’un enfant. On va donc simplement chercher tous les enfants du noeud courant, et les renvoyer. Pour cela, on va plus ou moins utiliser la même fonction, en changeant juste la requête CAML.

SPSecurity.RunWithElevatedPrivileges(delegate {
using (SPSite site = new SPSite(siteId)) {
using (SPWeb tmpWeb = site.OpenWeb(webId)) {

if (!ListExists(tmpWeb, « Menu »)) return;

SPList list = tmpWeb.Lists[« Menu »];
SPQuery query = new SPQuery();

            string queryValue = «  »;
            queryValue += «  »;
            queryValue += « 1 »;
            queryValue += «  »;

query.Query = queryValue;
SPListItemCollection myItems = list.GetItems(query);

            foreach (SPListItem menu in myItems) {
                string parent = menu[« Parent »] as string;
                string parentId = parent.Split(‘;’)[0];
                if (parentId.Equals(parentNode.Key.Replace(« CustomNode », «  »))) {
                    tmpNodes.Add(new PMONode(menu, tmpWeb.Url));
                }
            }
        }
    }
});

Voila, c’est volontairement parcellaire, mais ca devrait permettre a ceux qui sont intéressés de se dépatouiller

Une référence de STSADM interactive en Silverlight

Philippe Vialatte — Tue, 09 Jun 2009 07:00:00 +0000

Pour tous ceux qui se sont un jour gratté désespérément la tête en cherchant LA ligne de commande STSADM a utiliser pour faire juste ce qu’ils voulaient, Microsoft a sorti (récemment ?) une page montrant les différentes options de l’utilitaire, groupées par aires fonctionnelles.

Joie suprême, plutôt que de juste proposer une nouvelle page avec un tableau statique, cette fois-ci, on a droit a une jolie interface en Silverlight et tout et tout…

Et avec les filtres sur le service pack et la recherche super réactive

à voir ici:

http://technet.microsoft.com/en-us/office/sharepointserver/cc948709.aspx

Et en passant, la référence sous forme de table ~~moche~~ classique est ici (et en français, SVP) :

http://technet.microsoft.com/fr-fr/library/cc263384.aspx

[Sharepoint] Gérer les formules d’une liste

Philippe Vialatte — Fri, 05 Jun 2009 07:17:00 +0000

Que se passe-t’il quand, alors que 150 sites ont été déployés a partir d’un Template, on se rends compte qu’une formule ne fonctionne pas correctement ?

(Ne pas répondre: t’avais qu’a utiliser des types de contenu, pour un ensemble de raisons, c’était exclus… )

Parce grosso modo, c’était mon petit truc rigolo de la semaine…

Donc, comme d’habitude, je passe une petite heure dans la msdn, jusqu’a trouver *the* solution, dans les champs de la classe SPFieldCalculated.

Pour ceux qui seraient intéressés par ce genre de manip, cela se fait simplement comme cela :

    SPList list = web.Lists[« Liste1″];
    SPFieldCalculated calc = list.Fields[« Column3″] as SPFieldCalculated;
    calc.Formula = « =IF(Column1=Column2, \ »OK\ », \ »Not OK\ ») »;
    calc.Update();

Il faut convertir le champ en SPFieldCalculated, car Fields renvoie une collection de SPField, lesquels n’ont pas la colonne Formula.

La base de contenu de WSS, 2/n : Groups, GroupMembership, SchedSubscriptions et ImmedSubscriptions

Philippe Vialatte — Wed, 20 May 2009 15:37:00 +0000

Voila, un peu plus d’un mois après le premier post sur le sujet, un un second petit post sur la base de contenu de WSS.

Apres avoir vu la structure des Sites, des Webs et des Utilisateurs, on va jeter un oeil sur les groupes de nos utilisateurs, ainsi que sur leurs alertes.

En effet, dans sa version 3, Sharepoint a restreint a 2 le nombre de table nécessaire pour la gestion des groupes (contre 4 auparavant, avec une distinction des groupes sites et des groupes web…)

La table des groupes contient tous les groupes déclarés dans l’application Web. Elle va principalement contenir l’UniqueId du Site auquel le groupe est rattache, l’id du groupe, son nom, une description, l’id du propriétaire du groupe, et l’email permettant d’envoyer une requête pour rejoindre ce groupe.

Cette table des groupes en elle-même ne sert a rien. en effet, pour pouvoir être utilisée, elle est liée a la table Users par la table GroupMembership, qui détermine les appartenances des utilisateurs aux groupes. GroupMembership est juste une table d’intersection, et contient juste l’identifiant du site, l’identifiant de l’utilisateur, et l’identifiant du groupe.

Attention, l’ID des groupes et des utilisateurs n’est unique que pour un site donné !!!

Les tables SchedSubscriptions et ImmedSubscriptions sont quasiment identiques, la table SchedSubscriptions contenant juste trois champs supplémentaires, permettant de gérer la fréquence de notification (NotifyFreq), ainsi que l’heure de prochaine notification, selon le fuseau horaire du serveur (NotifyTime), et en Temps universel coordonné (NotifyTimeUTC).

On va pouvoir, en partant de ces tables, effectuer, par exemple, les requêtes suivantes:

SELECT Id, tp_Login, NotifyFreq, (SiteUrl+WebUrl) AS URL, ListTitle, AlertTitle, AlertType, Status
FROM SchedSubscriptions WITH (NOLOCK) INNER JOIN
      UserInfo WITH (NOLOCK) ON SchedSubscriptions.UserId = UserInfo.tp_ID AND
          SchedSubscriptions.SiteId = UserInfo.tp_SiteID
Where SchedSubscriptions.Deleted = 0
UNION
SELECT Id, tp_Login, 0, (SiteUrl+WebUrl) AS URL, ListTitle, AlertTitle, AlertType, Status
FROM ImmedSubscriptions WITH (NOLOCK) INNER JOIN
      UserInfo WITH (NOLOCK) ON ImmedSubscriptions.UserId = UserInfo.tp_ID AND
          ImmedSubscriptions.SiteId = UserInfo.tp_SiteID
WHERE ImmedSubscriptions.Deleted = 0

Cette requête va nous donner toutes les alertes actives pour tous les utilisateurs de nos sites

SELECT tp_Login, Groups.Title, Groups.Description
FROM GroupMembership WITH (NOLOCK) INNER JOIN
Groups WITH (NOLOCK) ON GroupMembership.SiteId = Groups.SiteId INNER JOIN
UserInfo WITH (NOLOCK) ON GroupMembership.SiteId = UserInfo.tp_SiteID

Cette requête retournera tous les utilisateurs définis, ainsi que leur groupes

Attention, a ne pas utiliser telle quelle…Chez moi, sur un environnement avec une 50aine de sites, la requête ci-dessus renvoie plus de 180 000 enregistrements

Il vaut mieux, si vous utilisez ce genre de requête, se limiter a un site donné….ce qui n’est pas si simple.

En effet, le site en lui-même n’a pas une représentation facile a déterminer…car l’url « du site » est en fait l’Url du Web de niveau supérieur (pour ceux qui ne suivent pas, retournez au premier article )

Pour trouver tous les utilisateurs définis sur un site donne, dont on á, par exemple, l’url, on va faire:

SELECT tp_Login, Groups.Title, Groups.Description,
Webs.Title AS WebTitle, FullUrl
FROM Webs INNER JOIN
GroupMembership WITH (NOLOCK) INNER JOIN
Groups WITH (NOLOCK) ON GroupMembership.SiteId = Groups.SiteId INNER JOIN
UserInfo WITH (NOLOCK) ON GroupMembership.SiteId = UserInfo.tp_SiteID ON Webs.SiteId = GroupMembership.SiteId
WHERE Webs.ParentWebId IS NULL
AND Webs.FullUrl=‘URL DE MON SITE PARENT’

Voila, doucement, mais surement, ca avance, il reste..euh…40 tables ??? (je ne les ferais pas toutes )

Ah, et, oui, si vous détruisez votre site SharePoint par mégarde, ne me tenez pas pour responsable (on rappelle, pas d’insert, pas d’update, pas de delete)

Créer des sites et des collections de sites avec l’API Sharepoint

Philippe Vialatte — Tue, 19 May 2009 08:41:00 +0000

(Si une personne suit, oui, je suis en train de me taper un petit outil pour automatiser la création de mes sites…et ca commence a bien marcher)

Dans mes aventures avec l’API, encore un gros arrachage de cheveux en vue

Cela fait déjà quelques mois que j’ai un système a peu prés stable pour créer automatiquement des webs, leur appliquer un modèle, des customisations de listes et Co.

Récemment, les exigences on t changes, il faut maintenant créer des collections de sites.

Première réaction, ok, facile, il suffit de trouver la « bonne ligne de commande ©T »

…en fait, c’est loin d’être aussi simple.

Premièrement, la ou on doit simplement ajouter notre site a la liste des modèles de sites pour créer un modèle de site, pour les modèles de collection de site, il faut aussi ajouter le modèle aux modèles disponibles. Pour cela, ca se passe cote serveur, avec stsadm…

Il faut donc:

Créer le modèle de site (dans les actions du site, sauver en tant que modèle)
Copier le modèle sur le serveur physique hébergeant l’application web (admettons, sur c:\montemplate.stp)
Lancer un coup de stsadm
stsadm -o addtemplate -filename « C:\montemplate.stp » -title « mon site projet » -description « mon modèle de site projet »
Vérifier que le modèle a bien été ajouté, avec stsadm
stsadm -o enumtemplates
-> « mon site projet » – Language: 1033 – Site Template: _GLOBAL_#0 – Template Id: 1

(Note, pour revenir sur mes exemples avec la base de contenu, si le modèle est bien ajouté, ou le retrouvera aussi dans la base de Configuration, dans la table CustomTemplates )

Ok, maintenant, mon modèle est au bon endroit…ne reste qu’a l’exploiter …

Pour créer une nouvelle collection de sites, je vais simplement remonter au niveau de ma web application, récupérer la liste des Sites (Sites étant une collection de site, et pas des webs…), et ajouter un nouveau SPSite.

using (SPSite parentSite = new SPSite(« http://monserveur »)) {
SPSiteCollection allSites = parentSite.WebApplication.Sites;

    SPSite newSite = allSites.Add(« sites/nouveau site », « nom du site »,
        « description du site », 1033, templateID, « MonDomaine\\MonUser »,
        « mon nom a moi », « philippe.vialatte@monserveuremail.com »);
}

…sauf que ce n’est pas si simple…En effet, la ou, pour les SPWeb, on passe directement un template, comme ca :

using (SPSite parentSite = new SPSite(siteUrl)) {

    SPWeb parentWeb = parentSite.OpenWeb();
    SPWebTemplateCollection templates = parentSite.GetCustomWebTemplates(_localeU);
    SPWebTemplate siteTemplate = templates[siteTemplateName];

return parentWeb.Webs.Add(webName, webName, « », _localeU, siteTemplate, false, false);
}

Pour les SPSite, il faut l’ID interne du modèle, qui est généré directement par Sharepoint (je vous laisse imaginer le bonheur si il faut maintenir un ID genre _GLOBAL_#1)

Une solution, si on connait le nom du fichier STP, ou si on se base sur le titre du modèle, est de passer par la collection des modèles

string templateID = null;

foreach (SPWebTemplate template in parentSite.GetWebTemplates(1033)) {
   if (template.Title.ToLowerInvariant().Equals(« mon site projet »)) {
      templateID = template.Name; // _GLOBAL_#0
   }
}

Attention, il faut bien préciser le bon ID pour la locale, sinon, pas moyen de retrouver le modèle.

Si ca intéresse du monde, je rajouterais un projet un peu plus complet, pour montrer le procédé plus en détail

Petites finesses de l’API Sharepoint

Philippe Vialatte — Mon, 18 May 2009 09:10:00 +0000

Ca faisait un moment que je n’avais plus fait de développement avec Sharepoint, et en m’y remettant, j’avais oublie deux petites finesses, qui peuvent éventuellement provoquer l’apparition spontanée de cheveux blancs, alors…pour ne plus les oublier

1. BreakRoleInheritance et AllowUnsafeUpdates

Lorsque l’on appelle BreakRoleInheritance, la référence au SPWeb courant est invalidée, ce qui provoque un reset de AllowUnsafeUpdates a false. Ce sera aussi le cas lorsque l’on changera le nom ou l’URL du site (après avoir appelé Update), ou lorsque l’on appellera BreakInheritance(),ResetRoleInheritance(). Par conséquent, a chaque appel a BreakRoleInheritance, il faut penser a sauvegarder préalablement la valeur de dans un booléen, et le remettre a sa valeur d’origine après.

bool updateRights = _web.AllowUnsafeUpdates;
_web.BreakRoleInheritance(false);
_web.AllowUnsafeUpdates = updateRights;

2. RunWithElevatedPrivileges et le site courant

RunWithElevatedPrivileges est super utile comme fonction lorsque l’on doit exécuter une portion de code avec des privilèges admin. Le seul petit piège de cette fonction, qui va exécuter une portion de code comme si elle tournait avec l’identifiant du pool d’application, est que, si on essaye de manipuler une référence a un site, a un web ou a une liste récupérée depuis l’extérieur de la zone de privilèges élevés, cette référence aura toujours les droits qu’avaient l’utilisateur AVANT RunWithElevatedPrivileges.

Donc, pour que cela fonctionne correctement, il faudra recharger les sites, web, listes et compagnie depuis l’intérieur de la zone impersonnée…

SPSecurity.RunWithElevatedPrivileges(delegate {
   using (SPSite site = new SPSite(siteUrl)) {
      using (SPWeb tmpWeb = site.OpenWeb(« / »)) {
         SPList MaListe = tmpWeb.Lists[« MaListe »]);
      }
   }
});

ou sinon, si on préfère :

Guid currentWebId = web.ID;
Guid currentSiteId = web.Site.ID;

SPSecurity.RunWithElevatedPrivileges(delegate {
   using (SPSite site = new SPSite(currentSiteId)) {
      using (SPWeb tmpWeb = site.OpenWeb(currentWebId)) {
         SPList MaListe = tmpWeb.Lists[« MaListe »]);
      }
   }
});

Voila, avec un peu de chance, j’y penserais tout de suite la prochaine fois (mais bien sur…)

[Sharepoint]Gérer les pièces jointes d’un SPListItem

Philippe Vialatte — Mon, 04 May 2009 11:29:00 +0000

Comme la question avait été posée sur le forum, une petite fonction pour gérer les pièces jointes a un Item.

Avec Sharepoint, les objets de type SPListItem ont une propriété en lecture seule Attachments, qui retourne un objet de type SPAttachmentCollection

public SPAttachmentCollection Attachments { get; }

Ajouter ou supprimer une nouvelle pièce jointe se fait assez simplement, du moment que l’on a un tableau de byte, soit :

    SPListItem item;
    byte[] content;
    string name;

    item.Attachments.AddNow(name, content);
    // utiliser AddNow permets de ne pas avoir à appeler item.Update();
    item.Attachments.DeleteNow(name);
    // utiliser DeleteNow permets de ne pas avoir à appeler item.Update();

Attacher le contenu d’un fichier venant du site Sharepoint se fait aussi assez simplement :

   SPFile file = myWeb.Folders(« monDossier »).Files(« Monfichier »);
   string fileName = file.Name;
   byte[] fileContent = file.OpenBinary();

La ou cela devient beaucoup plus rigolo, c’est lorsque l’on veut lister les attachments…

En effet, si on fais un foreach sur les attachements, on ne vas pas retourner des objets SPAttachment (par exemple), ni même SPFile, mais…le nom du fichier :-\

Apres un peu de recherche, ces items sont stockés dans un sous-répertoire de la liste, nommé Attachments, les fichiers étant exactement stockes dans un répertoire identifié par l’ID de l’item de la liste concerné. On peut donc y accéder ainsi :

    SPFolder folder = site.Folders(« Lists »).
        SubFolders(listItem.ParentList.Title).
        SubFolders(« Attachments »).
        SubFolders(listItem.ID.ToString());

    foreach (SPFile file in folder.Files) {
        // manipulations diverses et variées sur les fichiers
    }

(NB. : Ca a l’air trivial comme ca, mais à l’époque, ca m’a couté pas mal de cheveux )

Office 2010 officiellement annoncé pour mi-2010

Philippe Vialatte — Thu, 16 Apr 2009 07:58:00 +0000

L’annonce du jour concerne toute la suite Office 2010 (et pas seulement Sharepoint, pour changer ).

En effet, Microsoft a publié hier, sur PressPass, un entretien avec le « senior vice president of Microsoft’s Information Worker Product Management Group » (ouf !), au cours du quel il annonce une roadmap (une version française, quelqu’un ?) des sorties des différents produits de la suite 2010.

On aura donc, dés la fin 2009, Exchange 2010 (qui est d’ors et déjà disponible en beta), tandis que la suite Office 2010 sera disponible en CTP des le troisième quart de 2009, pour une livraison finale en début 2010.

http://www.microsoft.com/presspass/features/2009/Apr09/04-15Office2010.mspx

[Sharepoint] La base de contenu de WSS, 1/n : Sites, Webs et UserInfo

Philippe Vialatte — Mon, 06 Apr 2009 14:53:00 +0000

Ayant pas mal patouillé dans la base de contenu récemment, je me suis dit que cela pourrait toujours servir a quelqu’un d’autre un jour ou l’autre. En conséquence de quoi, voila le premier article dans une liste de je ne sais pas pas encore combien, qui concernera la base de contenu de Sharepoint V3.

Avant de commencer, on va commencer par les précautions d’usage au niveau de la base de contenu:

Ne jamais faire de mise a jour ou d’insertion directement dans la base de contenu. L’API est la pour ca, permets de tout faire, et est prévue pour.
Ne pas mettre en production un programme faisant des requêtes fréquentes sur la base de contenu. Un lock sur la base de contenu peut avoir des effets désastreux
Dans la mesure du possible, si c’est pour faire un test, ne pas travailler sur une base de production. Toujours faire les tests sur des backups.

…et évidemment, si vous détruisez par inadvertance votre base Sharepoint en faisant des manips, ne m’envoyez pas un mail rageur

J’insiste lourdement, une modification inconsidérée de la base de contenu peut détruire votre site Sharepoint…

On va commencer par trois tables qui vont parler a tous les développeurs Sharepoint, la table Sites, la table Webs, et la table des utilisateurs, Users.

Pour les non-Sharepointeurs, un peu de vocabulaire (un peu simplifié).

La base de contenu est une base SQL Server qui va contenir les données du site Sharepoint (les items, les documents etc…)
Une ferme est un ou plusieurs serveurs physique, sur lequel les pages applicatives et le « programme » Sharepoint vont être installés.
Une Web Application est un site au sens IIS, qui est géré par l’applicatif Sharepoint
Chaque Web Application va contenir une ou plusieurs collections de Sites (SPSite coté API, table Sites de la base de contenus)
Une collection de site va contenir au moins un Web (SPWeb, table Web), qui sera le Web de niveau supérieur, et pourra contenir autant de sous-sites (chacun étant un SPWeb) que nécessaire, et chaque Web pouvant aussi contenir des Webs
Une fois qu’on est au niveau Web, on trouvera des listes et des bibliothèques de documents

Voila pour la petite intro.

La table des Sites va contenir toutes les collections de site de l’application Sharepoint qui utilise la base de contenu courante.

On trouvera dans cette table, entre autre, les infos sur les quota, la taille occupée (pour le site et pour la corbeille) les différents Url (absolues), les propriétaires de la collection de site (primaires et secondaires), et les dates de certaines action (créations, dernière modification, etc…)

La table des Web va contenir tous les SPWeb contenu dans l’application web courante. On trouvera dans cette table le titre du Web, son Url relative, des statistiques (utilisation quotidienne, mensuelle), les informations de locale et de calendrier, l’Id unique du Web, et l’Id du Web parent si il existe.

On va pouvoir, en partant de ces tables, effectuer, par exemple, les requêtes suivantes:

SELECT FullUrl, Title, Author, TimeCreated
FROM Webs
WHERE ParentWebId IS NULL

Cette requête va nous donner tous les sites Web de niveau supérieurs (1 par collection…)

Inversement, celle ci va nous donner tous les Webs appartenant a un Web de niveau supérieur:

SELECT FullUrl, Title, Author, TimeCreated
FROM Webs
WHERE Not ParentWebId IS NULL

Cette requête va nous donner, pour tous les Sites, la taille occupée, la date de création, les propriétaires, et les tailles occupées par les données et par la corbeille.

SELECT Sites.Id, Sites.TimeCreated, Sites.DiskUsed, Sites.SecondStageDiskUsed,
       UserInfo.tp_Login AS Principal, UserInfo_1.tp_Login AS Secondaire
FROM Sites INNER JOIN
     UserInfo ON Sites.OwnerID = UserInfo.tp_ID INNER JOIN
     UserInfo AS UserInfo_1 ON Sites.SecondaryContactID = UserInfo_1.tp_ID

Plus intéressant, la liste de tous les utilisateurs de tous les webs

SELECT Webs.FullUrl, Webs.Title, UserInfo.tp_SiteAdmin, UserInfo.tp_Title, UserInfo.tp_Email
FROM UserInfo INNER JOIN Webs
ON UserInfo.tp_SiteID = Webs.SiteId

Et le nombre d’utilisateurs par web

SELECT Webs.FullUrl, Webs.Title, COUNT(UserInfo.tp_ID) AS nbUtilisateurs
FROM UserInfo INNER JOIN
Webs ON UserInfo.tp_SiteID = Webs.SiteId
GROUP BY Webs.FullUrl, Webs.Title

…ainsi que le nombre d’utilisateurs actifs

SELECT Webs.FullUrl, Webs.Title, COUNT(UserInfo.tp_ID) AS nbUtilisateurs
FROM UserInfo INNER JOIN
Webs ON UserInfo.tp_SiteID = Webs.SiteId
WHERE UserInfo.tp_IsActive = 1
GROUP BY Webs.FullUrl, Webs.Title

voila, pour une première approche de la bête, si j’arrive a garder intacte ma belle motivation (et que ca intéresse quelqu’un…), j’essayerai de passer brièvement sur toutes les tables intéressantes (de mon point de vue)

Pour conclure, je ne saurais pas assez le répéter, pas d’insert, pas d’updates !!!

[SharePoint]Ca y’est, SharePoint Designer est disponible gratuitement

Philippe Vialatte — Thu, 02 Apr 2009 18:31:00 +0000

Je l’avais déjà mentionné dans un précédent post, mais SharePoint Designer est désormais gratuit…

Vous le trouverez a cette adresse : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=baa3ad86-bfc1-4bd4-9812-d9e710d44f42