none
Les Variations : propagation des pages contenant des champs obligatoires de type "personne ou groupe" RRS feed

  • Question

  • Bonjour,

    Sur mon site SharePoint 2010, j'ai recours à la variation pour gérer du contenu dans plusieurs langues.
    Aussi, j'ai un type de contenu associé aux pages particulières que je crée ou que je mets à jour.
    Le contenu en question est représenté par des pages (dans la bibliothèque des pages) dont le layout contient des champs.
    Parmi ces champs, j'ai des champs de type "texte riche", des champs de type "image", et des champs de type "personne ou groupe", tous obligatoires.

    Mon problème réside dans le dernier type de champ cité ci-dessus.
    J'utilise un controle de type Microsoft.SharePoint.WebControls.UserField pour afficher la valeur d'un champ de type "personne ou groupe", en mode édition ou en mode display.
    En fait, lors de la propagation des pages (effectuée par les jobs natifs "CreateVariationPageJobDefinition" pour la création et "PropogateVariationPageJobDefinition" pour la mise à jour), aucune page n'est créée.
    J'ai rendu les logs plus verbeux ... et devinez quoi ?
    Il se trouve que le code du job n'arrive pas à résoudre le login de l'utilisateur.
    Le plantage a lieu exactement à la création de la page dans les bibliothèques de pages des sites variantes et plus précisément au remplissage des fields de type "personne ou groupe".
    Pourtant l'utilisateur est bien exporté et existe bien à tous les niveaux (càd. au niveau collection de sites parmi les SiteUsers et au niveau web en faisant un EnsureUser() du login en question).
    Tous cela à cause des champs obligatoires gérés avec un controle UserField dans ma page layout, et d'ailleurs, la classe UserField utilise un PeopleEditor comme controle interne apparemment !

    Est-ce que quelqu'un a déjà rencontré un tel problème avec les variations ?
    Si oui, comment peut-on gérer les champs de type "UserField" ?

    Y a-t-il un moyen pour contourner ce problème ?
    Si oui, lequel ?

    Merci pour votre aide,

    Okavango93

    PS :
    Après avoir cherché pendant une demi journée sur le web j'ai trouvé un post  
    (voir ici :  http://social.technet.microsoft.com/Forums/nl-NL/sharepoint2010programming/thread/98943b96-12ca-42d3-8d24-e11c4cc6c1f7)
    qui expose le même problème, mais il propose une solution de contournement qui ne me convient pas du tout.
    On dirait que c'est un bug du produit. On a également fait appel aux gars du support Microsoft pour nous aider mais sans résultats !
    Ils n'ont pas réussit à trouver d'où vient le problème.
    Dommage ! Cela "peut être" voire même "est" très très bloquant fonctionnellement !

    • Déplacé Hengzhe Li mardi 21 février 2012 05:30 merge forum (Origine :Développement Sharepoint 2010)
    lundi 30 janvier 2012 20:39

Réponses

  • Bonjour tout le monde,

    A ce que je vois, deux années (jour pour jour) se sont écoulées et toujours pas de réponse à ma question.

    :-)

    En fait, j'ai trouvé pourquoi les pages ne se créaient pas lors des exports/imports : en fouillant dans les DLLs (classe ImportObjectManager) de SharePoint et plus précisément dans l'API d'import/export de données, je suis remonté jusqu'au message d'erreur lu dans les logs.

    Il se trouve qu'il y a un test qui est effectué lors de la résolution d'un utilisateur qui, dans sa condition, vérifie si le login de l’utilisateur ne contient pas un deux points ":" et que dans le cas contraire, une résolution par SID (visiblement qui c'est ce qui échoue systématiquement) est effectuée.

    Voici des extraits de codes, l'exception levée est dans le dernier bloc try/catch :

    private bool EnsureUser(byte[] sid, string login, bool isRole, string display, string email, string notes, string mobilePhone, int flags, bool deleted, int idOld, out int idNew)
    {
        if (this.ImportSettings.UseSecurityMappingDirectly)
        {
            idNew = idOld;
            return true;
        }
        bool flag = true;
        idNew = -1;
        if (SecurityCheck.OnUserGroupImport(this.Context))
        {
            try
            {
                this.ImportSettings.Logger.Log(DeploymentLogSeverity.Progress, SPResource.GetString("UserImportExport", new object[] { SPResource.GetString("Importing", new object[0]), login }));
                base.Site.Request.EnsureUserExists(base.Site.Url, login, email, display, notes, mobilePhone, flags, isRole, false, true, ref sid, deleted, out idNew);
            }
            catch (Exception exception)
            {
                SPImportObject deplObject = new SPImportObject {
                    SourceUrl = login
                };
                this.ImportSettings.Logger.Log(DeploymentLogSeverity.Warning, deplObject, exception, false);
                if (this.ImportSettings.HaltOnWarning)
                {
                    throw;
                }
                flag = false;
            }
            return flag;
        }
        try
        {
            if (!string.IsNullOrEmpty(login) && !string.IsNullOrEmpty(SPUtility.GetProviderName(login)))
            {
                return SecurityObjectSerializer.ResolveUser(this.Context, base.Site.RootWeb, login, ref idNew);
            }
            flag = SecurityObjectSerializer.ResolveUser(this.Context, base.Site.RootWeb, sid, ref idNew);
        }
        catch (Exception exception2)
        {
            flag = false;
            SPException exception3 = new SPException(SPResource.GetString("UserCouldNotBeFound", new object[] { login }), exception2);
            this.ImportSettings.Logger.Log(DeploymentLogSeverity.Warning, exception3, false);
            if (this.ImportSettings.HaltOnWarning)
            {
                throw exception3;
            }
        }
        return flag;
    }
    

    et pour la vérification du nom du provider :

    public static string GetProviderName(string fullName)
    {
        if (string.IsNullOrEmpty(fullName))
        {
            throw new ArgumentNullException();
        }
        int index = fullName.IndexOf(':');
        if (index != -1)
        {
            return fullName.Substring(0, index);
        }
        return string.Empty;
    }

    Je pense que c'est bien un bug produit car la résolution par SID ou par login fonctionne bien dans d'autres pages.

    Okavango93

    samedi 1 février 2014 10:04

Toutes les réponses

  • Bonjour tout le monde,

    A ce que je vois, deux années (jour pour jour) se sont écoulées et toujours pas de réponse à ma question.

    :-)

    En fait, j'ai trouvé pourquoi les pages ne se créaient pas lors des exports/imports : en fouillant dans les DLLs (classe ImportObjectManager) de SharePoint et plus précisément dans l'API d'import/export de données, je suis remonté jusqu'au message d'erreur lu dans les logs.

    Il se trouve qu'il y a un test qui est effectué lors de la résolution d'un utilisateur qui, dans sa condition, vérifie si le login de l’utilisateur ne contient pas un deux points ":" et que dans le cas contraire, une résolution par SID (visiblement qui c'est ce qui échoue systématiquement) est effectuée.

    Voici des extraits de codes, l'exception levée est dans le dernier bloc try/catch :

    private bool EnsureUser(byte[] sid, string login, bool isRole, string display, string email, string notes, string mobilePhone, int flags, bool deleted, int idOld, out int idNew)
    {
        if (this.ImportSettings.UseSecurityMappingDirectly)
        {
            idNew = idOld;
            return true;
        }
        bool flag = true;
        idNew = -1;
        if (SecurityCheck.OnUserGroupImport(this.Context))
        {
            try
            {
                this.ImportSettings.Logger.Log(DeploymentLogSeverity.Progress, SPResource.GetString("UserImportExport", new object[] { SPResource.GetString("Importing", new object[0]), login }));
                base.Site.Request.EnsureUserExists(base.Site.Url, login, email, display, notes, mobilePhone, flags, isRole, false, true, ref sid, deleted, out idNew);
            }
            catch (Exception exception)
            {
                SPImportObject deplObject = new SPImportObject {
                    SourceUrl = login
                };
                this.ImportSettings.Logger.Log(DeploymentLogSeverity.Warning, deplObject, exception, false);
                if (this.ImportSettings.HaltOnWarning)
                {
                    throw;
                }
                flag = false;
            }
            return flag;
        }
        try
        {
            if (!string.IsNullOrEmpty(login) && !string.IsNullOrEmpty(SPUtility.GetProviderName(login)))
            {
                return SecurityObjectSerializer.ResolveUser(this.Context, base.Site.RootWeb, login, ref idNew);
            }
            flag = SecurityObjectSerializer.ResolveUser(this.Context, base.Site.RootWeb, sid, ref idNew);
        }
        catch (Exception exception2)
        {
            flag = false;
            SPException exception3 = new SPException(SPResource.GetString("UserCouldNotBeFound", new object[] { login }), exception2);
            this.ImportSettings.Logger.Log(DeploymentLogSeverity.Warning, exception3, false);
            if (this.ImportSettings.HaltOnWarning)
            {
                throw exception3;
            }
        }
        return flag;
    }
    

    et pour la vérification du nom du provider :

    public static string GetProviderName(string fullName)
    {
        if (string.IsNullOrEmpty(fullName))
        {
            throw new ArgumentNullException();
        }
        int index = fullName.IndexOf(':');
        if (index != -1)
        {
            return fullName.Substring(0, index);
        }
        return string.Empty;
    }

    Je pense que c'est bien un bug produit car la résolution par SID ou par login fonctionne bien dans d'autres pages.

    Okavango93

    samedi 1 février 2014 10:04
  • WOW! Merci pour votre retour après 2 ans!


    Microsoft SharePoint MVP. Community Warrior. Managing Consultant. TechNet Addict. Gokan contributes on @WikiNinjas.

    mercredi 5 février 2014 20:25