Lors de la copie d’un élément qui contient une auto-référence dans l’une de ses versions précédentes et que cette référence fait également partie d’une dépendance circulaire, cet élément peut être différent à la destination.

Cela peut aussi se produire lorsque vous avez une bibliothèque de documents sans gestion des versions activée et faisant partie d’une dépendance circulaire.

En raison d’une limitation, cet élément aura désormais l’auto-référence dans sa version actuelle.

L’élément « {0} » possède une ancienne version qui fait partie d’une dépendance circulaire. Cette référence pourrait être supprimée ou présente dans la version la plus récente en raison d’une limitation de l’API d’importation SharePoint Azure.

Le fichier « {0} » fait partie d’une dépendance circulaire. Cette référence pourrait être supprimée ou présente dans la version la plus récente en raison d’une limitation de l’API d’importation SharePoint Azure.

Lorsque vous utilisez Insane Mode, ShareGate Migrate envoie toutes les versions et les éléments qui complètent une chaîne circulaire en même temps. Habituellement, l’ordre dans lequel ces éléments sont envoyés n’a pas d’importance. Mais en raison d’une limitation de l’API d’importation que nous utilisons, l’ordre semble avoir de l’importance dans ce cas, mais lorsqu’il s’agit d’une chaîne où tous les éléments sont liés, il n’y a pas vraiment de « premier élément ».

Voici un exemple de liste source qui rencontrera ce problème :

Voici l’historique de chaque élément à la source :

et

Lors de la copie, l’un de ces éléments sera évidemment placé avant sa dépendance. Cet élément sera modifié. Voici le résultat après notre migration :

Cela semble correct, mais voici leurs versions :

et

"Cet article a été traduit à l’aide de l’intelligence artificielle. En cas de doute, veuillez vous référer à la version originale en anglais."