Înlocuirea insignelor Open Badges native din Moodle cu Badges Ninja (designer mai bun, același API)

Moodle emite Open Badges nativ încă din versiunea 2.5, iar pentru mulți administratori de cursuri acesta este motiv suficient să nu caute mai departe. Este integrat, este gratuit și produce, din punct de vedere tehnic, o acreditare conformă cu standardul. Atunci de ce ajung atât de mulți administratori Moodle frustrați până emit a cincizecea insignă?

Răspunsul sincer: sistemul de insigne din Moodle a fost conceput pentru a bifa o căsuță de conformitate, nu pentru a fi un produs de acreditare. Funcționează, dar funcționează așa cum funcționează o caracteristică adăugată forțat pe un LMS – funcțională, învechită și limitată de constrângerile platformei în care trăiește. Dacă ai încercat vreodată să faci o insignă Moodle să arate altfel decât o iconiță circulară de clip-art, sau ai auzit un absolvent întrebând „stai, unde văd de fapt chestia asta din nou?”, deja cunoști diferența.

Acesta nu este un atac la adresa Moodle – este un LMS excelent, iar motorul său de criterii pentru insigne (finalizarea cursului, finalizarea activității, acordare manuală, apartenența la o cohortă) este chiar bine gândit pentru declanșarea unei acreditări. Problema este tot ce urmează după declanșare: instrumentele de design, experiența destinatarului și vizibilitatea insignei în afara instanței tale Moodle. Exact pentru asta este construit badges.ninja, iar pentru a-l folosi nu trebuie să renunți la logica de finalizare din Moodle – trebuie doar să direcționezi declanșatorul către un alt motor de emitere.

Unde eșuează insignele native din Moodle

Designerul este un compozitor de imagini bazat pe coordonate, nu un instrument de design. Editorul de insigne din Moodle îți permite să alegi o imagine de bază, să adaugi câteva suprapuneri de iconițe prestabilite și să ajustezi poziția prin decalaje în pixeli. Nu există bibliotecă de forme, nu există sistem de palete, nu există opțiuni de font în afara celor incluse în setul de iconițe. Dacă organizația ta are un brand – un logo, o paletă de culori, un limbaj vizual specific pentru certificările tale – editorul Moodle nu îl poate exprima. Majoritatea instituțiilor ajung să proiecteze grafica insignelor în Photoshop sau Canva și să încarce un PNG plat, ceea ce anulează sensul de a avea un designer integrat în aplicație.

Destinatarii au nevoie de o autentificare Moodle pentru a-și vedea propriile insigne. Insignele acordate unui cursant trăiesc în pagina lui de profil din Moodle. Dacă a trecut deja de curs, și-a uitat acreditările instituționale, sau instituția i-a dezactivat între timp contul, insigna dispare practic din perspectiva sa – chiar dacă afirmația (assertion) care stă la bază poate încă funcționa prin conectorul backpack al Moodle sau pagina publică a insignei. Nu există un loc dedicat, personalizat cu brandul, mereu accesibil, unde un destinatar să se poată autentifica doar cu emailul și să vadă fiecare acreditare pe care a obținut-o vreodată, din toate cursurile.

Distribuirea este un gând ulterior. Moodle poate trimite insigne către un serviciu compatibil Mozilla Backpack și expune o adresă URL publică de verificare pentru fiecare insignă, dar nu există un flux integrat „Adaugă pe LinkedIn”, niciun buton de distribuire cu un singur clic și nicio analiză a implicării care să arate dacă cineva s-a uitat vreodată la insignă după emitere. Pentru programele care vor ca insigna să funcționeze ca marketing prin recomandare – bootcamp-uri, furnizori de educație continuă, training corporativ – acesta este un cost de oportunitate real.

Operațiunile în masă sunt greoaie. Acordarea unei insigne unei întregi cohorte funcționează dacă toată lumea finalizează activitatea declanșatoare din Moodle în același timp. Dar dacă trebuie să completezi retroactiv insigne pentru o cohortă trecută, să imporți finalizări istorice dintr-un tabel, sau să emiți o insignă pentru ceva ce s-a întâmplat complet în afara LMS-ului, rămâi blocat scriind interogări SQL pe baza de date a Moodle sau luptându-te cu instrumente de import CSV care nu au fost construite special pentru insigne.

Modelul de înlocuire: păstrează declanșatoarele Moodle, schimbă emitentul

Nu trebuie să migrezi de pe Moodle pentru a rezolva asta. Cel mai curat model este să lași Moodle să continue să facă ceea ce știe cel mai bine – urmărirea finalizării cursului, finalizarea activității, apartenența la cohortă – și să-l pui să apeleze API-ul Badges Ninja în momentul în care se declanșează o condiție de finalizare, în loc de (sau pe lângă) acordarea insignei sale native.

Moodle susține acest lucru în câteva moduri:

