Comment modifier de manière programmable les autorisations de niveau d'élément avant la première sauvegarde?

Question

J'ai une situation où il existe des exigences d'autorisations strictes sur une liste dont j'ai déjà écrit un formulaire personnalisé. L'exigence est qu'à la création, sur la base de métadonnées, seuls certains utilisateurs ont accès à lire et à écrire l'article.

Ma première tentative de cette première tentative était de mettre cela dans un récepteur d'événement sur la liste pour vous assurer que les autorisations sont mises à jour lorsque l'article est ajouté. Je mets l'article dans l'élément ajouté de l'article puisque pendant l'élément ajoutant, je n'ai pas le moyen d'élever des privilèges et d'obtenir une instance élevée de l'article (que je connaisse). Cela a provoqué un retard indésirable, bien que court, entre le moment où l'article a été créé et le moment où le code a réellement couru.

La prochaine chose que j'ai essayée était de mettre les autorisations d'article dans le formulaire immédiatement après la création de l'élément depuis que je disposerais d'un identifiant pour l'article afin que je puisse le récupérer dans un contexte surélevé (je veux que l'article soit créé dans le contexte de l'utilisateur actuel). Cela pose problème car dès que cette approche a été mise en œuvre, environ 50% du temps que nous obtenons une erreur dans un flux de travail qui fonctionne sur l'élément crée: "Impossible de démarrer le flux de travail. Le flux de travail ne peut pas accéder à l'élément qui est appliqué. " (Il vaut probablement la peine de noter que ceci est un flux de travail Nintex) - je suppose que le problème est dû à une condition de raquette où au milieu de l'élément.Update () pour définir les autorisations, le flux de travail tente de commencer à la fois.

Idéalement, je voudrais pouvoir mettre à jour les autorisations sur la toute première mise à jour de l'élément (Créer) ou pendant un événement ItemAdding, mais je ne sais pas comment procéder à cela sans élever l'ensemble du processus de sorte que l'article soit créé par l'article. Le compte système et non l'utilisateur qui a réellement créé l'article.

Quelles options ai-je à votre disposition?

Answer 1

La façon dont vous l'avez initialement utilisée à l'aide de l'événement d'articleAdded était correcte.Il ne manque qu'une seule étape manquante, vous pouvez rendre l'événement à exécuter immédiatement en le modifiant pour fonctionner de manière synchrone au lieu d'asynchrone.

Détails de la procédure à suivre pour commuter le mode synchrone sont ici: http://blogs.technet.com/b/stefan_gossner/archive/2011/11/10/Unuant-synchronous-quot-after-Quot-événements-EG-itemUpAndated-in-SharePoint-2010.aspx

Answer 2

Une approche que vous pourriez essayer, permet une approbation de contenu sur cette liste.Cela signifiera que chaque fois qu'un nouvel élément est créé, il restera dans en attente de statut jusqu'à ce qu'il soit approuvé.Lorsqu'un article est en attente en attente, seul l'expéditeur de l'article et les personnes qui ont des autorisations pour gérer des listes et des bibliothèques peuvent le voir, à condition que vous ayez choisi le paramètre suivant: qui devrait voir des éléments de projet dans cette bibliothèque de documents?-> Seuls les utilisateurs qui peuvent approuver des éléments (et l'auteur de l'article). Ensuite, vous pouvez utiliser l'événement ItemAjouté pour modifier les autorisations du fichier et mettre également dans l'état approuvé .

J'espère que cela vous aidera à sortir dans votre scénario particulier.

Answer 3

Vous devriez pouvoir imiter l'utilisateur qui a créé l'élément ou apporté le changement dans votre code.

    public override void ItemUpdating(SPItemEventProperties properties)     
       {     
           base.ItemUpdating(properties);

           SPUserToken objSPUserToken = properties.OriginatingUserToken;

           if (objSPUserToken != null) 
           { 
               using (SPSite objSPSite = new SPSite(properties.SiteId, objSPUserToken)) 
               { 
                   using (SPWeb objSPWeb = objSPSite.OpenWeb())

                   { 
                       //You can perform user context specific changes here... 
                   } 
               } 
           }
       }

Elevation d'impersonnation des privilèges

Imperson de l'événement dans SharePoint 2010

Answer 4

Ce que j'ai fait pour contourner ce problème est de commencer automatiquement le flux de travail via les paramètres du flux de travail, nous sommes "manuellement" à partir du flux de travail via le code après mise à jour.

string workflowId = "{...}"; //dynamically retrieve workflow id
SPWorkflowManager workflowManager = item.Web.Site.WorkflowManager;
SPWorkflowAssociationCollection workflowCollection = item.ParentList.WorkflowAssociations;

foreach (SPWorkflowAssociation workflow in workflowCollection)
{
    if (String.Compare(workflow.BaseId.ToString("B"), workflowId, true) == 0)
    {
        workflowManager.StartWorkflow(item, workflow, workflow.AssociationData, true);
        break;
    }
}