in

didierdanse.net

Site personnel de Didier Danse
Didier Danse's Personnal Website
Microsoft Most Valuable Professional SharePoint

This Blog

Syndication

didierdanse.net - Les news Developpement

October 2008 - Posts

  • SharePoint: Attention aux champs users après une migration avec la Content Migration API

    [English version]

    Si dans vos listes vous utilisez un champ user qui filtre les utilisateurs possibles sur base d'un groupe SharePoint et que vous avez l'intention de migrer votre application d'un environnement à un autre via la Content Migration API, ce post est pour vous!

    Tout d'abord, un rapide rappel sur la manière de filtrer les users sur base d'un groupe:

    Dans la définition de la liste, cliquez sur le nom de la colonne user. Une fois dans la fenêtre de propriétés, il suffit de sélectionner le groupe utilisé pour filtrer les users.

     02_thumb[1] 

    Comment cela se passe-t-il en interne? L'identifiant du groupe sélectionné est stocké dans une propriété du champ. Il s'agit de SPFieldUser.SelectionGroup qui reçoit et renvoie un entier comme en atteste MSDN: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfielduser.selectiongroup.aspx.

    Cet identifiant (424 dans notre exemple) est celui présent dans l'url lorsque vous modifiez les membres du groupe.

    01_thumb[2]

    Jusque là, pas de problème.

    Là où peut survenir un problème, c'est lorsque, via STSADM (stsadm -o export) ou un outil (SP RAD Studio par exemple) utilisant la Content Migration API, nous exportons ce site et ensuite l'importons dans un autre environnement. Et là, surprise! Il s'avère que le groupe sélectionné pour le filtre ne correspond pas à ce que nous attendions.

    03_thumb[12]

    Que s'est-il passé? La réponse est simple. Seul un identifiant sous forme d'entier est utilisé comme nous l'avons vu. En regardant le package généré par une opération d'export, on pourrait penser que l'import ne posera aucun problème puisque l'on retrouve  <Group Id="424" Name="GroupName" [...]> dans le fichier UserGroup.xml.

    Cependant, lors de l'import, pour peu que l'identifiant soit déjà utilisé, le groupe importé recevra un nouvel ID. Malheureusement, l'ID utilisé par le champ user n'est quant à lui pas modifié. Et c'est ainsi que l'on se retrouve avec un filtre sur un groupe non souhaité!

    Ainsi, il nous sera nécessaire de modifier manuellement ce filtre après la migration. Pour cela, il suffit de passer par l'interface web... si nous en avons le droit. Dans le cas contraire, une solution possible est d'utiliser des extensions STSADM. C'est cette solution que j'ai mis en place afin de réaliser toutes les opérations d'une traite.

    Cette opération prend en paramètre le nom d'un groupe SharePoint (et non pas sans identifiant puisqu'on ne le connaît pas à l'avance dans notre scénario).

    stsadm -o setfieldproperties -url <SiteUrl> -list <Listname> -field <Fieldname> -userfieldgroupfilter <GroupName>

    Cette extension fait partie des extensions Migration extensions présentes sur CodePlex (http://www.codeplex.com/migrationstsadmext).

More Posts
L'auteur du site ne peut être tenu responsable des dommages que les informations fournies pourraient entraîner. Tout est cependant mis en oeuvre pour éviter tout désagrément.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems