Posterior a de una larga búsqueda de datos resolvimos este asunto que presentan algunos de nuestros lectores. Te ofrecemos la respuesta y deseamos que resulte de gran apoyo.
Solución:
El blog al que vinculó tiene la respuesta correcta. No es óptimo, pero funciona.
Una fuente de confusión es que después de crear un sitio de grupo, hay dos grupos con el mismo nombre. Por ejemplo, si crea un nuevo sitio de grupo llamado “proyecto 1”, se crearán los siguientes grupos:
- “proyecto 1”: este grupo está visible en la lista de grupos en la consola de administración. La consola de administración mostrará que este grupo tiene una dirección de correo electrónico y una tipo de grupo de Office 365. La consola de administración también mostrará la lista de propietarios y miembros. Al ver la página de inicio del sitio, mostrará “x miembros” en la esquina superior derecha. al hacer clic en él, se mostrarán los miembros de este grupo.
- “miembros del proyecto 1”: este grupo es visible navegando a los permisos del sitio -> avanzado. Esta página mostrará este grupo (más otros) y tendrá un tipo de grupo de “Grupo de SharePoint”. Este grupo tendrá un nivel de permiso de edición predeterminado.
- “propietarios del proyecto 1”: igual que el anterior, con un nivel de permiso de control total
- “visitantes del proyecto 1”: igual que el anterior, con un nivel de permiso de lectura
Si hace clic en el grupo de SharePoint de miembros del proyecto 1, verá que tiene un miembro de forma predeterminada: “miembros del proyecto 1”, que son los miembros del grupo de Office 365.
Si regresa a la página de inicio y a los permisos del sitio, verá listados de propietarios, miembros y visitantes del sitio. Estas son referencias a los grupos de SharePoint. El grupo de miembros del sitio mostrará un miembro, “miembros del proyecto 1 miembros”. Cambiar el menú desplegable de editar a leer no cambia los permisos del grupo de SharePoint, sino que mueve el grupo de Office 365 fuera del grupo sharepoint de miembros del proyecto 1 y dentro del grupo sharepoint de visitantes del proyecto 1.
Dado lo anterior:
- navegue a la pantalla de permisos avanzados y haga clic en el grupo de SharePoint de miembros del proyecto 1
- haga clic en la casilla de verificación junto al grupo de Office 365 de miembros del proyecto 1
- haga clic en acciones -> eliminar usuarios del grupo
- Vuelva a la pantalla de permisos avanzados, cree un nuevo grupo de SharePoint y dele permisos de contribución. Después de crear el grupo, debería llevarlo a la página de personas y grupos, que muestra la membresía de su nuevo grupo. haga clic en “nuevo” y agregue el grupo de miembros del proyecto 1 a su nuevo grupo. (este será el grupo de Office 365).
Una vez que haya hecho lo anterior:
- Los miembros del grupo de Office 365 del proyecto 1 tendrán acceso de contribución.
- Hacer clic en el enlace de x miembros en la página de inicio y modificar la membresía del grupo funcionará bien, ya que aún modifica la membresía del grupo de Office 365, que tiene acceso de contribución.
- al hacer clic en “permisos del sitio”, se mostrarán los propietarios del proyecto 1 con control total, pero no se mostrará a nadie como miembro o visitante. Este es el defecto de este enfoque. El grupo tiene acceso de contribución, pero esta pantalla no lo mostrará. En cambio, este panel simplemente indicará “hay grupos adicionales con permisos en este sitio”.
(En mi procedimiento, eliminé el Grupo de O365 del Grupo de SharePoint. En la publicación de blog a la que vinculó, Paul sugiere cambiarlo a un visitante. No estoy seguro de cuál me gusta más. El enfoque de Paul aún hace que el grupo sea visible en el panel de permisos del sitio, pero eso también hace que sea realmente fácil para un usuario cambiarlos de nuevo a miembro, anulando el propósito de todo esto).
Por lo tanto, no es una solución perfecta, ya que el panel de permisos del sitio no le permite ver o cambiar los permisos de los miembros, y cualquier cambio adicional deberá realizarse en la pantalla de permisos avanzados del sitio. Sin embargo, esto preserva la capacidad de modificar la lista de miembros del sitio a través del panel de “pertenencia al grupo” de la página de inicio.
editar: mencioné que la otra publicación no era “óptima”. Esto no fue una crítica a la publicación del blog, sino que me gustaría que MS nos proporcionara una forma de prescindir de todo lo anterior.
Cuando crea un sitio de grupo moderno, automáticamente crea un grupo de Office 365 (grupo de anuncios azul) que contiene a todos los miembros y se agrega al grupo de sharepoint de los miembros del sitio. Cuando agrega un usuario o invita a un usuario desde la interfaz de usuario moderna, esencialmente está agregando el usuario al grupo de anuncios de Azure. Los servicios conectados al grupo de Office 365, como el buzón de correo compartido, el planificador, etc., utilizan el mismo grupo azul para administrar los permisos en los servicios respectivos. De esta forma, si se agrega un usuario al grupo, se actualizan los permisos de todos los servicios conectados.
Cuando crea un nuevo grupo de SharePoint y agrega usuarios directamente, esos usuarios solo obtienen acceso al sitio de SharePoint y no podrán aprovechar ningún otro servicio conectado, ya que no forman parte del grupo de Azure.
Puede crear un grupo de SharePoint y agregarle el grupo azul y luego asignarle el permiso de contribución al grupo de SharePoint tal como se menciona en el enlace de su pregunta y otra respuesta (para garantizar que los usuarios sean administrados por el grupo de anuncios azul), personalmente no lo haría lo recomiendo.
Un problema que sé es que si el grupo está conectado al equipo de MS, y luego el usuario intenta agregar una pestaña wiki por primera vez, se encontrará con un error debido al hecho de que solo tiene permiso de contribución en el sitio de SharePoint correspondiente. La primera vez que agrega una pestaña wiki, intenta proporcionar una lista y biblioteca (datos del equipo wiki) que requiere que el usuario tenga el permiso ‘agregar lista’ como parte del nivel de permiso ‘Editar’.
Como MS actualiza continuamente los servicios, nunca se sabe qué tipo de dependencia de servicios cruzados pueden agregar y, por lo tanto, romper sus cambios.
Si no necesita los servicios proporcionados por un sitio de grupo moderno, personalmente recomendaría crear un sitio de grupo clásico y habilitar la experiencia moderna a nivel de biblioteca (si el nivel de inquilino está configurado para usar clásico). De esta manera, puede administrar los permisos de la manera que desee. También tiene la opción de conectarse a un grupo de Office 365 en caso de que sus requisitos cambien en el futuro.
Si te gusta la programación, eres capaz de dejar una crónica acerca de qué le añadirías a este tutorial.