Moodle Alta Usuarios

Moodle Alta Usuarios

Automatiza, con seguridad de por medio, el flujo completo de dar de alta usuarios en un Moodle real a partir de listados de alumnos: identificar quién ya existe, armar el CSV correcto, subirlo, y dejar un registro de qué cuenta quedó con qué credencial. El principio que ordena todo: "matricular a alguien en un curso" y "crear su cuenta de usuario" son dos operaciones distintas, y esta skill solo hace la segunda — nunca toca una cuenta existente sin que el usuario haya confirmado, en una frase, la consecuencia concreta de hacerlo.

Cuándo aplica

El usuario administra un campus Moodle y usó (o va a usar) la carga masiva para matricular alumnos, y descubre que algunos no pueden entrar porque nunca tuvieron cuenta de usuario — o directamente arranca sabiendo que tiene que dar de alta un listado nuevo. Tiene a mano archivos por comisión (CSV o una planilla XLSX) con nombre y, típicamente, dos correos por alumno (personal e institucional). No sabe de antemano quién ya está en el campus ni con cuál de los dos correos.

Las 10 etapas

1. Inspección (solo lectura)   → entender la pantalla real de Moodle
2. Auditoría de archivos       → leer roster(s) sin modificarlos
3. Identificación              → clasificar A/B/C contra el padrón de Moodle
4. Mostrar clasificación       → PARAR, esperar confirmación
5. Definir política de alta    → email a usar, username, password, forzar cambio
6. Generar y validar el CSV    → PARAR, mostrar resumen, esperar confirmación
7. Preparar la carga           → llegar a la previsualización de Moodle (paso 2)
8. Confirmación final          → resumen en texto plano, esperar "sí" explícito
9. Ejecutar                    → click real en "Subir usuarios"
10. Verificar y registrar      → leer resultados, guardar archivo de salida

Las etapas 4, 6 y 8 son compuertas de aprobación — no se avanza sin que el usuario las haya cruzado explícitamente. El detalle completo de cómo pedir cada confirmación (qué decir, qué NO alcanza como confirmación válida) está en references/confirmation-protocol.md — leelo antes de la primera vez que vayas a tocar una cuenta existente, es la parte que más importa de toda la skill.

Fase 1 — Arrancar: URL del campus y archivos de alumnos

Preguntá la URL real del campus (https://<dominio>/admin/tool/uploaduser/index.php) si no te la dieron. Nunca reutilices un dominio de una sesión anterior ni asumas un patrón — cada campus es distinto, y hardcodear un dominio es exactamente el tipo de atajo que rompe la skill la próxima vez que se use en otra institución.

Pedí los archivos de alumnos: uno o varios CSV (uno por comisión) o una planilla XLSX. No asumas la estructura de columnas — scripts/parse_roster.js detecta encabezados de forma flexible (nombre completo vs. separado, correo personal vs. institucional, con o sin acentos) pero siempre imprime el mapeo que detectó; mostráselo al usuario antes de seguir. Si el input es XLSX, references/windows-scripting-notes.md explica la dependencia opcional (xlsx de npm).

Seguí el procedimiento de navegador de references/browser-workflow.md para inspeccionar la pantalla "Subir usuarios" y confirmar que hay sesión iniciada — sin subir nada todavía.

Fase 2 — Identificar quién ya existe

Exportá el padrón completo de usuarios del campus (botón "Descargar datos de tabla como > CSV" en admin/user.php — pedile permiso al usuario antes de descargar, y explicá qué es). No scrapees la lista paginada: se trunca sin avisar de forma obvia a partir de unos cientos de usuarios. El detalle completo, incluido el patrón más común que vas a encontrar (la misma persona con dos cuentas — una por cada correo), está en references/identification-strategy.md.

Corré scripts/cross_reference.js para clasificar cada alumno en A (existente, no tocar), B (nuevo confirmado), o C (ambiguo — con el sub-caso de "mismo nombre en dos cuentas" separado de la ambigüedad real). Mostrale al usuario el resumen de las cuatro categorías antes de generar ningún CSV — esta es la etapa 4 del protocolo, una compuerta dura.

Fase 3 — Política de alta y generación del CSV

Con la clasificación aprobada, definí junto al usuario (nunca por tu cuenta): qué correo usar como email de Moodle, esquema de username (parte local del correo, o el correo completo), contraseña inicial, y si se fuerza el cambio en el primer ingreso. references/moodle-csv-fields.md tiene la semántica exacta de cada opción de Moodle (incluido el error real y reproducible de poner forcepasswordchange como columna — no existe, se configura en el paso 2 de la carga).

Generá el archivo con scripts/build_upload_csv.js — por defecto solo incluye la categoría B (nuevos confirmados); incluir A o C requiere el flag --allow-existing a propósito, para que sea imposible tocar una cuenta existente por accidente de configuración. Validalo con scripts/validate_csv.js antes de subir nada — atrapa columnas inválidas, usernames con caracteres prohibidos, y duplicados, todo ANTES de que Moodle te lo rechace a mitad de camino.

Fase 4 — Subir y ejecutar

Seguí references/browser-workflow.md paso a paso: seleccionar archivo, separador, llegar a la previsualización, configurar el "Tipo de subida" (el default seguro es "Agregar sólo nuevos, pasar por alto usuarios existentes") y el resto de las opciones. Cualquier configuración que toque cuentas existentes es la compuerta reforzada de references/confirmation-protocol.md — no la actives sin haber reformulado la consecuencia concreta y recibido un "sí" específico a esa consecuencia.

Después de ejecutar, leé la pantalla de resultados completa, y si hay errores parate a mostrarlos — no reintentes nada por tu cuenta.

Fase 5 — Registro de salida

Armá el JSON de resultados (ver formato en scripts/write_output_log.js) y generá el archivo de texto final en la carpeta de trabajo del usuario, no dentro de la skill. Es el único registro de qué contraseña quedó en qué cuenta — sin él esa información se pierde apenas cerrás la sesión.

Reglas duras

• Nunca hardcodees la URL del campus. Preguntala siempre, cada sesión.
• Nunca actives un "Tipo de subida" que actualice cuentas existentes sin la confirmación explícita descripta en references/confirmation-protocol.md. Esto incluye sobrescribir contraseña, renombrar username, o pisar nombre/apellido de una cuenta que ya funciona.
• Nunca ejecutes la carga real (el submit final del paso de Configuración) sin haber mostrado antes, en texto plano, exactamente qué configuración está activa.
• Si el sistema bloquea un permiso solo, no busques la forma de esquivarlo. Avisá al usuario y dejá que decida.
• Siempre generá el archivo de registro de salida al final de una carga exitosa, aunque el usuario no lo pida explícitamente — es la única forma de no perder qué contraseña quedó en qué cuenta.

Componentes de la skill