Valery Fremaux

Votre problème se situe au niveau de l'interconnexion avec la couche AICC qui permet le transfert des scores et des points de reprise. Cette couche combinant Javascript et ActionScript reste fragile. 

Il y a malheureusement à ma connaissance peu de spécialistes "open" de cette couche d'interconnexion dans la communauté francophone qui demande un examen approfondi de l'implémentation d'AICC dans Moodle et regarder les spécifications (très détaillées) des outils auteurs que vous utilisez pour générer le flash. Peut-être pourriez vous observer des forums anglophones et le tracker.moodle.org où des considérations techniques très pointues sont abordées.

Avec toute la prudence de rigueur, il me semble que Captivate génère des sorties au format Flash en y intégrant les tests.

Moodle peut recevoir des évaluations de certains modules de formation, à partir du moment où ils respectent la norme AICC et sont empaquetés dans une capsule SCORM. Est-ce le cas ?

Si oui, on les intègre dans un Moodle en choisissant un format de cours SCORM et en téléchargeant le paquetage que Moodle demande à ce moment là.

Si tu actives un cours sur un site extérieur, c'est simplement un "play" du flash qui est exécuté dans le client. Aucune fonction spécifique de l'AICC plate-forme (je rappelle que l'AICC est un protocole -- originairement des technologies de l'aviation américaine -- qui permet l'échange d'informations de parcours et d'évaluation entre une plateforme d'enseignement à distance (LMS ou LCMS) et un "module de formation". Elle contient donc, comme toute "interface", deux faces : le côté plate-forme et le côté module) n'est présente dans l'environnement du flash (la page Web qui le publie) et donc Moodle ne peut recevoir les notes.

Pour conclure, le fonctionnement du transfert de notes vers Moodle ne peut se faire que si Moodle injecte dans la page où le module est joué les interfaces nécessaires à la récupération de ces notes.   

pour le schéma de la base de données à partir de 1.7 :

http://docs.moodle.org/en/Development:Database_Schema

Pour la conversion en PHP d'un timestamp, selon la culture moodle, on utilise la fonction userdate() comme ceci :

            setLocale(LC_TIME, substr(current_language(), 0, 2));
            $datetexte = userdate($timestamp);

La ligne supérieure permet de s'assurer que le PHP utilise les bonnes localisations et n'afficha pas la date uniquement en anglais. Il s'agit d'une fonction de PHP et non de Moodle.

La deuxième convertit le timestamp (un timestamp est un temps universel UNIX calculé à partir d'une date de référence au 1er Janvier 1970 à minuit, date avant laquelle le système d'exploitation Unix -- et donc le reste de l'univers -- n'était pas sensée exister  - on appele cette date magique "The Epoch"). La date de référence est exprimée en secondes écoulées à partir de The Epoch, ce qui constitue bien un entier, mais qui va forcément devenir de plus en plus grand (!!) d'où l'idée d'utiliser les plus grand entiers stockables de la base de données.

Je rappelle pour le fun, -- ou pas -- que le bug de l'an 2000 était dû au fait que les années étaient codées sur deux chiffres décimaux. Si le temps est codé sur 32 bits : 2^32 secondes celà représente un comptage de ... 136 ans et des brouettes. D'où un bug à prévoir en 2106. Autre inconvénient : pas d'existence de comptage avant 1970. Il existe une autre raison qui fait que le comptage d'une date Unix ne peut actuellement dépasser Septembre 2035.

Avantage certain : on peut calculer des durées par simple différence.

Pour finir, le bigint stocke des entiers jusqu'à 18.446.744.073.709.551.615 soit 584942417355 ans. De quoi voir venir.... 

Il faudrait penser également à vider la table prefix_cache_text qui contient un cache base de donnée des textes qui ont été produits par les affichages. En principe la durée de cache est courte dans la base, mais il peut y rester des choses.

D'autre part, depuis la 1.8 (et peut-être un peu avant) les fichiers de langue des modules et des blocs (pas les fitres ou d'autres composants plus exotiques) sont recherchés également dans le même répertoire que le module lui-même, en plus des répertoires centraux /lang (répertoire de distribution) ou /moodledata/lang répertoire des paquetages téléchargés. Il ne devrait pas être nécessaire de surcharger encore avec une distribution locale, si les fichiers de langue sont fournis avec le module directement dans le module. Pour gérer une vingtaine d'instances de Moodle et autant d'autres plates-formes de ce type, adopter la politique la plus simple et la plus propre est salutaire => choisir à quel endroit on déploie systématiquement et de façon "régulière" ces paquetages et éliminer tous les autres (hormis le paquetage /lang/en_utf8 qui est le paquetage "legacy" de la distribution de base). Sinon les copies se multiplient et le risque de voir certaines copies "oubliées" passer devant les autres s'accroît.

Je ne sais pas s'il ça peut marcher, mais après avoir un peu fouillé le code de la 1.5, une solution (dont je ne connais pas les conséquences exactes) pourrait être de désactiver le SEUL endroit où ce paramètre est demandé :

Pour faire propre :

en ligne §338 de lib/moodlelib.php, on ajoute le test suivant :

    if (!empty($CFG->ignoresesskey)) {
        return true;
    }

puis on ajoute la clef ignoresesskey -> 1 dans la table prefix_config.

Ceci désactive proprement la vérification explicite de la clef de session, mais ce qui pourrait potentiellement constituer un trou de sécurité...