Roles: usuarios y permisos en moodle

En este microtaller describiré mis experiencias de administrador con lo que se ha traducido, mal, como roles en moodle.

Resumen del microtaller presentado en la sección MoodleMootNoUni de la MoodleMoot07 de Cáceres, el 16 de octubre de 2007.

Cuando las cosas eran sencillas

Cualquiera que haya utilizado una moodle en versiones anteriores a la 1.7 sabrá que las cosas estaban claras: sólo había 5 clases de usuarios — invitado, alumno (o cualquiera de sus sinónimos vergonzantes, participante, etc.), profesor (perdón: facilitador, tutor, asesor...), creador de cursos (escribo de memoria, creo que se llamaba así) y administrador. Cada uno de estos tipos de usuarios tenía un nivel de permisos predefinido y fijo, con pocas variantes: los participantes podían responder o no en determinados foros, podían iniciar discusiones nuevas o no, pero poco más. Además los roles y sus permisos se asignaban por curso.

Esta simplicidad hacía difícil cualquier uso no ortodoxo de la plataforma: ¿cómo permitir que los alumnos utilizaran el editor de páginas web, subieran ficheros o colocaran enlaces en la página principal del curso?

Había, claro, soluciones: el envío de ficheros se hacía o bien como adjuntos a mensajes de foros (lo que siempre es desordenado) o como respuesta a tareas (y entonces sólo facilitador y participante tienen acceso al fichero). Otra solución más radical es que todos los participantes en el curso tuvieran el nivel de profesores (en el mismo curso o en uno vinculado). Demasiada acracia para algunos.

Cuando los dioses quieren castigarnos

Ya se sabe: cuando los dioses quieren castigarnos nos conceden lo que pedimos. ¿Qué pedíamos? Lo que habíamos visto en otras plataformas, un sistema de usuarios y permisos configurable y granular. Y eso obtuvimos. Se nos olvidó pedir que fuera coherente.

Cualquiera que haya vivido la actualización de una plataforma 1.6 a una 1.7 con un número significativo de usuarios habrá pasado las mismas experiencias. En principio, en apariencia, la cosa estaba bien definida: se heredan los permisos de la versión 1.6 en los primeros nuevos roles predefinidos, y se crea una interfaz para configurar estos roles. Hermanos de experiencia, os contaré la mía.

Uno, prudente, ha hecho sus pruebas en el portátil, con sus cinco o seis alteregos, y decide que ya es hora de actualizar y disfrutar de bases de datos, roles y bitácoras. La actualización en local siempre tiene éxito, o lo parece: los alteregos son comprensivos y discretos. La actualización en serio con los tres mil usuarios de tu centro también parece ir bien. Se crean los roles, los permisos se heredan, nadie sabe cómo añadir usuarios a la plataforma o a un curso pero eso es un tigre de papel, cuestión de formación.

Todo parece ir bien y comienzas a relajarte. Craso error. Empiezas a percibir extrañas expresiones en las caras que te cruzas por los pasillos. Comentarios que no comprendes, guiños cómplices. ¿Guiños complices? Resulta que ese foro secreto, en el que montabas conspiraciones o quedadas cerveceras, ahora envía copias por correo de los mensajes a media institución. Claro, como fomento de la lectura y la transparencia institucional es un éxito. Pero a lo mejor no es lo que querías.

¿Qué ha pasado? Todavía no lo tengo del todo claro. Se me ocurren un par de hipótesis: que en la actualización se han confundido los contextos de «válido para toda la plataforma» y «válido para un curso determinado» y que algunas de las herencias de permisos se han cruzado o han heredado de la nada, con valores poco menos que aleatorios. Pero seamos serios: la solución no es difícil, consiste en definir valores razonables para las distintas acciones posibles.

Usuarios y permisos hoy

He tratado de presentar de forma humorística una anécdota que es historia hoy. El sistema de permisos en moodle es complejo pero perfectamente funcional. Lo que quizás no lo sea tanto, como ha admitido Martin Langhof, es su interfaz de configuración y seguimiento. Intentaré explicarlo para hacer visibles las mejoras necesarias.

En la actualidad un administrador puede trabajar con los usuarios clásicos o crear categorías nuevas de usuarios a partir de los usuarios preexistentes. Desde la versión 1.8 las propiedades de estas categorías de usuarios están determinadas por el contexto en el que se definen: un participante «de sitio» es participante en todos los cursos del sitio; pueden definirse roles para toda una categoría de cursos, para un curso, y la gran novedad, para una actividad o recurso en el interior del curso. Al fin la granularidad.

Quizás se entienda mejor con un ejemplo, supongamos que damos de alta a Martin Dougiamas como participante en un curso nuestro. Lo que realmente pueda hacer dependerá de si estaba ya definido como usuario de sitio (y con qué papel) y de la categoría a la que pertenece el curso. Pero eso no es todo: en cada uno de estos contextos es posible configurar qué puede hacer el usuario y, nuevo elemento de complejidad, modificar granular (palabra de moda) y localmente los permisos de un rol. Por ejemplo Martin, como usuario, en circunstancias normales no podría ver las calificaciones de los otros alumnos, pero podemos utilizar la interfaz «Anular roles» (extraña forma de referirse a modificar localmente los permisos asignados a un rol) para permitírselo. Este espacio sirve para arreglar problemas que no comprendes.

No sé si estoy siendo suficientemente claro. Contaré un caso. De hecho me ha pasado. He creado un curso y he asignado a una persona como «creadora de cursos». Días después me llama: no puede añadir nuevos temas al foro de novedades. ¿Cómo que no puedes añadir nuevos temas? ¡Un «creador de cursos» es uno de los niveles más altos en la escala de permisos!, ¡no puede ser! Pero era. Miro los permisos: hereda.

Vale, espera dos minutos que te lo arreglo. Y arreglado queda. Pero sigo sin entender (claro, podría ir mirando uno a uno todos los contextos del sitio y los permisos particulares de mi usuaria para saber qué pasa realmente) porqué una creadora de cursos no puede añadir nuevos hilos en un foro (conste que no es a propósito y tampoco tenéis pruebas). Lo que he añadido es una excepción local a una regla, lo que no me deja nada tranquilo, porque no sé cuándo me volverá a fallar la regla.

Lo que necesitamos (Martin Langhof habló de ello) es una interfaz para visualizar sinópticamente los distintos contextos jerárquicos que actúan sobre un usuario y una actividad. Supongo que no es fácil.

No sé esta charla ha aclarado algo. Espero por lo menos que no haya aburrido.