Artículo original publicado el martes, 28 de junio de 2011

Hace poco surgió un problema que resultó bastante difícil de localizar, por lo que pensé en compartir el problema y la solución. En este caso, se había desarrollado un proveedor de notificaciones personalizado y se estaba usando como proveedor de notificaciones predeterminado para el SPTrustedIdentityTokenIssuer, tal como se describe aquí:  http://blogs.technet.com/b/speschka/archive/2010/04/28/how-to-override-the-default-name-resolution-and-claims-provider-in-sharepoint-2010.aspx. Puede parecer estar funcionando en algunos casos: puede buscar algo, muestra la lista de coincidencias, selecciona una y luego hace clic en el botón Aceptar. En algunos casos, todo funciona bien (el cuadro de diálogo desaparece y ve el nombre resuelto en el tipo en control). Además, puede establecer un punto de interrupción en el método FillResolve y pasar por él.

Sin embargo, en algunos casos ve este comportamiento:

  • Se cierra el cuadro de diálogo del selector de personas
  • El tipo en control es blanco - nada (resuelto o no) aparece
  • Si establece un punto de interrupción en FillResolve, nunca se llega a él
  • Si mira en los registros de ULS, no ve errores

En este caso, lo que finalmente determiné que estaba sucediendo es que el proveedor de notificaciones personalizado estaba agregando un tipo de notificaciones que no tenía una asignación correspondiente en el SPTrustedIdentityTokenIssuer. Por ejemplo, estaba creando una notificación donde el tipo de notificación era http://schemas.steve.com/foo, pero la lista de asignaciones de notificaciones para el SPTrustedIdentityTokenIssuer no tenía una asignación para http://schemas.steve.com/foo (para ver un ejemplo de asignaciones de notificaciones y cómo se crean, consulte http://blogs.technet.com/b/speschka/archive/2010/02/17/creating-both-an-identity-and-role-claim-for-a-sharepoint-2010-claims-auth-application.aspx). Así que en lugar de agregar una notificación que SharePoint sabe que no está asignada, en algún lugar de la canalización simplemente se lo come y aparece una pantalla en blanco, sin ningún mensaje de error. Y por eso se puede tardar tanto en localizar.

Para este problema en particular, terminamos destruyendo el SPTrustedIdentityTokenIssuer y volviendo a crearlo, pero agregando una nueva asignación para el tipo de notificación que estaba desapareciendo del selector de personas. Ejecutamos el código nuevamente y todo “simplemente funcionó” de inmediato, así que eso confirmó el problema y la solución.

Esta entrada de blog es una traducción. Puede consultar el artículo original en Name Disappears After Selecting in People Picker with Custom Claims Provider in SharePoint 2010