J'ai été obligé de fermer, pour cette fin d'année, toute une liste de cours (139 au total) dans une sous-catégorie de mon Moodle. Pour ce faire, j'ai attaqué la base principale à coup de
Qu'en pensez-vous ?
Voici déjà la mienne (livrée sans garanties) :
| UPDATE moodle.mdl_course SET `visible`=0 WHERE moodle.mdl_course.category IN (SELECT `id` FROM moodle.mdl_course_categories WHERE moodle.mdl_course_categories.path LIKE "chemin%"); |
Petite explication de texte pour ceux qui voudraient bien comprendre la démarche :
Petit rappel, les cours sont rangés dans des sous-catégories, elles même rangées dans des catégories... Nous allons devoir taper dans 2 tables (mdl_course et mdl_course_categories) pour obtenir satisfaction. Dans ma requête, ma base s'appelle moodle !
La condition WHERE moodle.mdl_course_categories.path LIKE "chemin%" filtre les id des sous-catégorie de cours (et ses descendants) dont le chemin correspond à notre critère de sélection.
Ce chemin, justement, s'écrit de la façon suivante : "/x/y/z" où x est l'id de la catégorie principale, y l'id de la sous-catégorie et z, l'id de la sous-sous-catégorie... On va s'arrêter là mais ça pourrait continuer longtemps.
Ex: ="/12/34" avec 34 comme id de la sous-catégorie rangée dans la catégorie n°12.
Vous imaginez bien qu'on pourrait améliorer cette requête en en imbriquant d'autre plus éloquentes. Mais je n'ai pas trop le temps... 
Vous serez donc forcer d'aller chercher dans votre Moodle quel est le chemin de votre sous-catégorie.
Le champs visible doit être basculer à 0 si on veut fermer le cours aux étudiants. Le reste de la requête me parait assez simple à traduire...
Petite remarque et gros dangers de cette requête :
Les plus attentifs auront remarqué une faiblesse dans cette requête. En effet, le critère de sélection peut engendrer des débordements puisque nous pourrions avoir le cas suivant : soit les chemins /12/34, /12/34/56 et /12/345. Si nous voulons sélectionner tous les cours de la sous-catégorie 34 et ses descendants (donc /12/34 ET /12/34/56), nous allons embarquer ceux de la catégorie 345 puisqu'elle commence par la même séquence de chiffre (à savoir un 3 suivi d'un 4). Faites donc attention !!!
Je laisse le soin aux spécialistes du MySQL d'améliorer cet embryon et j'espère qu'elle pourra servir à d'autres. Je ne suis pas persuadé d'avoir été très explicite mais c'est déjà un premier pas 
Je suis preneur d'autres requêtes du même genre que vous auriez développées pour votre usage !
A bientôt,
