Es un pájaro! … NO!… Es un Bug! … NO!… Es: SuperPoint!

Una semana más de vida y una semana más de luchas con/contra SharePoint. Lo menos que se puede decir es que la vida de un pica-código no es excitante, James Bond es un guía turístico de picnics de monjitas en comparación.

Después de un par de “issues” que les comentaré más adelante, me he puesto a pensar cuál es la diferencia entre un bicho/“Bug”, una Interferencia/“Glitch” y un IND (“Issue Not Documented”)? A ver: un Bug es claramente una metida de pata, un Glitch es un “Upsss” que no debería haber pasado y que viene de vez en cuando y un IND es “By Design” siempre que nos pregunten, aunque para nosotros mismos es un enorme bicho… de acuerdo?

Veamos algunos ejemplos en nuestro bien amado SharePoint:

1 – Situación: Una Lista en donde tienes que cambiar programáticamente los derechos de cada elemento. Como el usuario no tiene derechos para cambiar la autorización, usamos “ElevatedRights” (método delegado “CodeToRunElevated” de la clase “SPSecurity”), y necesitamos romper la herencia de derechos de la Lista utilizando el método “BreakRoleInheritance” de la clase “SPListItem”. Para que todo funcione, necesitamos además utilizar la propiedad “AllowUnsafeUpdates” de la clase “SPWeb”. Más claro no canta una gallina…


miWeb.AllowUnsafeUpdates = true;

SPList miLista = miWeb.Lists[«unaLista»];

miLista.BreakRoleInheritance(false);


Problema: Ya tenemos nuestra Lista con sus propios derechos, magnifico. Ahora hay que darle derechos diferentes a uno de sus elementos:


SPListItem miElemento = miLista.GetItemById(1);

SPRoleAssignment AsignacionRole = new SPRoleAssignment(@»NombreServidorNombreUsuario», «a@b.com», «NombreUsuario», «ninguna nota»);

SPRoleDefinition DefinicionRole = miWeb.RoleDefinitions.GetByType(SPRoleType.Contributor);

AsignacionRole.RoleDefinitionBindings.Add(DefinicionRole);

miElemento.RoleAssignments.Add(AsignacionRole);

miElemento.Update();


Creamos el elemento, creamos el role que hay que darle, le asignamos el role al elemento y lo refrescamos. Perfecto… no funciona… error que dice que “Hay que refrescar la pagina” o algo por el estilo.

Workaround: después de una hora de sudor y lagrimas resulta que por una u otra razón desconocida, al llamar el “BreakRoleInheritance” el “AllowUnsafeUpdates” se regresa a “false” solito. Así que volviéndole a meter otra vez el renglón y poniéndolo en “true” antes de hacer el update, todo funciona a la perfección. Bug, Glitch o IND? Ustedes deciden

2 – Situación: De nuevo tenemos nuestra Lista y elemento del punto 1. Ahora queremos agregarle programáticamente un Content Type. Pan comido:


SPList miLista = miWeb.Lists[«unaLista»];

SPListItem miElemento = miLista.GetItemById(1);

SPContentType miTipo = miWeb.ContentTypes[«GustavoCT»];

miElemento.ContentTypes = miTipo;


el compilador lo acepta todo, pues la propiedad espera un set del tipo “SPContentType”, que es precisamente lo que le estoy entregando…

Problema: puedes compilar pero no ejecutar. Después de maldecir como un cosaco me acorde que ya me había pasado anteriormente, y que tenía que usar las propiedades:

Workaround:


miElemento[«ContentTypeId»] = miTipo.Id;


3 – Situación: Usando las pantallas de Configuración del sitio creas un Content Type propio. Ningún problema. Creas un Field Type propio. Ningún problema. Finalmente le conectas tu Content Type y tu Field Type a una Lista existente. Ningún problema.

Problema: Ahora queremos hacer que el Content Field sea incluido en el Content Type programáticamente:


SPContentType miTipo = miWeb.ContentTypes[«GustavoCT»];

SPField miCampo = miWeb.Fields[«GustavoFT»];

miTipo.Fields.Add(miCampo);


SharePoint pega un grito de aquí al otro lado: “Esta funcionalidad no está disponible para colecciones de campos que no están asociadas a una lista”… perdón? Lo último que hice fue conectar el Content Type a una Lista… pero bueno, un Glitch tal vez… a ver lo hago manualmente usando la Configuración del sito. Ningún problema… hmmm…

Workaround: Hasta ahora no he encontrado ninguno. Y si no me equivoco, este problema existe desde que SharePoint estaba en beta…

4 – Situación: Un usuario necesita conocer algunas propiedades de otro usuario que se encuentran en la Base de Datos de Perfiles de MOSS. Usuarios tienen derechos muy limitados para este tipo de búsquedas (solo pueden ver el nombre, E-mail y algo mas), así que hay que usar un impersonador.

Problema: Ni siquiera con un impersonador que utilice derechos de administrador es posible ver la información buscada, SharePoint devuelve cada vez un “No autorizado”.

Workaround: Desde la pantalla de Administración de Servicios Compartidos del servicio que contiene la Base de Datos de Perfiles que queremos utilizar, vaya a “Permisos de servicios de personalización” y agregue el grupo de usuarios “NT AUTHORITYusuarios autenticados” con los permisos “Crear un sitio personal”, “Utilizar características personales” y “Administrar los perfiles de usuario”. Significa esto un riesgo de seguridad? Parece que no según las últimas pruebas, pero que es un Bug/Glitch/IND, de eso no cabe duda.

Como dicen que la mala suerte viene en rachas de a tres, pues mi semana me ha agotado mi provisión de errores por un buen tiempo. Espero. También hay que ser justos y decir que en los miles y miles de renglones de código del Modelo de Objetos de SharePoint son muy pocas las situaciones que se encuentran como las que les comento. Y también decir que no es muy común de hacer lo que estaba intentando hacer aquí arriba (nunca le asignas un ContentType a un elemento de una lista, por ejemplo, se lo asignas a la lista completa). Ya me desearía yo escribir código que funcione con tan pocos problemas…

Ya se nos viene otra semana nuevecita y sin estrenar… a ver que nos trae…

 


Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…

4 comentarios sobre “Es un pájaro! … NO!… Es un Bug! … NO!… Es: SuperPoint!”

  1. Hola Juan Carlos.
    Si, me acuerdo que comentamos el problema hace unos meses, y que no encontramos salida por ningún lado, y que tu seguiste peleando con el por un tiempo. Tienes oportunidad de probar este workaround? A mí me ha servido, pero puede ser un caso aislado (yo no lo utilizo en una WebPart sino en una página aspx para contenido en SharePoint como CMS, característica de publicación).
    Un saludo, Gustavo

  2. Hola Gustavo!
    Con ese workaround si funciona, pero por temas de seguridad no lo consideramos. Preferimos crear un servicio windows que lea los profiles y los cargue en una lista de contactos estándar de SharePoint…Gracias por los apuntes.

    JC’s

  3. En el caso de agregar las columnas a los tipos de contenido de sitio, lo he conseguido agregando columnas de tipo SPFieldLink en la coleccion a la que se hace referencia dentro de la propiedad FieldLinks del tipo de contenido de sitio.

Responder a jcgonzalez Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *