Es importante conocer que en todo caso, cuando trabajamos en Gitlab.com somos usuarios de Gitlab.com aunque hayamos llegado a gitlab porque nos han invitado desde la UM o nos hayamos registrado con nuestra cuenta @um.es. Cuando un usuario es expulsado del grupo no se le da de baja en gitlab aunque deje de tener acceso a un grupo concreto. No hay inconveniente para que un usuario cree otros grupos fuera del grupo de la UMU y en ese caso están totalmente bajo su único control. Los repositorios dentro de la UMU están anidados dentro de un grupo organizativo llamado "umugit". Todos los objetos bajo ese grupo disfrutan de la licencia contratada por la universidad, mientras que cuando se está fuera de umugit tenemos funcionalidad de licencia "free".
Finalmente, se puede observar que en la mayoría de los grupos y repositorios hay usuarios en la lista de members que vienen heredados de un grupo superior al nuestro. Esos usuarios pueden ser los administradores de la Umu. Tienen que estar para que puedan ayudar con las incidencias. Si tenemos dudas sobre alguno de los usuarios de nuestra lista de podemos preguntar por Dumbo.
Se puede invitar a cualquier usuario de Gitlab a colaborar en nuestros grupos y en nuestros proyectos. Se puede usar el id de gitlab o una cuenta de correo. Si gitlab no encuentra el correo, enviará una invitación al usuario. No restringimos a cuentas @um.es
Si la invitación se hace desde un grupo, el usuario queda invitado de forma recursiva a los subgrupos y repositorios anidados.
La forma de hacerlo es ir posicionarnos en el grupo o proyecto en cuestión y seleccionar "Manage" (gestión) en el menú de la izquierda. Dentro encontramos la lista de miembros con algún rol.
En la parte derecha aparece el botón "Invite members"
En todo momento se puede expulsar a un invitado.
La ventana de invitación nos permite decidir el poder con el que podrá desenvolverse el nuevo miembro y la caducidad de la invitación.
Gitlab.com tienen muchas funcionalidades asociadas a diferentes tipos de tarea. Los roles tienen una interpretación parecida con matices. Por ejemplo, un owner tiene poder absoluto y un guest prácticamente es solo ver. Los roles intermedios tienen capacidades adaptadas en cada caso. Nos remitimos a la documentación oficial actualizada para entender estos aspectos: https://docs.gitlab.com/ee/user/permissions.html