Logbook — sauvegarde, historique et évaluation

RôleStructure dudes logbookdonnées

Le logbook est lestocké journalpar équipe dans teamsLogbooks, avec teamUid comme UID du document. Chaque activité possède deux rubriques : student et teacher. Chaque rubrique contient une entrée courante par yearId et un historique de bordversions.

logbook[actUid][role][yearId] = { text, date }
logbookHistory[actUid][role][yearId] = [{ text, date }, ...]

Côté Unity, Logbook.logbookRoles indexe les activités et les rôles. LogbookRole.entries contient les entrées courantes; historyEntries contient les listes de l'équipe.versions. SonLogEntry systèmeporte comprendle la sauvegarde des entrées, la synchronisation entre clients, la restauration d'historiquetexte et l'évaluation. Ces responsabilités justifient une pagedate dédiéeen dansmillisecondes Commun.depuis l'époque, convertie en heure locale pour l'affichage.

ModèleChargement et persistancecache

Élément Responsabilité Logbook Représentation runtime commune du journal de bord.

TeamBaseController.Logbook

Accèsexpose le modèle chargé. LoadLogbook() appelle BackEndBrainCloud.GetLogbook(), puis _command/get_logbook.js, qui retourne le document teamsLogbooks.

Le controller conserve un cache. Des demandes concurrentes de chargement sont regroupées par callbacks et _logbookIsLoading. Si le cache existe, le callback est appelé sans relire le serveur.

Édition et sauvegarde

LogbookRoleControl gère l'édition, la sauvegarde, l'annulation, le collage, Undo/Redo et la sélection d'une version. Le bouton Save applique Trim() au logbooktexte deet évite l'équipeenvoi depuissi le controller.

texte est teamsLogbooks Document serveur contenant les données persistées. save_logbook.js Point d'entrée serveur de sauvegarde. logbook_changed Message de synchronisation adresséidentique à l'équipeentrée actuelle.

L'accès étudiant à l'édition dépend du rôle : avec HasLogbookDir, le directeur du logbook est requis; sinon, en équipe, le rôle temporaire logbook_editor sert à coordonner l'édition. Il peut être repris après confirmation et auest professeur.

libéré à la sortie

Chemindu demode sauvegarde

édition.

1. Le client appelle TeamBaseController.SaveLogbookEntry() normalise actUid en asynchrone via UtilsBase.GetActUid().

Le rôle envoyé au serveur est déterminé par l'utilisateur : professeur → teacher, étudiant → student. BackEndBrainCloud.SaveLogbook() envoie teamUid, actUid, yearId, date, text et role à _command/save_logbook. Le controller normalisemet l'actUidaussi enà modejour asynchrone,son puisentrée appellelocale SaveLogbook.immédiatement. Cette mise à jour locale ne constitue pas un accusé de sauvegarde serveur. Le script serveurpersiste save_logbook.jsles écritchamps dansde teamsLogbooks., Lepuis serveur émetenvoie logbook_changed à l'équipe et au professeur pour synchroniser les clients concernés.professeur.

La donnée persistée constitue la référence à contrôler. Le message temps réel signale un changement; il ne remplace pas la vérification du document ni le chargement initial. Pour le mécanisme commun, voir RTT, messages et synchronisation.

Historique et: restauration10 versions précédentes

Lesave_logbook.js systèmecopie supportel'entrée laprécédente restaurationdans d'historique.l'historique Unesi modificationson du format des entréestexte ou du parcours de sauvegarde doit préserver la lecture et la restauration des données existantes.

Lors d'une restauration, vérifier le bon contexte d'équipe et d'activité, le contenu obtenu après rechargement, puis sa visibilitédate sur un second client. Une entrée visible localement ne suffit pas à confirmer la sauvegarde ou la restauration côté serveur.

Évaluation du logbook

L'évaluation est un flux distinctdiffère de la nouvelle entrée. La version précédente est insérée en tête. MAX_LOGBOOK_HISTORY = 10 limite la liste; la version la plus ancienne est retirée au-delà de cette limite. La première sauvegarde n'a pas d'entrée précédente à archiver.

Les piles Undo/Redo du texte.champ d'édition sont locales et distinctes de cet historique persistant.

Restauration

La liste déroulante présente un choix initial, puis les versions historiques. Sélectionner une version ouvre _utils/utils_eval.jsHistoryPreviewPopupControl; la confirmation appelle RestoreLogbookHistory() fournitavec lel'index cadrede communversion, d'évaluationaprès du logbook,normalisation de l'activité en asynchrone.

restore_logbook_history.js retire la version choisie de l'historique, place l'entrée courante en tête, puis remplace l'entrée courante par le texte et la date d'origine de la présence;version chaquerestaurée. jeuIl fournitsauvegarde ensuitele son implémentation Eval<Game> via la factory d'évaluation.

