...
| Info | ||
|---|---|---|
| ||
Cette solution repose totalement sur Pod et n'impacte en rien BigBlueButton. Aucune modification n'est à réaliser côté BigBlueButton. |
| Avertissement | ||
|---|---|---|
| ||
Les informations concernant les modérateurs dans BigBlueButton dépendent du client BBB utilisé : Greenlight ou le plugin mod_bigbluebuttonbn pour Moodle. Le système réalisé n'a été testé qu'avec le plugin mod_bigbluebuttonbn pour Moodle (CASifié, donc les données proviennent de notre annuaire LDAP); cela signifie que les modérateurs sont définis sous la forme "Prenom Nom".
|
Architecture de la solution
...
L'idée des 4 jours est d'éviter de traiter les enregistrements qui ont été supprimés ou avec de mauvaises données dans la base de données.
| Info | ||
|---|---|---|
| ||
Au final, l'API BigBlueButton présente un statut d'enregistrement (attribut recording) mais qui s'avère peu fiable. Dans l'environnement UM, il est quasiment tout le temps à vrai, alors que les sessions n'ont pas été enregistrées. |
...
| Avertissement | ||
|---|---|---|
| ||
Les Je me répète, mais les informations concernant les modérateurs dans BigBlueButton dépendent du client BBB utilisé : Greenlight ou le plugin mod_bigbluebuttonbn pour Moodle. Le système réalisé n'a été testé qu'avec le plugin mod_bigbluebuttonbn pour Moodle (CASifié, donc les données proviennent de notre annuaire LDAP); cela signifie que les modérateurs sont définis sous la forme "Prenom Nom".
Il est également possible de modifier le code source pour que cette correspondance se réalise, selon le contexte de l'établissement cible. |
Ce point est crucial pour que le système fonctionne correctement : une correspondance doit exister sur le "Prenom Nom" des modérateurs de BigBlueButton et le "Prenom Nom" des utilisateurs 
A priori, cela devrait pouvoir fonctionner avec Greenlight si celui-ci est configuré pour utiliser l'annuaire LDAP de l'établissement et les champs givenName et snÉtape 4 : publication des vidéos
...