Version 10.9

Cette version apporte quatre grandes évolutions :

• l’exécution de toutes les règles SQL et des règles planifiées à travers les processus et le déplacement de la gestion des autres règles vers les tables concernées

• Le regroupement des imports/exports et plugins planifiés dans les processus

• la refonte des écrans de paramétrage des états et l’intégration des fonctions recherche dans ces écrans.

• la possibilité de modifier la couleur des lignes paires des listes et sous-listes à travers les thèmes

Pour aboutir à cela,

• des processus ont été créés pour chaque élément en respectant les principes de migration détaillés ci-après,
• un nouveau type de déclencheur a été créé
• les boutons d’accès aux automatisations sur les listes des règles, imports/exports et plugins ont été supprimés
• une liste nommée ‘Autres règles’ a été ajoutée sur chaque table pour gérer les règles de calcul, lecture seule etc….

Les règles #

Le transfert vers les tables #

La sélection d’une table dans la structure de la base (via Ecrans et structure/Structure du menu de paramétrage) permet la gestion des types de règles suivants :

.

La liste des règles déjà existante en 10.8 s’affiche ainsi :

Seul l’endroit à partir duquel elles sont gérables est impacté par cette migration. Aucune modification n’a été faite dans leur paramétrage ou leur exécution.

Les règles SQL #

Voici la liste des types de règles migrées vers les processus.

Note : Le type de règle ‘Règle SQL affectée à un champ’ n’apparait pas dans cette liste car il reste en création et exécution indépendamment des processus.

Principes de migration appliqués #

Un processus est créé pour chaque table avec un ou plusieurs déclencheurs selon le type de règle.

Lorsque plusieurs règles de même type existaient pour une même table, elles ont été regroupées dans le même processus en respectant leur ordre alphabétique, afin qu’elles s’exécutent dans le même ordre qu’avant la migration.

C’est pour cette raison que le nom donné aux processus pour ces règles est constitué des éléments suivants : ‘migration_NomDeLaTable_TypeDeRegle’. Le tout est précédé de deux espaces afin qu’ils s’exécutent avant les processus déjà existants avec les mêmes déclencheurs.

Chaque processus a été créé avec le déclencheur de même type que la règle dont il est issu.

Deux exceptions :

• Règle SQL sur création de fiche => Ouverture en création de fiche

  il s’agit d’un nouveau déclencheur qui exécute les traitements à l’ouverture de la fiche suite au clic sur le bouton Ajouter d’une liste ou d’une sous-liste

• Règle SQL sur validation de fiche => création de deux déclencheurs (Validation de création de fiches et Validation de fiche) dans le processus généré afin que la règle soit exécutée lors de la validation d’une fiche qui vient d’être créée comme lors de sa modification, comme c’était le cas avec les règles de ce type.

Notes :

• Jusqu’à la 10.8, les règles SQL s’exécutaient avant les processus. Pour que ce soit toujours le cas, le nom des processus créés pour les règles SQL est précédé de deux espaces et les processus s’exécutent dorénavant dans l’ordre alphabétique, ce qui était précédemment le cas pour les règles mais pas pour les processus.

• Les règles SQL peuvent toujours être créées à partir de la liste des règles accessible via l’onglet ‘Traitements’, présent au même niveau que ‘Processus’. En revanche, elle ne peuvent plus être activées.

Les règles automatiques #

• Pour chaque règle automatique active création des éléments suivants

  • une règle SQL générique avec son nom d’origine,

  • un processus de type ‘Général’ avec

    • un traitement actif de type ‘Règle SQL’ avec la règle créée
    • un déclencheur actif de type ‘Planification’ avec la même périodicité que l’automatisation initiale

    Le processus créé est nommé suivant cette nomenclature : ‘migration_regleauto_NomDeLaRegleAutoMigrée’

  A titre d’exemple voici une règle automatisée active en v10.8 :

  

  Voici le processus qui a été créé en v10.9 :

  

• Pour chaque règle automatique inactive création uniquement d’une règle SQL générique avec son nom d’origine

Les automatisations des imports, exports et plugins #

La seule modification visible sur les listes des imports et exports est l’absence du bouton qui permettait de gérer leurss automatisations. Il est donc toujours possible de créer des modèles et d’exécuter des imports et des exports manuels à partir de la liste des imports/exports.

Concernant les plugins, seul le bouton d’accès aux automatisations a été supprimé.

Leur automatisation se fait dorénavant uniquement à partir des processus. Il est également possible de créer et modifier des modèles à travers les processus.

Principes de migration appliqués #