Diagnostiquer séparément une erreur de contenudocument et une erreur de note. Pour une entrée absente, commencer parémet teamsLogbookslogbook_changed.

Synchronisation entre clients

Le message contient teamUid, actUid, yearId et larole. synchronisation.Le Pourtexte unecomplet noteet incorrecte,l'historique examinersont relus depuis le flux d'évaluation et le contexte d'activité/année.

Voir Système d'évaluation commun et Évaluations, logbook, scénarios et rankings By Year.

Cycle annuel By Year

En By Year, le logbook est lié à l'activité et à l'année; son évaluation reste séparée du texte. Conserver les index d'année lorsqu'on ajoute une logique annuelle.serveur.

utils_by_year.deleteYearLogbook(TeamBaseController.OnLogbookChanged() intervientignore les autres équipes et les logbooks qui ne sont pas encore chargés. Pour un logbook chargé de la bonne équipe, il invalide le cache, appelle LoadLogbook(), puis déclenche onLogbookChanged(role). Le chargement initial reste donc nécessaire.

Évaluation distincte du texte

save_logbook_eval.js enregistre la note dans le nettoyagedocument evaluation de chaque étudiant concerné. simulation.logbookPonderationType choisit un mode annuel ou global, en équipe ou individuel. En équipe, la note est appliquée aux membres; en individuel, elle vise studentUid.

Annuel : evaluation.logbookEval[actUid][yearId]. Global : evaluation.logbookEval[actUid]. La valeur note = -1 supprime la note concernée.

getLogbookScore(), dans utils_eval.js, calcule en annuel la moyenne arrondie des notes présentes jusqu'à currentYear. Sans note, il retourne 0 si l'année est terminée, sinon -1. En global, il retourne la note stockée.

La sauvegarde des notes émet logbook_eval_changed_stub et, pour les notes annuelles, logbook_eval_by_year_changed. get_logbook_evaluation.js charge les notes annuelles d'un étudiant. Sauvegarder le texte ne sauvegarde pas sa note.

Réouverture annuelle

utils_reopen_year.js appelle deleteYearLogbook(actData, teamUid) après avoir ajusté l'état et, selon le cas, l'année courante. Le helper cible précisément yearId = actData.currentYear + 1.

Il supprime les notes de cette année pour les pondérations annuelles, puis les entrées courantes et leurs historiques pour les rôles concernés. Il sauvegarde les documents et émet les messages de changement du logbook et ded'évaluation. sesLes évaluations.notes Uneglobales réouverturene ousont unepas suppressionsupprimées d'annéepar doitce traitertraitement correctementannuel.

ces deux ensembles

Fichiers de données. Vérifier que l'opération vise l'année attendue et ne laisse pas une ancienne évaluation associée à un contenu supprimé.

Modifier le systèmeréférence

Dans

Identifier le contextemaster/game/Assets/Src : équipe, activité, mode synchrone/asynchrone et année si applicable. Adapter le modèleGame/Data/Logbook.cs, LogbookGame/Controllers/TeamBaseController.cs, Game/BackEnd/BackEndBrainCloud.cs, UI/SimByYear/LogbookRoleControl.cs.

Dans master/node.js/backend/braincloud/server_scripts : _command/get_logbook.js, save_logbook.js, restore_logbook_history.js, save_logbook_eval.js, get_logbook_evaluation.js, _utils/utils_eval.js, utils_by_year.js et le_utils/command/utils_reopen_year.js.

controller

Vérifié sidans le formatcode local le 30 septembre 2026. Les parcours décrits ont été contrôlés par lecture du code; aucune sauvegarde ou le comportement change.

Vérifier le contrat SaveLogbook, le script serveur et la persistance dans teamsLogbooks. Vérifier le traitementréouverture de logbook_changedsimulation côtéréelle équipen'a etété professeur.exécutée Contrôlerpour l'historique,cette la restauration et l'évaluation. Pour By Year, contrôler aussi la réouverture et le nettoyage annuel.

Vérification et diagnostic

Entrée perdue après reconnexion : vérifier la sauvegarde serveur, les identifiants de contexte et teamsLogbooks. Second client désynchronisé : vérifier logbook_changed, ses destinataires et le rafraîchissement côté client. Historique incorrect : vérifier les données conservées et le contexte de restauration. Note incorrecte : vérifier le flux d'évaluation séparément du texte. Anciennes données après réouverture : vérifier le nettoyage annuel et les évaluations liées.

Valider une sauvegarde, un rechargement après reconnexion, une mise à jour sur un second client, une restauration d'historique et une évaluation. En By Year, ajouter un cas de réouverture d'année.vérification.