# Moodle Alta Usuarios

> Gestiona el alta y actualización segura de usuarios en un campus Moodle vía la herramienta "Subir usuarios" (admin/tool/uploaduser): recibe listados de alumnos por comisión (uno o varios CSV, o una planilla XLSX) con su correo personal e institucional, cruza contra los usuarios que YA EXISTEN en el campus para no duplicar cuentas ni pisar credenciales que ya funcionan, arma el CSV de carga en el formato exacto que exige Moodle, y ejecuta la subida por navegador con múltiples puntos de confirmación explícita antes de cualquier acción irreversible. Usar SIEMPRE que el usuario quiera dar de alta/crear usuarios en Moodle a partir de un listado de alumnos, resolver el error "Acceso inválido" tras una matriculación masiva (bulk enrolment), subir un CSV a la pantalla "Subir usuarios" de Moodle, decidir si un alumno ya existe en el campus antes de crearlo, o generar cuentas iniciales con contraseña por defecto y cambio obligatorio — aunque lo pida con otras palabras: "dar de alta a estos alumnos en moodle", "necesito

- Skill: `juancruzrobledo/moodle-alta-usuarios` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add juancruzrobledo/moodle-alta-usuarios`
- Raw SKILL.md: https://api.skillmd.com/api/skills/juancruzrobledo/moodle-alta-usuarios/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- License: Apache-2.0
- Author: juancruzrobledo (https://skillmd.com/u/juancruzrobledo)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/juancruzrobledo/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

| Archivo | Para qué |
|---|---|
| `scripts/parse_roster.js` | Normaliza CSV(s) por comisión o una planilla XLSX a `students.json`, detectando encabezados de forma flexible |
| `scripts/cross_reference.js` | Clasifica cada alumno en A/B/C contra el export de usuarios de Moodle |
| `scripts/build_upload_csv.js` | Arma el CSV final para Moodle a partir de la clasificación + política de alta explícita |
| `scripts/validate_csv.js` | Valida el CSV contra las reglas reales de Moodle antes de subirlo |
| `scripts/write_output_log.js` | Genera el archivo de registro final (cuentas creadas/actualizadas) |
| `references/identification-strategy.md` | Cómo determinar si un alumno ya existe; el patrón de cuentas duplicadas |
| `references/moodle-csv-fields.md` | Campos válidos del CSV, semántica de cada opción de la pantalla de carga |
| `references/browser-workflow.md` | Procedimiento paso a paso con claude-in-chrome |
| `references/confirmation-protocol.md` | Las compuertas de aprobación — leer antes de tocar cuentas existentes |
| `references/windows-scripting-notes.md` | Gotchas de Node/Bash en Windows y la dependencia opcional de xlsx |
| `assets/example.csv` | Archivo de ejemplo oficial de Moodle, formato mínimo |
| `assets/templates/roster-comision-template.csv` | Plantilla de listado de alumnos por comisión |
| `assets/templates/output-log-template.txt` | Formato del archivo de registro final |