Valery Fremaux

• assessment.php : for assessments
• criteria.php : for editing evaluation criteria sets
• by<something> : to display views of data "by" (essentially tasks)
• copy.php : for item copy features
• cvs.php : for future CVS external drive
• deliverables.php : for handling deliverable tree
• description.php : for editing descriptions
• detail.php : for the detailed view (object browser)
• ...

and so on.

Note that all these may use rendering functions in locallib.php for rendering a single entity or a full entity tree. Most of these functions are recursive, so handling easily tree-shaped structures.

• version.php
• backuplib.php
• restorelib.php
• mod.html

are standard.  

T'affoles pas Jérome , j'ai anticipé mais n'ai pas eu le temps de publier. (un peu charette en ce moment). Je posterai ce soir une version nettement plus stable avec une détection de collision plus serrée. Je pensais m'en sortir vaguement en comptant sur le code original, mais l'intervention de limites numériques et les améliorations de gestion ont fait exploser les cas à vérifier.

J'ai également ajouté la possibilité de révoquer un rendez-vous (faut que j'ajoute un envoi de notification mail). J'ai commencé une vraie série de tests. Ce module peut être vraiment TRES utile s'il marche bien et s'il est très peaufiné au niveau ergonomie.

A ce soir...  

PS : continuez quand-même à me rapporter les défauts. Je ne peux pas tout voir et ces allers-retours, même s'ils peuvent vous paraître lourds, sont néanmoins une méthode extrêmement rapide et efficace pour obtenir un résultat dans des délais optimaux. (partage des tâches + réactivité = succès rapide). 

Non, la réaction n'est pas normale, du moins pas celle que j'attends. Si un admin crée des créneaux pour le compte d'un prof, ces créneaux appartiennent désormais au prof en question. Lui seul peut les supprimer de façon sélective, l'admin pouvant toujours supprimer l'ensemble des créneaux pour tout le monde.  

Je vérifie ce "circuit".

N'hésitez pas, comme tu le fais, nicolas, à tester et vous poser toutes les questions possibles sur ce qu'il se passe. Ce module mélange du nouveau code à de l'ancien code et toutes les subtilités des cas possibles ne me sont pas encore connues. Nous mettrons quelques semaines à en maîtriser les possibilités de fonctionnement (et les limites aussi). Je peux aussi moi-même me planter sur certains cas d'usage.

La preuve :

view.php §558

Changer le code du cas 'deleteonlymine' :

            if ($slots = get_records_select('scheduler_slots', "scheduler = {$cm->instance} AND teacher = {$USER->id}")){
                foreach($slots as $aSlot){
                    scheduler_delete_calendar_events($aSlot);
                }
            }           
            delete_records('scheduler_slots', 'scheduler', $cm->instance, 'teacher', $USER->id);
            break;

(Erreur d'utilisation de get_records)

Thanks TIm,

is there any relationship (sure there is !!) with the moodle/legacy:student and related legacy capabilities, i.e, is it a good practice to map additional roles to that legacy position in the system only assigning to 'em the adequate legacy capability ?

As a consequence, do deprecated calls get_course_student() and related know about that ?  

J'ai corrigé dans ma version.

filesystemlib.php est nécessaire pour effectuer les manoeuvres du système de fichier à "haut niveau". Il préfigure une future API de Martin qui virtualisera complètement le système de fichiers. (Nous pourrons avoir ces fichiers n'importe-où, y compris dans une base de données, ou sur un autre serveur, sous n'importe quel OS, etc.).

Pour supprimer les traces du module précédent (essentiellement des répertoires flashcard sous moddata, puisque le module ne génère pas d'événements), il suffit donc de détruire tous les répertoires moddata/flashcard dans les répeertoires numérotés de moodledata (répertoires de cours).

Je vais checker pour ma part l'état du module à l'international, pour proposer cette mise à jour.