Catégories: SharePoint, Admin, API

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).

» Lire la suite!

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.

» Lire la suite!

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 :

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

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.

» Lire la suite!

(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 ;)

» Lire la suite!

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.

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...

ou sinon, si on préfère :

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

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

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

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

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 :

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

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

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.

» Lire la suite!

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

Je me suis récemment un peu pris la tête sur un problème, en apparence simple, mais pour lequel l'API m'a enduit d'erreur.

Mon problème  de base était simple, je voulais juste lister les répertoires d'une liste de documents (pour supprimer des droits, si vous voulez tout savoir ;) ).

Pour cela, je jettes un oeil a l'API, je vois un joli list.Folders...sauf que List.Folders renvoie une liste...d'items :-\.

Après quelques essais, la bonne propriété est donc la propriété SubFolders du RootFolder de notre liste, pour un résultat final ressemblant a cela:

J'avais vu passer la rumeur a un moment, mais jusqu'a il y'a peu, je n'y croyais pas trop, malgré la relative fiabilité des sources (quelle idée dans le choix de la date aussi...), mais il semblerait qu'a partir du premier Avril 2009, Sharepoint Designer 2007 serait gratuit.

Les licences déjà achetées pouvant être ultérieurement converties en licences pour Expression

Niveau sources, voir ici:

http://weblogs.asp.net/bsimser/archive/2009/03/13/sharepoint-designer-free-as-in-beer.aspx

http://edonoffice.blogspot.com/2009/03/sharepoint-designer-will-be-free.html

Ce qui m'a le plus convaincu étant ce post:

http://www.sadev.co.za/node/346

...et surtout sa version d'avant le "désolé, je me suis fait taper sur les doigts", dont on voit encore un bout sur le blog :

"Microsoft will offer SharePoint Designer 2007 free of charge, as a download, starting April 1, 2009. This change is being made in order to help customers get the most value out of their investments in SharePoint products and technologies.  Microsoft will remove SharePoint Designer 2007 from the April 2009 Volume Licensing price list. "

Plus qu'a attendre le premier Avril