Effectivement, ça arrive, et c’est assez ennuyeux car ça signifie code appelé deux fois, actions effectuées deux fois… bref pas pratique.
N’oublions pas que la première cause d’un évènement levé deux fois est dans la plupart des cas le fait d’avoir cet évènement référencé deux fois. Et dans ce cas un outil comme https://speventreceiverman.codeplex.com/ est très utile.
Autre chose à vérifier, que ce ne soit pas vos utilisateurs qui accomplissent deux fois la même action quelque chose de similaire. (si si, j’ai confiance en mes utilisateurs finaux, mais quand même j’ai appris à me méfier)
Mais admettons qu’aujourd’hui ce n’est pas un de ces cas, et que votre code est bien appelé deux fois.
Avant tout assurez-vous que vous n’êtes pas dans un de ces cas présentés par Microsoft https://msdn.microsoft.com/en-us/library/aa979520.aspx
Non ce n’est pas le cas ? Ne désespérez pas tout de suite, il reste toujours quelque chose qui pourrait faire en sorte que vos évènement soient levés deux fois : les options d’extraction/d’archivage.
Le cas est décrit ici pour SharePoint 2007 https://support.microsoft.com/kb/939307 il n’est cependant pas indiqué si SharePoint 2010 (et 2013 ?) est concerné ou non.
C’est apparemment le cas puisque ce n’est pas un bug à proprement parler mais un comportement natif : Quand l’option exiger l’extraction est activée dans une librairie de documents voici ce qu’il se passe.
L’utilisateur upload le document ItemAdding puis ItemAdded sont appelés, avec aucune propriété de renseignée (les champs que vous avez ajoutés en plus sur la doc lib).
Ensuite l’utilisateur est redirigé vers la page de détails, il remplit les propriétés et enregistre. ItemUpdating et ItemUpdated sont appelés une première fois car mise à jour des données.
A ce moment l’ER de gestion des archivages/extractions rentre en jeu et décide d’archiver le document, la notion d’archivage étant cachées dans une propriété cachée, il est obligé de mettre à jour le SPListItem et donc nouvelle levée de nos ER.
Vous commencez à saisir le problème ?
Maintenant voici comment le fixer, le workaround de Microsoft fonctionne très bien pour ItemUpdating, mais sous 2010, selon les paramètres d’archivage/extraction et parce que les valeurs controlées sont mises à jour entre ItemUpdating et ItemUpdated, ça ne marche pas parfaitement.
Voici ce que j’ai trouvé pour contourner le problème dans SharePoint 2010 sur l’ER ItemUpdated :
properties.ListItem.File.CheckOutType == SPFile.SPCheckOutType.None
En espérant que ça fasse gagner du temps à certains d’entre vous.