Outils pour utilisateurs

Outils du site


local:moodlescript:developerapplicationexample

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

local:moodlescript:developerapplicationexample [2019/03/26 16:24]
admin [Réalisation à l'ancienne]
local:moodlescript:developerapplicationexample [2024/04/04 15:52]
Ligne 1: Ligne 1:
-===== Cas d'​usage : Scripter les opérations d'​arrivée d'un cours à partir d'une livraison externe ===== 
  
-==== Scénario ==== 
- 
-Il s'agit ici d'un scénario d'​intégration dans lequel un composant (block_publishflow) transportant des cours entre plusieurs plates-formes Moodle a besoin d'​effectuer un certain nombre d'​opérations "​post-transport"​ pour recaler certains paramètres et dispositifs du cours à son nouvel environnement. Le scénario ci-dessous décirt le besoin d'​opération suite à la mutualisation d'un cours à partir d'une plate-forme A dans un moodle collecteur de mutualisation B. 
- 
-Parmi les opérations à réaliser :  
- 
-   * Nommer l'​utilisateur actif comme "​déployeur"​ (rôle personnalisé) de ce cours 
-   * Supprimer un bloc (course_recycle) 
-   * Déplacer le cours dans une catégorie propre de l'​utilisateur qui est à l'​origine de l'​émission du cours. Crer cette catégorie si elle n'​existe pas. 
-   * ajouter un méthode [[:​enrol:​profilefield|d'​inscription par "​profil utilisateur"​]] au cours pour accepter les collègues enseignants dans le cours. 
-   * enfin, réaliser une sauvegarde du cours dans le contexte de la publication de cous pour que les collègues puissent déployer. 
- 
-Note : Ce scénario est en application sur les plates-formes moodle académiques du Rectorat de Rennes et de la plate-forme Atrium Paca. 
- 
-==== Réalisation à l'​ancienne ==== 
- 
-En l'​absence de MoodleScript,​ l'​ensemble de ce scénario devrait être codé en PHP avec un appel à des API complexes de gestion de fichiers Moodle, les API de role, l'API de catégorie de cours. les API d'​inscriptions plus du code spécifique pour le traitement des blocs. 
- 
-L'​estimation de ce développement est de plus de 800 lignes de code. 
- 
-==== Implementation en Moodlescript ==== 
- 
-La séquence Moodlescript écrite pour effectuer le postprocessing du cours après restauration est :  
- 
-   ENROL current IN current AS editingteacher USING manual 
-    
-   ​ASSIGN ROLE deployer TO current IN current 
-    
-   ​REMOVE BLOCK course_recycle FROM current 
-    
-   ADD ENROL METHOD profilefield TO current HAVING 
-   ​profilefield:​ profile_field_enseignant 
-   ​profilevalue:​ 1 
-   role: deployer 
-    
-   ADD CATEGORY PATH ":​userhostname/:​userfullname"​ IN idnumber:​ARRIVALS IF NOT EXISTS HAVING 
-   ​idnumber:​ ":​userwwwroot_:​username"​ 
-    
-   MOVE COURSE current TO runtime:​idnumber:":​userwwwroot_:​username"​ 
-    
-   ​BACKUP COURSE current FOR publishflow 
-    
-Compte tenu des implicites de contexte courant suivants :  
- 
-   * L'​utilisateur courant est celui qui est en train d'​effectuer le transfert reconnu par son $USER courant dans la plate-forme d'​arrivée du cours. 
-   * Le cours courant est le cours qui vient d'​être déployé. 
- 
-Le script est invoqué dans une instance de moteur de script par le composant block_publishflow qui en a pris le contrôle. Dans ce contexte le bloc publishflow injecte dans la machine de script les contextes ad hoc suivants :  
- 
-   * :​userwwwroot : l'​identité de la plateforme d'​origine de l'​utilisateur émetteur du cours (URL). 
-   * :username : l'​identifiant de connexion (login) de cet utilisateur 
-   * :​userhostname : Le nom "en clair" de la plate-forme d'​origine de l'​utilisateur 
-   * :​userfullname : Le nom "en clair" de l'​utilisateur qui mutualise le cours. 
- 
- 
- 
-[[:​local:​moodlescript|Revenir à l'​index du composant]] 
local/moodlescript/developerapplicationexample.txt · Dernière modification: 2024/04/04 15:52 (modification externe)