2019-03-27 : Axiell Collections version 1.5

Nous en sommes maintenant à la cinquième mise à jour d'Axiell Collections 1, qui intègre comme vous pourrez le constater de nouvelles fonctionnalités et la résolution de certains bugs, mais ce qui caractérise le plus cette version 1.5, axée sur la "performance", c'est qu'elle améliore globalement la vitesse d'exécution du logiciel, facilitant le déplacement à l'intérieur de grands volumes de notices, l'affichage de hiérarchies conséquentes et la navigation dans les arborescences.

2019-03-27 : résolutions de bugs significatives depuis 2019-02-26

Brève description du problème

Le numéro de notice ne pouvait pas être imprimé par l'intermédiaire d'un modèle Word.

Les messages d'erreur générés pendant la modification d'une notice ne s'affichaient pas.

Au cours d'une Création à la volée de notice, l'enregistrement n'était pas possible si un champ comportant une numérotation automatique et considéré comme obligatoire était vide, alors que c'est quelque chose de tout à fait possible quand on crée une seule notice. Dans un contexte de Création à la volée, comme les champs de ce type sont désormais en lecture seule, cela ne fait plus obstacle à l'enregistrement des notices, ce qui rend la Création à la volée à nouveau pleinement opérationnelle.

La création de nom pour une nouvelle localisation pendant un Changement de localisation ne fonctionnait pas.

Re-lancer une recherche sauvegardée en cas de champs non indexés donnait pour résultat l'ensemble des notices de la base de données.

Il était possible d'ajouter des notices à des sources de données qui devaient en principe exclure en principe la méthode Créer un nouvel enregistrement.

Les changements apportés en Mode modification dans la Liste résultat n'étaient pas conservés une fois le Mode modification quitté.

La fonction OPENFILE dans le langage ADAPL n'était opérationnelle que si l'interface d'Axiell Collections était en anglais ou si un fichier texte se rapportant à la langue employée était présent.

La fonction RECCOPY dans le langage ADAPL copiait le terme faisant partie du champ lié au lieu de copier la référence au lien même si le champ lié avait la même base de données pour source et pour cible.

Lorsqu'un terme était forcé dans un champ lié en interne, il n'était pas enregistré.

Quand le point était employé comme séparateur décimal, il ne s'affichait ni avec Google Chrome ni avec Microsoft IE11.

Un paramétrage de l'IIIF vidait le Lecteur média de tout contenu.

Les champs HTML ne s'affichaient pas correctement quand ils faisaient partie d'un groupe répétable.

De nouvelles valeurs pouvaient être attribuées à des champs liés de l'écran de Changement de localisation sans être forcées.

Le nom de lieu saisi dans un champ de géolocalisation n'était pas repris dans la zone de recherche de la fenêtre de lien.

La carte de l'onglet Carte géographique dans la fenêtre de lien pour le champ production.place ne changeait pas d'aspect après la saisie d'un nom de lieu.

Quand on ouvrait une notice avec un champ de géolocalisation relié à plusieurs lieux, le champ ayant déjà été sélectionné dans la Carte géographique, le zoom effectué sur la carte visait sur un emplacement situé entre les différents endroits concernés, alors qu'un zoom arrière permettant de voir tous les emplacements aurait été préférable.

La mise à jour de liens ne se répercutait pas comme il se doit dans la base de données rattachée.

Le mécanisme de rétroaction ne fonctionnait pas correctement au moment où un terme préféré devenait terme non préféré.

La variable système ADAPL &1[3], pour une notice enregistrée "manuellement", était 0 au lieu de 1.

Message d'erreur la valeur ne peut pas être "null". Nom de paramètre : "key" à l'enregistrement d'une notice après avoir supprimé une occurrence de champ lié en interne.

Un champ en HTML ne s'affichait pas correctement dans un écran zoom.

La variable système ADAPL &1 retournait toujours la valeur 1. Elle aurait dû retourner la valeur 4 en Mode modification.

Un adapl avant-écran ne s'exécutait pas si la notice était en Mode modification.

Dans les Détails d'enregistrement, le Mode Filtre Has data ne fonctionnait pas comme prévu.

Le texte et les références de champ figurant dans l'en-tête d'un modèle Word ne pouvait plus être imprimés.

Les droits d'accès en lecture seule sur une base de données liée s'étaient reportés sur d'autres bases de données liées avec celle-ci.

Au moment de sélectionner un terme dans la fenêtre Recherche des termes pour le champ, quand l'option Afficher seulement <domaine> est désélectionnée, Axiell Collections demandait si on voulait l'ajouter au domaine du champ lié, quand bien même ce domaine était déjà celui auquel le terme appartenait.

La fenêtre de lien s'ouvrant au sein de l'écran de Changement de localisation pouvait ne pas être en rapport avec la langue de l'interface.

2019-03-08 : prise en charge du format d'impression XSLT+adapl

Depuis la version 1.5, Axiell Collections est désormais à même de prendre en charge des formats d'impression qui combinent adapl et feuille de style XSLT. Dans la liste des Formats d'impression, il n'est pas possible de donner à voir visuellement quelles sont les technologies employées par les différents formats d'impression proposés. La différence n'apparaissait qu'une fois le format d'impression mis en oeuvre : si le format était basé sur une feuille de style, il apparaissait sous forme de pages HTML, que l'on pouvait consulter à l'aide d'un navigateur web, puis enregistrer ou imprimer,tandis que, si le format était basé sur un modèle Word, il apparaissait sous forme de fichier Word.

ACxsltPrinting

Chaque technologie a ses avantages et ses inconvénients, il appartient à l'administrateur du système de déterminer quelle est la technologie la plus judicieuse dans une situation donnée. La conception de feuilles de style XSLT (avec adapl ou sans adapl) est un travail de programmeur. Se reporter aux Rubriques d'aide pour Axiell Designer pour en savoir plus sur la configuration de format d'impression dans ce contexte.