1. Webhook pentru finalizarea cursului / interogare prin Moodle Web Services (REST). API-ul core_completion din Moodle expune starea de finalizare per utilizator per curs. O sarcină programată ușoară (o sarcină cron programată în Moodle, sau un job cron extern care apelează API-ul REST al Moodle) poate interoga periodic înscrierile nou finalizate și, pentru fiecare, poate apela endpoint-ul de acordare a insignelor Badges Ninja.

2. Un hook printr-un plugin local. Dacă ai un dezvoltator în echipă, sistemul de evenimente al Moodle (\core\event\course_completed) poate fi observat de un mic plugin local care declanșează o cerere HTTP chiar în momentul finalizării – fără întârzierea specifică interogării periodice.

3. Zapier/Make/n8n ca element de legătură, dacă preferi să eviți să atingi codul sursă al Moodle – Moodle poate trimite evenimente de finalizare către un receptor webhook pe care un instrument de automatizare no-code îl transformă într-un apel de acordare.

Iată apelul propriu-zis de acordare, odată ce ai numele și emailul unui utilizator care a finalizat cursul:

curl -X POST https://api.badges.ninja/awards \
  -H "X-Api-Key: bws_3f9a1c2d4e5b6a7c8d9e0f1a2b3c4d5e" \
  -H "Content-Type: application/json" \
  -d '{
    "badgeId": "badge_moodle_course_completion",
    "recipient": { "name": "Jordan Alvarez", "email": "learner@example.edu" },
    "issuedOn": "2026-08-31"
  }'

Sau în Node, în interiorul oricărei sarcini programate sau receptor webhook pe care îl rulezi:

const response = await fetch("https://api.badges.ninja/awards", {
  method: "POST",
  headers: {
    "X-Api-Key": process.env.BADGES_NINJA_API_KEY,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    badgeId: "badge_moodle_course_completion",
    recipient: { name: completedUser.fullname, email: completedUser.email },
    issuedOn: Date.now(),
  }),
});
const award = await response.json();

Emailul destinatarului este hashuit cu SHA-256 la stocare, acordarea primește automat o adresă URL unică de verificare, un cod QR și un certificat PDF în format A4, iar – esențial – destinatarul o poate revendica printr-o autentificare cu magic-link pe badges.ninja/me, fără să fie nevoie de un cont Moodle separat. Vezi structura completă a cererii/răspunsului în referința API pentru acordări și în ghidul de autentificare pentru a înțelege cum funcționează cheile API de la un capăt la altul.

Dacă preferi să o faci în lot – de exemplu, completând retroactiv finalizările unui semestru întreg dintr-o singură trecere, în loc să conectezi evenimente în timp real – exportă finalizările din Moodle ca CSV și folosește direct fluxul de acordare în masă, care susține pauză/reluare pentru fișiere mari. Acest lucru este detaliat în cum să emiți Open Badges dintr-un CSV.

Proiectarea insignei propriu-zise

Odată ce conexiunea este pusă la punct, proiectarea propriu-zisă a insignei durează minute, nu un tichet pentru echipa ta web. Designerul vizual îți oferă peste 80 de șabloane de forme, un sistem real de palete de culori, biblioteci de iconițe și încărcare de fonturi personalizate – astfel încât o insignă pentru „Statistică avansată – Finalizat” poate arăta cu adevărat ca și cum ar aparține brandului instituției tale, în loc de o iconiță generică de realizare din Moodle.

Fiecare cheie API are un domeniu limitat și poate fi revocată din același panou de control unde gestionezi insignele și emitenții, așa că predarea acreditării de integrare unui dezvoltator (sau unui instrument de automatizare precum Zapier) nu înseamnă partajarea datelor de autentificare ale contului tău principal.

Comparație directă: experiența destinatarului

Moodle câștigă totuși într-o privință: dacă singura ta cerință este ca „insigna să existe, să fie conformă tehnic cu Open Badge v2.0 și să trăiască în interiorul LMS-ului pe care cursantul îl folosește deja”, insignele native nu costă nimic în plus și nu necesită nicio muncă de integrare. Compromisul apare din momentul în care îți pasă de calitatea designului, de portabilitatea după terminarea cursului, sau de transformarea emiterii într-un semnal de recrutare/marketing – ceea ce, în cele din urmă, se aplică majorității instituțiilor.

Pentru o perspectivă mai amplă asupra modului în care alte platforme de Open Badges se compară la preț și funcționalități, vezi comparația celor mai ieftine platforme de Open Badges. Iar dacă instituția ta cântărește Open Badge v2.0 în raport cu noua specificație de acreditări verificabile, Open Badge v2 vs v3 explicat arată care variantă ar trebui folosită de fapt astăzi.

Ești pregătit să emiți prima ta acreditare verificabilă? Începe gratuit pe badges.ninja – designer vizual, pagină publică de verificare, certificat PDF, ieșire în format Open Badge v2.0. Nu este necesar cardul de credit.