Problem
Grupo IOE / UNADE runs many live Zoom sessions inside Moodle, and the stock mod_zoom module forces you to create each videoconference by hand, one at a time, inside each course. With dozens of sessions scheduled every term, that manual setup was slow, repetitive and error-prone: wrong dates, sessions in the wrong course, or the wrong teacher attached. The built-in attendance tracking also did not match how UNADE needs to evidence real participation, especially when someone joins Zoom under a name that does not match their Moodle account.
Solution
I started from the official mod_zoom module and built my own fork, mod_zoomioe, keeping the Zoom API integration and layering a videoconference queue (vc_queue) on top. The core is a new table and a model that resolves the course by ID or idnumber, computes duration from start and end times, and validates each row through a state machine (draft, pending, queued, created, error). A coordinator uploads a CSV of the term’s sessions, reviews them in a filterable table, and triggers bulk creation: an adhoc task creates each Zoom activity, records the per-row outcome, and emails a summary with the links. I also added custom attendance and participant-management pages to reassign raw Zoom entries to real Moodle users.
Result
A complete, stable activity module running in production on UNADE’s platform. What used to be creating videoconferences one by one becomes upload a CSV, review, click once — with clear statuses and per-row error traceability. On top of the 10 tables and 23 pages inherited from mod_zoom, the vc_queue layer (around 2,300 new, bilingual ES/EN lines) adds the bulk provisioning and attendance control the stock module lacks, all gated behind a dedicated capability so only managers operate the queue.