Importer des essais

Reprendre dans cette archive un fichier .glab enregistré sur une autre installation, comme entrée indépendante et entièrement traçable : ce qui est validé, ce que la copie reçoit, et ce qu'elle ne reçoit jamais.

Le contrôle Importer se trouve dans l'en-tête de la liste des essais, à côté d'Actualiser, et accepte un fichier .glab enregistré sur une autre installation (Exporter un essai). Le contrôle n'est dessiné que pour un rôle qui a la permission Exporter/importer les historiques ; tout autre rôle voit l'en-tête de la liste sans lui. Il exige une station qui accepte les écritures (« La station est en lecture seule. »), parce qu'il publie un fichier d'essai et une ligne d'index, et il est grisé pendant qu'un autre verbe de la bande est en cours (« La commande précédente est encore en cours. »).

Ce qui est validé

Le fichier est transféré vers une copie temporaire (les envois sont plafonnés à 1 GB ; le journal indique « Import · fichier… ») et validé là d'abord. Un refus ne crée aucune entrée :

Le reçu et la copie publiée

Un fichier issu d'une ancienne base prise en charge est mis à niveau sur la seule copie temporaire ; le fichier reçu n'est jamais touché. La copie reçoit alors son reçu d'import, l'instant de l'import et le nom du fichier reçu, gravés en elle, de sorte que le dossier puisse toujours dire d'où vient l'essai et qu'un index reconstruit rétablisse la marque Importé ; une copie réexportée depuis une autre station portait le reçu de cette station, et la provenance de cette copie-ci est son arrivée ici. La station publie une nouvelle copie locale sous un nom unique (Imported_<run name>_<id>.db) et enregistre une entrée nouvelle et indépendante ; le journal indique « Importé · nom · depuis fichier (taille) » et la liste s'ouvre dessus.

Ce que la copie reçoit, et ne reçoit jamais

• L'essai importé reçoit une identité locale toute neuve ; l'identifiant d'essai d'origine reste dans le fichier comme preuve, donc deux installations peuvent échanger des essais sans collision.
• Il n'est jamais relié à la configuration locale, même quand une procédure du même nom existe : il n'appartient à aucune unité, sa procédure est nulle, il ne peut pas être repris, il ne compte jamais dans la productivité locale, il ne configure aucune étiquette pour Nouvelle étiquette, et « (rapport de la procédure) » le rend avec la mise en page par défaut à toutes les sections.
• Son état est l'état final figé dans le fichier : un essai auquel un verrouillage a mis fin s'importe comme Interrompu, et un état figé qui n'est pas final est ramené à Terminé. Un fichier qui n'a jamais écrit son instantané (la station source est morte en cours d'essai) s'importe comme un essai En échec nommé d'après le fichier, pour qu'il ne soit pas perdu.
• Rien n'est écrasé ni fusionné : importer deux fois le même fichier donne deux entrées indépendantes.
• Le responsable voyage avec la copie comme preuve figée. Sur une station qui partage la même liste d'utilisateurs, l'identité figée continue de désigner le même opérateur ; ailleurs, elle nomme la personne sans correspondre à aucun utilisateur local.

Utiliser l'essai importé

Une fois importé, l'essai se consulte, se commente, s'annote et se réexporte comme n'importe quel autre, et ses artefacts d'étiquette et ses enregistrements de rapport viennent avec lui : les octets figés d'un artefact peuvent être réimprimés ici, tandis que le PDF publié d'un enregistrement n'est pas sur cette station, donc il ne peut être ouvert ou renvoyé que si la station source en a gardé une copie dans l'essai ; sinon, générez un nouveau PDF à partir du fichier.

Si l'application s'arrête en plein import

Si l'application s'arrête dans l'étroite fenêtre entre la publication du fichier et son enregistrement, le fichier n'est pas perdu : Reconstruire l'index de l'historique des essais dans Paramètres réexamine les fichiers d'essai, qui font foi, et lui rend son entrée.