Catégorie: API

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.

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

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:

Mon petit problème de la semaine en SharePoint a été le suivant...

A 9h du matin, le lundi, un ensemble d'utilisateurs a...change de groupe AD...

Attention, leur groupe AD n'a pas été renommé, mais pour des raisons d'organisation, ces utilisateurs ont été bougés d'un groupe AD a l'autre. Or, ce groupe AD avait la responsabilité d'administrer n sites Sharepoint...joie

Ma mission, que je n'avais pas d'autre choix que d'accepter, a donc été de supprimer le groupe précédent du groupe défini comme owner des sites, et de le remplacer par un autre groupe...sur une cinquantaine de sites...

» Lire la suite!