• pour chaque automatisation active création des éléments suivants :

  • un processus de type ‘Général’ avec
    • un traitement actif de type ‘Import’, ‘Export’ ou ‘Plugin’ selon le type d’automatisation initiale
    • un déclencheur actif de type ‘Planification’ avec la même périodicité que l’automatisation initiale

• pour chaque automatisation inactive non liée à un processus création des éléments suivants :

  • un processus de type ‘Général’ avec
    • un traitement actif de type ‘Import’, ‘Export’ ou ‘Plugin’ selon le type d’automatisation initiale
    • un déclencheur inactif de type ‘Planification’ avec la même périodicité que l’automatisation initiale

• pour chaque automatisation inactive liée à au moins un processus on ne crée rien

Pour les imports et les exports automatiques, le processus créé est nommé suivant cette nomenclature : ‘Migration ie automatique NomDeLiEAutoMigré’.

Pour les plugins automatiques, deux cas de figures :

• pour ceux exécutés via un bouton, un processus a été créé reprenant la traduction du bouton placé dans le design

• pour les autres le processus créé a été nommé ainsi ‘Migration plugin automatisé NomDuPluginAutoMigré’.

Les nouveautés dans les processus #

Dans les traitements #

Il est dorénavant possible de créer directement une règle, un plugin ou un modèle d’import/export à partir d’un processus via un traitement du type correspondant.

Lors du clic sur un traitement avec ou sans restriction fiche un crayon et un + apparaissent à droite de la règle, du plugin, de l’import ou de l’export sélectionné afin de modifier celui sélectionné ou d’en créer un.

Seul l’écran de paramétrage des traitements de type Import ou Export a des informations complémentaires.

Traitement de type import :

Traitement de type export :

Toutes les informations sont présentes dans le traitment, hormis celles qui concernent la planification, visibles dans le déclencheur.

Dans les déclencheurs #

Création d’un nouveau déclencheur nommé ‘Ouverture en création de fiche’. Il permet d’exécuter les traitements lors de la création d’une fiche, dès son ouverture, comme c’était le cas pour les règles à création de fiche.

IMPORTANT : Le nom des processus est pris en compte pour définir leur ordre d’exécution dans deux cas :

• processus ‘Fiche’ sur une même table avec même déclencheur
• processus ‘Général’ avec même déclencheur sans notion de périodicité donc de type ‘A l’arrêt du serveur’ ou ‘Au Démarrage du serveur’

L’exécution se fait alors dans l’ordre alphabétique croissant de leur nom.

Les états d’impression #

Le seul changement notable dans le paramétrage des différents types d’états d’impression, hormis l’utilisation d’objets d’affichage et de sélection plus modernes, réside dans la possibilité d’associer des recherches à chaque état, créant ainsi ce qu’on appelait jusqu’en 10.8 ‘Fonction recherche’.

Voici un exemple d’écran de paramétrage d’un état d’impression :

Pour gérer les recherches associées, cliquer sur l’onglet portant le même nom. L’écran suivant s’affiche ainsi.

De la même façon que sur toutes les listes, cliquer sur une ligne ouvre la fiche, cliquer sur le bouton + permet d’en ajouter une.

L’écran de paramétrage se présente ainsi

Il est possible à partir de cet écran de sélectionner une recherche déjà existante, de la modifier si nécessaire ou d’en créer une.

Ce paramétrage met à disposition un bouton, insérable dans un design, qui permet d’exécuter l’état basé sur la recherche sélectionnée.

Note : Le bouton ‘Fonction-recherche’ a été supprimé du sous-menu ‘Etats et indicateurs’ du menu de paramétrage.

Couleur de fond des lignes paires #

Dans la définition d’un thème, le paramètre ‘Couleur de fond des lignes paires dans les listes’ a été ajouté.

Il a par défaut la valeur #fbfbfb, code de la couleur fixée jusqu’à maintenant pour le fond des lignes paires des listes et sous-listes.

Pour modifier cette valeur, aller dans le paramétrage, cliquer dans le menu sur ‘Ecrans et structure/Structure’, déployer ‘Thèmes/Thème application’ et sélectionner le thème à modifier. Affecter la valeur souhaitée en saisissant son code ou en sélectionnant la couleur via la palette associée puis cliquer sur [Sauvegarder].

Pour voir le résultat, raffraichir la page.

Note : Dans le cas où une couleur est définie sur une table, par la sélection d’un champ de type couleur, c’est ce paramètre qui est prioritaire sur celle définie sur le thème, c’est à dire qu’une ligne paire sera de la couleur définie sur le thème uniquement si elle n’a pas de couleur affectée dans le champ sélectionné sur la table concernée.