Règles d'affectation des imprimantes au lancement d'un état
Introduction
Lors du lancement d'un état, une valeur par défaut peut être proposée de façon automatique en fonction du contexte pour indiquer la destination de l'édition (imprimante, fichier, messagel…). Cette valeur par défaut peut provenir de l'utilisateur, de l'état, du site… avec un ensemble de règles de priorité sophistiquées. Ce document décrit les règles et les priorités d'affectation des imprimantes en fonction du contexte.
Pré-requis
Différents paramètres peuvent être décrits pour gérer les affectations d'imprimantes :
La table des destinations permet de définir les imprimantes disponibles pour les utilisateurs, ainsi que le type de sortie associé. Notons que le type de sortie est le menu local numéro 22, qui est paramétrable.
Le paramétrage des utilisateurs qui permet de définir une table des destinations par défaut et par type, soit directement, soit en faisant référence à un autre utilisateur.
Le dictionnaire des états définit les états avec une destination par défaut, un type de sortie qui servira de filtre (sauf s'il s'agit de la première valeur qui est passe-partout), et une formule permettant d'exprimer la valeur du complément décrit ci-dessous.
La table des destinations par utilisateur, qui définit les règles les plus fines d'affectation de destination (par triplet utilisateur, complément, état).
Règles d'affectation détaillées
Une première remarque est à faire. Avant toute affectation de destination, deux cas particuliers permettent de définir une imprimante de façon particulière :
Le point d'entrée DEFIMP est utilisé par un développement spécifique, le code appelé peut imposer une destination à partir de règles particulières. Ce point d'entrée, prioritaire, est appelé en fin d'algorithme (on sait donc quelle imprimante aurait été choisie par défaut en appliquant toutes les autres règles).
Le programme appelant (si l'impression est appelée directement par un traitement) peut aussi imposer la destination.
Si l'on excepte ces deux cas particuliers, les règles d'affectation sont définies ci-dessous. L'algorithme commence par déterminer les trois valeurs suivantes :
Dans le dictionnaire des états, un Type de sortie est défini. L'algorithme de détermination ci-dessous ne va chercher qu'une destination du type correspondant si le type demandé dans l'état n'est pas le premier de la liste (autrement dit, si la destination trouvée n'a pas le bon type, la recherche continue). Il faut bien entendu également que la destination soit active, et que l'utilisateur ait le droit de l'utiliser - c'est l'accès en exécution sur le code accès associé à la destination le cas échéant. Si la destination n'est pas dans ce cas, la recherche continuera.
Si la zone Formule complément est renseignée dans le dictionnaire des états, on évalue le résultat de la formule, qui est appelé complément. Le complément peut par exemple être un code de site, si l'état lancé se lance pour les données d'un site. Ainsi, la destination utilisée pourra dépendre du site concerné par l'édition. Si la zone Formule complément n'est pas renseignée, on considère que la valeur complément est vide. Dans la formule de calcul utilisée, on peut mettre : des constantes, des fonctions, la valeur d'un paramètre de l'état par la syntaxe PARAM(NOMPARAM), où NOMPARAM est le code du paramètre tel qu'il est défini dans le dictionnaire de l'état, des variables dont on sait qu'elles sont renseignées dans le contexte - par exemple le site par défaut d'un utilisateur pour un module donné, qui peut être trouvé dans le tableau GFCYDEF...
Enfin, dans la suite, on utilise comme paramètre de détermination le code de l'utilisateur connecté, sauf si, dans sa fiche, il existe un autre code utilisateur dans la zone Destinations utilisateur (ce pour permettre de définir qu'un utilisateur a les mêmes règles d'affectation qu'un autre utilisateur modèle). Il peut y avoir des indirections successives sur le code utilisateur, mais en cas de bouclage dans la liste, on prend comme code l'utilisateur de départ.
Les trois valeurs (type de sortie recherchée, valeur du code complément, code utilisateur) étant déterminées, la règle de détermination est alors la suivante :
On se réfère à la table des destinations par utilisateur. S'il existe une ligne dans cette table pour l'état courant, le code utilisateur concerné, et la valeur de complément calculée précédemment, c'est la destination définie sur la ligne qui va être utilisée.
Si aucune valeur n'est trouvée pour le triplet, et si la valeur du complément évaluée n'était pas vide, on se réfère tout de même à cette même table en recherchant une ligne avec le code utilisateur et le code état idoines, et avec la zone complément vide (si la zone complément était vide, on aurait déjà réalisé la recherche à l'étape précédente.). Si une ligne existe, on prend la destination correspondante.
A défaut, on prend la destination définie dans la fiche de l'état (si elle existe).
Si la destination n'est toujours pas trouvée, on prend la destination du bon type définie sur la fiche utilisateur (si elle existe)
Si la destination n'est toujours pas trouvée, on recherche la destination du bon type associée au site par défaut de l'utilisateur (paramètres PRT1, PRT2, PRT3, PRT4). Le site par défaut de l'utilisateur dépend à la fois de son profil fonction, et du module auquel l'état appartient. Cette recherche se fait bien entendu en utilisant les règles habituelles de hiérarchie site/société/dossier pour les valeurs de paramètres.
A défaut, si un lancement en batch est fait, on choisit la première destination du bon type. Si on est en édition directe depuis un poste de travail, la première destination de type Prévisualisation sera proposée.
Si la destination a été définie dans la table des destination par utilisateur ou dans le dictionnaire des états, une case Obligatoire lui est associée. Si elle n'est pas cochée, la destination ainsi déterminée n'est pas obligatoire, et l'utilisateur peut donc changer de destination ou redéfinir celle-ci en choisissant destination/serveur/nom d'imprimante/caractéristiques. Une destination déterminée à partir des autres règles n'est jamais considérée comme obligatoire.