2009-04-22 21 views
13

Tenemos un elemento web que carga un documento a una biblioteca de documentos. El usuario que carga el documento puede no tener acceso a la ubicación de destino, por lo que el código que agrega el archivo se ejecuta dentro de un bloque RunWithElevatedPrivileges. Esto significa que el campo "Modificado por" siempre se establece en Cuenta del sistema. Aquí está el código:¿Cómo se puede modificar "Modificado por" cuando se usa RunWithElevatedPrivileges?

SPSecurity.RunWithElevatedPrivileges(
    delegate 
    { 
     using (SPSite elevatedSite = new SPSite(SPContext.Current.Site.Url)) 
     using (SPWeb targetWeb = elevatedSite.OpenWeb(webUrl)) 
     { 
      targetWeb.AllowUnsafeUpdates = true; 
      SPFile newFile = files.Add(filename, file); 
      SPListItem item = newFile.Item; 

      // TODO: Insert code to set Modified By 

      item.SystemUpdate(); 
     } 
    } 
} 

El "Modificado por" campo necesita ser definido como el nombre del usuario actual (en la línea TODO arriba), pero ninguno de los siguientes intentos han trabajado:

item["Modified By"] = SPContext.Current.Web.CurrentUser; 

item["Author"] = SPContext.Current.Web.CurrentUser; 

item["Modified By"] = new SPFieldUserValue(
SPContext.Current.Web, SPContext.Current.Web.CurrentUser.ID, 
SPContext.Current.Web.CurrentUser.Name); 

item["Author"] = new SPFieldUserValue(
SPContext.Current.Web, SPContext.Current.Web.CurrentUser.ID, 
SPContext.Current.Web.CurrentUser.Name); 

¿Alguien sabe de una solución que permite cambiar el valor "Modificado por"?

Respuesta

10

he hecho un poco más pruebas ...

item["Editor"] = SPContext.Current.Web.CurrentUser; 
item["Author"] = SPContext.Current.Web.CurrentUser; 
item.SystemUpdate(); 

Creado Por está establecido para el usuario actual, pero Modificado por está ajustado a cuenta del sistema.

item["Editor"] = SPContext.Current.Web.CurrentUser; 
item["Author"] = SPContext.Current.Web.CurrentUser; 
item.Update(); 

Ambos creados por y Modificados por se configuran para el usuario actual.

El problema fue utilizar SPListItem.SystemUpdate(), que hace exactamente lo contrario de lo que indica la documentación de API, al menos cuando se ejecuta con privilegios elevados.

Nota: SPContext.Current.Web.CurrentUser no recoger el usuario actual y no la cuenta de sistema cuando se ejecutan dentro SPSecurity.RunWithElevatedPrivileges. (Si debe usarse así, es otra pregunta).

+0

Gran ayuda, +1 ... –

+0

Comportamiento extraño de las llamadas. Gracias, por publicar la solución. Me ayudó. –

+0

tengo un problema en mi biblioteca de documentos donde he habilitado el check-in y check-out. así que cuando se llama mi itemupdate sigo recibiendo la modificación como "cuenta del sistema" y cuando lo intento con listitem ["Editor"] = ospuser.ID; , estoy de nuevo recibiendo un check out y un error de registro. pls ayuda – SaMolPP

6

Una forma de resolver esto es almacenando el usuario actualmente registrado en la memoria antes de elevando los permisos. Más adelante en la solicitud de actualización, reemplace la 'Cuenta del sistema' con su variable.

ver más abajo:

// Keep a reference of the Logged in user in memory 
SPUser currentUser = SPContext.Current.Web.CurrentUser; 

SPSecurity.RunWithElevatedPrivileges(
delegate 
{ 
    using (SPSite elevatedSite = new SPSite(SPContext.Current.Site.Url)) 
    using (SPWeb targetWeb = elevatedSite.OpenWeb(webUrl)) 
    { 
     targetWeb.AllowUnsafeUpdates = true; 
     SPFile newFile = files.Add(filename, file); 
     SPListItem item = newFile.Item; 

     // Replace 'System Account' with current user 
     item["Author"] = currentUser; 
     item["Modified By"] = currentUser; 

     item.SystemUpdate(); 
    } 
}); 

espero que esto ayude.

+0

No olvides establecer targetWeb.AllowUnsafeUpdates en falso. Te gustaría hacer eso en el {} bloque final. –

0

¿Has probado esto en lugar de SPSecurity.RunWithElevatedPrivileges?

using (WindowsImpersonationContext w = WindowsIdentity.Impersonate(IntPtr.Zero)) 
{ 
    //Do stuff here 
} 
+0

Sugiero leer en Windows Impersonation y SharePoint –

1

Hacer como (Henrique Zacchi) escribe, pero crea un método de extensión de envoltura que toma SPUser como un parámetro adicional. Entonces úsalo.

1

RunWithElevatedPrivileges siempre crea un nuevo hilo dentro del hilo actual con la identidad de la AppPool. Entonces, dentro de este delegado, el contexto pertenece a la cuenta del sistema.

Cuestiones relacionadas