San

Page de titre





 SOMMAIRE

Terminologies et références
Documents de référence :

Lexique :

Principe de découpage de la base Système
On découpe la base de données système en trois :


 * Description du modèle physique de données et de ses contraintes :
 * Tables/Vues SGBD
 * Colonnes
 * Sources de données
 * Relations
 * Les zones de compétence
 * Description des affichages/fonctionnalités métiers disponibles
 * Les vues applicatives : Ces vues servent à présenter la donnée, leur règle d ’ affichage et de mise à jour. Seules les tables ou ensemble de tables décrites dans les vues sont publiables.
 * Les Menus disponibles pour les modules
 * Les modules disponibles
 * Description des droits sur les modules, treeview et les fonctionnalités (cf. e-maori et compatibilité)



Pour plus de détails sur la notion d ’ entité, zone de compétence, utilisateurs, voir le chapitre Droits et profils, p.48

Le modèle physique données
Le modèle de données est définit dans les tables MTD%.

Les tables et les champs peuvent avoir des contraintes applicatives du type : Lecture seule, Lecture écriture, non publiables (cachés ne pouvant être utilisé dans une vue applicative).

Les catalogues métiers
Les vues sont définies pour toute l ’ application (Les vues ne contiennent pas de notion d ’ entité).

On ajoute une description des modules disponibles. On ajoute une description des menus disponibles par modules. Les droits porteront sur ces descriptions. Se reporter au chapitre traitant du sujet.

Descriptif des tables
Il faut penser à bien décrire les tables et les vues et leurs champs en MAJUSCULE pour la génération du mapping.

La table « gi_ts_dldex »
Description : Règles de déploiement associées aux arborescences.

La table « gi_ts_dldil »
Description : Relation/Dépendance entre les nœuds.

La table « gi_ts_dldli »
Description : Liste des arborescences.

La table « gi_ts_dldno »
Description : paramétrage d ’ une branche de treeview (à refactoriser, cf specs treeview)

La table « gi_ts_dldpc »
Description : liste des pictogrames et icones

La table « gi_ts_dvclg »
Description : Préférence affichage Grille pour chaque colonne.

Remarque : Table à l ’ usage de la grille.

La table « gi_ts_dvcol »
Description : Propriétés des colonnes pour la vue que ce soit grille ou fiche.

Ces informations sont utiles à la grille et à la fiche

Explication sur la colonne DVCOL_IDREAL :

Exemple : la table Rue

La table « Site » a 2 liens vers Arrondissement. Si on veut obtenir dans la vue applicative le nom de l ’ arrondissement 1 de la rue, le service va renvoyer 2 noms d ’ arrondissement 1 et 2. Dans la description de la vue, le champ pointé sera le champ indiquant le nom de l ’ arrondissement de la table Arrondissement. Il est alors nécessaire d ’ indiquer si c ’ est l ’ arrondissement 1 ou 2 recherché, d ’ où le champ MTDCL_IDORIGIN.

Dans le cas où la relation est directe, la recherche ne passe pas par RowRelation et le mapping distingue bien les deux informations (ex : site- > arrondissement, Rue- > arrondissement, car c ’ est un lien d ’ héritage).

''Par contre dans le cas de relation distante, l ’ application ne pourra distinguer le premier du second. Ce cas sera à prendre en compte par la suite, si un projet le demande, ce qui n ’ est pas le cas du projet de Lyon.''

La table « gi_ts_dvfic »
Description : Préférence affichage fiche.

La table « gi_ts_dvhpx »
Description : Permet d ’ attacher un pictogramme, une couleur de lignes, une couleur de fond sur la fiche, aux enregistrements vérifiant une condition.

Note : les conditions se cumulent avec celles déclarées sur les entités père.

La table « gi_ts_dview »
Description : Permet de décrire les vues applicatives.

Attention, si plusieurs vues applicatives pointent vers la meme table, les distinguer en incrémentant le champ DVIEW_NUMVIEW.

La table « gi_ts_dvlnk »
Description : Permet de mettre en relation les vues applicatives dans le cas, par exemple, des menus atteindre.

La table « gi_ts_dvmnu »
Description : Table de description des menus.

Utilisation : cf 8.3.1.

La table « gi_ts_dvmod »
Description : Table de description des modules.

Les modules reprennent la désignation du module dans l ’ application. C ’ est le couple Module/Nom du module codé qui permet de définir la licence sur le module.

La table « gi_ts_dvqry »
Description : Table de stockage des requêtes utilisateurs.

La table « gi_ts_entit »
Description : liste des entités (groupes d ’ utilisateurs disposant de droits et de préférences identiques)

La table « gi_ts_entrg »
Description : Droit pour les entités.

L ’ entité est un ensemble de droits sur les vues et les fonctionnalités directs ou hérité d ’ une autre entité.

L ’ entité est un ensemble de règles définissant une entreprise, un contrat, ou un métier.

L ’ utilisateur et l ’ entité sont intimement liés (cf. les utilisateurs)

L ’ entité zéro est réservée. Elle permet de définir les préférences par défaut dont héritent toutes les entités. Le droit par défaut sur l ’ entité 0 est invisible, il est donc nécessaire de redéfinir les droits pour voir la donnée.

La table « gi_ts_ident »
Description : Contient l ’ ensemble des identifiants utilisateurs.

Selon le mode de gestion de l ’ application (Paramètre général à l ’ application), l ’ utilisateur sera identifié à chaque connexion au site de l ’ application soit par la saisie de son login et mot de passe e.Maori soit automatiquement par la récupération de son authentification de session Windows et la recherche de la correspondance dans cette table.

De cette manière, quelque soit le mode de gestion, un service d ’ authentification permettra de retourner l ’ ID Entité.

La table « gi_ts_intrg »
Description : description des droits pour couplage cartographique.

La table décrivant les droits pour les couplages définit pour chaque couche :

- L ’ utilisateur

- L ’ entité

- La zone de compétence

- Le secteur choisi

- Droit de création

- Droit de visualisation

- Droit de Modification

La table « gi_ts_intrp »
Description : description des règles de couplage

La table de description des règles de couplage donne :

- L ’ application avec laquelle on est couplée (« GIMS », « MAPINFO », « EPCENTER »). Cette dénomination nous permettra par la suite d ’ implémenter des couplages spécifiques : règles de création particulières …

- La vue sur laquelle porte le couplage

- La couche correspondant à cette vue

- Si on doit mettre à jour la table des droits décrite si dessous

- Le cas échéant la table et les champs permettant faire l ’ équivalence entre la clé cartographique et la clé primaire GIMAO. Sinon le champ qui est utilisé dans la vue comme clé primaire.

- Les critères de filtres permettant de distribuer les enregistrements entre les différentes couches cartographiques.

La table « gi_ts_layer »
Description : liste des couches cartographiques gérées par GIMAO.

La table « gi_ts_lstit »
Description : Définition des listes de référence systèmes

La table « gi_ts_mtdca »
Description : description des zones de compétences

La table « gi_ts_mtdcc »
Description : description des contraintes par zone de compétence et par table.

La table « gi_ts_mtdcl »
Description : description physique des colonnes des tables (attributs/champs d ’ une table)

La table « gi_ts_mtddb »
Description : Description des connexions aux bases clientes

La table « gi_ts_mtdls »
Description : Définition des listes de référence

La table « gi_ts_mtdrl »
Description : Définition des relations entre les tables.

Les règles d ’ écriture :


 * Une relation est décrite entre deux tables
 * Une jointure peut s ’ effectuer sur plusieurs champs. Ils sont alors listés à l ’ aide de séparateur de type « ; ». La liste est ordonnée.
 * Dans le cas de double jointure sur une table (exemple : nœud amont, nœud aval sur un tronçon) les champs de jointure contiennent les deux champs de jointure et la table fille n ’ en contient qu ’ un (dans notre exemple : MTDCL_ IDSCHILD contiendrait les ids des champs nœuds amont, nœud aval de la table tronçon « 125 ;128 » et MTDCL_IDSPARENT contiendrait uniquement l ’ id de la table nœuds). L ’ ordre amont > aval doit être respecté.
 * Dans le cas des relations NN. Seuls les PK des tables se trouvent dans MTDCL_IDNNPARENT et MTDCL_IDSCHILD. Les MTDCL_IDNNPARENT et MTDCL_IDNNCHILD Correspondent au champ de jointure avec les PK des tables pères et filles.
 * Une table peut-être en relation avec elle-même sur un principe PKFK dans la même table
 * Une table peut-avoir avec elle-même une relation NN

Remarque :

Les Ids des tables ne sont là que pour faciliter les recherches

La table « gi_ts_mtdrt »
Description : description des types de relations métiers définissables entre tables.

La table « gi_ts_mtdtb »
Description : description physique des table

La table « gi_ts_mtdtf »
Description : famille d ’ appartenance de la table (optionnel)

Cette notion est nouvelle et peut être nécessaire au moins pour des outils administratifs (lister les tables patrimoines). Le fait d ’ indiquer la table racine d ’ une famille peut permettre d ’ accrocher des spécificités de comportement dans les modules.

Une famille «Gestion relation distante» indiquera qu ’ un lien entre 2 tables appartenant à cette famille sera géré dans la table relation si elles sont liées indirectement.

Exemple : sur epcenter Ville de Lyon, les familles de tables suivantes sont déclarées :

Les tables définies CARTO sont celles qui sont représentées sur la cartographie, un filtrage est possible sur chacune de ces tables.

La table « gi_ts_trebr »
Description : table destinée à remplacer GI_TS_DLDNO

La table « gi_tm_reglessyst »
Description : table de description des règles de systématiques

C ’ est la pocédure stockée planningWatch située dans le package systématique qui lance le recalcul des sytématiques (regrouement, déplacements…).

Présentation générale
Ce fichier est indispensable au fonctionnement de l ’ application. Il comporte notamment les sections suivantes :


 *  < configSections > : A terminer 
 * : paramétrage du premier accès à la base par la DAL, des chemins accédant aux fichiers de configuration emaori (cgi-shl) :


 * Avec :
 * [ 1 ] Le chemin du répertoire « cgi-shl » ;
 * [ 2 ] L ’ identifiant de connexion à la base de données ;
 * [ 3 ] Le mot de passe de connexion à la base de données ;
 * [ 4 ] Le nom de la base de données ;
 * [ 5 ] Le chemin d ’ accès au fichier de mapping, c ’ est-à-dire le chemin d ’ accès au fichier
 * 
 * Définit les paramêtres pour l ’ accès aux données
 *  < assembly id="100" : indiquer ici le MTDDB_ID. Dupliquer la ligne dans le cas où il y a plusieurs bases clients et indiquer les différents MTDDB_Ids
 * name="GI.GMAO.DALClient_CM" : doit être identique au nom de l ’ assembly définit dans AdminGIMAO
 * namespace="GI.GMAO.DAL.ClientDTO_CM" : doit être identique au namespace des classes DTO définit dans AdminGIMAO
 * Dans la section < system.web >, le nom de l ’ assembly doit aussi être indiqué.
 * La section permet de définir une connexion de test utilisée si l ’ attribut « active »=1.
 * : paramétrage de l ’ utilitaire de log « log4net ». Cet utilitaire présente différents « appenders « qui correspondent à des rubriques de log. On gère les appender « traceappender », « queryappender », « errorappender », « nHibernateLogger ». Pour chaque appender, l ’ emplacement du fichier de log est définit dans l ’ élément < param name="File" value="..\chemin\fichier.txt"/ >
 * < appSettings > :
 * section liste les noms, version, clefs des dll que l ’ application doit utiliser
 * La section permet de définir quel mode d ’ authentification est utilisé, on peut définir les 2 valeurs suivantes :
 * < authentication mode="Windows" > pour une authentification par le système d ’ exploitation
 * < authentication mode="Forms" > pour une authentification en mode formulaire web par cookies cryptés.
 * < authentication mode="Forms" > pour une authentification en mode formulaire web par cookies cryptés.

Paramétrage des messages d ’ exception de base de données
Le paramétrage s ’ effectue dans le « web.config » dans la balise « client ».

Une nouvelle balise nommée « exceptions » permet de paramétrer l ’ encapsulation des messages d ’ erreurs d ’ Oracle.

Chaque balise « exception » contenu dans la balise « exceptions » permet d ’ indiquer une substitution.

L ’ exemple, ci-dessous, indique que toute erreur contenant la chaîne « LYON .UTU » doit retourner à l ’ utilisateur le message « Erreur sur l ’ insertion. ».

 < client  >

…

< / mapping  >

< exception pattern=" LYON.UTU" message="Erreur sur l ’ insertion."/ >

…

< / exceptions  >

< /client >

Il est ainsi possible de gérer des contraintes d ’ intégrité référentielle en base de données et d ’ intercepter les messages d ’ erreurs renvoyés par la base pour les renvoyer à l ’ utilisateur sous une forme plus compréhensibles. Dans l ’ exemple suivant, on intercepte les pattern correspondant aux nom des contraintes d ’ intégrités définis dans oracle:

 < <font color="#800000">exception <font color="#FF0000">pattern= "<font color="#0000FF">lanterne_fk1 " <font color="#FF0000">message <font color="#0000FF">= "<font color="#0000FF">suppression de la lanterne impossible car elle est référencée par des lampes "<font color="#0000FF">/ >

< <font color="#800000">exception <font color="#FF0000">pattern= "<font color="#0000FF">console_fk1 " <font color="#FF0000">message <font color="#0000FF">= "<font color="#0000FF">suppression de la console impossible car elle est référencée par des lanternes "<font color="#0000FF">/ >

< <font color="#800000">exception <font color="#FF0000">pattern= "<font color="#0000FF">support_fk1 " <font color="#FF0000">message <font color="#0000FF">= "<font color="#0000FF">suppression du support impossible car il est référencé par des consoles "<font color="#0000FF">/ >

< <font color="#800000">exception <font color="#FF0000">pattern= "<font color="#0000FF">ptlum_fk1 " <font color="#FF0000">message <font color="#0000FF">= "<font color="#0000FF">suppression du ptlum impossible car il est référencé par des supports "<font color="#0000FF">/ >

En cas d ’ exception répondant à plusieurs critères d ’ exception pattern, c ’ est la première déclaration qui l ’ emporte et qui sera renvoyée à l ’ utilisateur.

Génération de la DLL
Menu Base système > Mapping

Onglet Liste des tables

Onglet paramètres de mapping:
 * choisir dans la liste déroulante: tables et vues décrites
 * décocher éventuellement les tables que l ’ on ne souhaite pas publier
 * les boutons permettent d ’ enregistrer / récupérer la liste des tables cochées / décochées à partir du fichier tablesMapping.xml présent dans le répertoire des ressources XML (menu Settings > Paramétrage > Onglet fichiers de travail)

Onglet action:
 * Namespace des classes DTO: indiquer un nom pour le namespace des classes DTO. Ce nom devra être repris dans le fichier web.config
 * Liste des assemblies: non utilisé
 * Entête des classes: non utilisé
 * Version de l ’ assembly: indiquer une valeur pour différencier la version ou laisser la valeur par défaut
 * Version du fichier dll généré: indiquer une valeur pour différencier la version ou laisser la valeur par défaut

La DLL générée est à recopier dans le répertoire "bin" de l ’ application.
 * Chemin des fichiers de classe à créer: indiquer un répertoire dans lequel les classes seront générées
 * Nom de l ’ assembly: indiquer le nom de la DLL à générer, sans mettre l ’ extension ".dll". Ce nom doit être repris dans le fichier web.config
 * Répertoire de destination dll: indiquer le répertoire dans lequel sera générée la dll. Il est préférable que ce répertoire soit différent de celui des classes.
 * Script de génération des vues oracle: non utilisé
 * Fichiers de clef pour signature de la dll: cocher la case signe depuis la clef interne
 * Menu Génération: après avoir choisi les tables à inclure dans la dll (onglet liste des tables), choisir Générer les classes et la dll.

Si des messages d ’ erreur apparaissent au cours de la génération de la DLL, vérifier les points suivants:


 * Chaque table et vue décrite doit avoir un et seulement un champ ayant le role de clé primaire
 * Le champ ayant le role de clé primaire doit être de type NUMBER

Styles
Les feuilles de style utilisées par l ’ ensemble de l ’ application sont stockés dans un dossier situé sous [ rep install application ] \app_themes

Il est ainsi possible de définir un groupe de style d ’ application par client en nommant ce dossier de façon unique. Le nom du groupe de style utilisé lors du déploiement est ensuite définit dans le fichier web.config par la balise suivante :

<font color="#0000FF">   < <font color="#A31515">pages <font color="#FF0000">theme= "<font color="#0000FF">VDL "<font color="#0000FF"> >

(ici : le dossier rep install application ] \app_themes\VDL sera utilisé)

Droits et profils
GIMAO est une application administrée. Chaque utilisateur est soumis à des droits.

1. Des droits sur des zones de compétences

2. Des droits sur le modèle de données

3. Des droits sur des fonctionnalités

GIMAO a des droits applicatifs notamment dans le cadre de couplage. Par droit applicatif on entant des restrictions sur les données s ’ appliquant à tout utilisateur du système.

GIMAO se doit aussi de proposer des comportements différents en fonction de typologie de données.

GIMAO permet de conserver des préférences utilisateurs.

Les entités
L ’ entité est un ensemble de droits sur les vues et les fonctionnalités directs ou hérité d ’ une autre entité (sorte de « profil »).

L ’ entité est un ensemble de règles définissant une entreprise, un contrat, ou un métier.

L ’ utilisateur et l ’ entité sont intimement liés (cf. les utilisateurs)

L ’ entité zéro est réservée. Elle permet de définir les préférences par défaut dont héritent toutes les entités. Le droit par défaut sur l ’ entité 0 est invisible, il est donc nécessaire de redéfinir les droits pour voir la donnée.

Tables de la base système :

GI_TS_ENTIT

GI_TS_ENTRG

GIMAO ne gère pas de préférence utilisateur. Il ne connait que des préférences entité. Les préférences seront gérées selon le couple module/entité.

Chaque entité hérite des préférences de l ’ entité supérieure (par défaut l ’ entité zéro). Si aucune préférence n ’ est définie pour l ’ entité, on passe en affichage par défaut.

Zones de compétences
Les zones de compétences sont définis tables à table. Chaque table ou famille de tables peuvent avoir un ou plusieurs critères.

Les zones de compétences sont indépendantes des secteurs (ou contrats) que l ’ on choisit dans l ’ application Maori. Ils viennent se sur ajouter à ces filtres utilisateurs.

Les zones de compétence sont décrites dans deux tables :

GI_TS_MTDCA (table de description des zones)

 * L ’ héritage consiste à mettre un and entre les divers critères

GI_TS_MTDCC (table de description des contraintes)

Droits sur des zones de compétence :

GIMAO doit permettre de filtrer l ’ autorisation d ’ accès aux données en fonction de critères. Ces critères peuvent-être différents pour chaque vue applicative/table.

Les droits fonctionnels peuvent-être différents en fonction des sous ensembles.



Droits sur les données
GIMAO doit permettre de définir les droits sur les données (Tables/Vues/Colonnes). Les droits peuvent-être de type Invisible, Visible, Modifiable, Créable, supprimable.

Les droits sont soumis à l ’ intégrité référentielle : si un champ est en saisie obligatoire et que l ’ utilisateur a les droits de création sur l ’ objet mais ne peut modifier ce champ la création ne peut aboutir.

On se réserve la possibilité de mettre des droits applicatifs qui prime sur le reste (Lecture seule d ’ une table, de champ, …).

Les droits sur les données sont soumis à cette hiérarchie : TABLE > Colonne table > VUE > Colonne Vue.

Ce qui est réalisé actuellement
Un utilisateur est associé à une entité et dispose des droits définis pour cette entité.

Il est possible de définir plusieurs utilisateurs par entité.

Ce qui est encore en spécification
Les utilisateurs sont définis comme ayant plusieurs couples entité/zone de compétence.

L ’ entité devient alors un profil « métier » s ’ appliquant sur une zone. Chaque couple ainsi définit devient une entité unique pour l ’ utilisateur.

En cours de session un utilisateur peut changer de couple de droits.

Ce changement s ’ effectue par sélection du couple dans une listbox.

L ’ utilisateur peut changer de mot de passe.

L ’ utilisateur peut définir le couple entité/zone de connexion par défaut.

L ’ utilisateur est définit dans la table IDENT. L ’ utilisateur est définit par un identifiant unique et un couple login/mot de passe unique.

''Les utilisateurs pourront dans un second temps être couplés aux ressources. Un utilisateur pourra être un agent.''



Si la zone de compétence n ’ est pas définit, aucun filtre n ’ est fait.

La définition des droits d ’ un utilisateur se fait donc de façon matricielle :

Administrateur Système
Le système se doit d ’ avoir un utilisateur non déclaré dans la base de données système. Cet utilisateur permet l ’ initialisation du système. Il a accès aux outils d ’ administration uniquement. Son mot de passe sera définit dans le web.config sous forme cryptée. La suppression de sa définition dans le web config le désactivera pour des raisons de sécurité sur le web.

Super Administrateur
Les supers administrateurs pourront définir tous les droits. Le droit de super administrateur est indépendant de l ’ entité. Il est décrit dans la base de données Système dans la table IDENT

Administrateur fonctionnel
L ’ administrateur fonctionnel administre les droits pour sa zone de compétence. Il peut créer de nouveaux utilisateurs, mais ne peut modifier ni les entités ni les zone de compétences sauf à les restreindre.

Des droits sur les fonctionnalités
Les fonctionnalités sont : Les Modules (Patrimoine, Maintenance, DI, planning…), les fonctionnalités disponibles dans chacun de ces modules (Menus, boutons, …).

Les droits sur les fonctionnalités sont étroitement liés aux droits sur les données. Les droits sur les données priment sur les droits sur les fonctionnalités.

Actuellement, les droits sont gérés sur les fonctionnalités suivantes :

Chaque droit est définit dans la table GI_TS_ENTRG, le champ ENTRG_TYPE contient obligatoirement le code du type de droit (un des code ci-dessus).

Les codes autorisation n ’ ont pas tous le meme effet sur chaque type de fonctionnalité comme le montre le tableau suivant :

matrice d ’ utilisation des autorisations

la notion de vue applicative
une vue applicative est un regroupement de données publiables sous forme de grille ou de fiche. Une vue applicative se rapporte à une et une seule table principale (la table maître) mais peut faire appel à des champs issues de tables en relation avec cette table maître.

Remarque : les tables maîtres ou secondaires peuvent également être des vues oracle.

La description de cette vue applicative se fait dans la table GI_TS_DVIEW, les colonnes de vue applicative sont décrites dans GI_TS_DVCOL.

Les vues Oracle portent le nom GI_VC_APTxxx où xxx est le DVIEW_ID de la vue applicative.

Génération manuelle des vues applicatives
Pré-requis:

Utilisation:
 * La génération des vues Oracle se fait via un package (source SVN: http://10.133.110.200/epcenter/GIMAO/base_system/plsql/GIMAO.pls).
 * Existence de la table ViewGenerationReport: localiser la phrase SQL de création de la table et la lancer (CREATE TABLE ViewGenerationReport…)


 * Génération manuelle d ’ une vue:
 * Dans SQL Tools, se connecter avec le compte de la base système GIMAO
 * Commande: exec gimao.p_generate_view(xxx);
 * Xxx correspond au DVIW_ID de la vue à générer
 * Effectuer un commit à la fin de l ’ exécution du package
 * Génération manuelle de toutes les vues
 * Dans SQL Tools, se connecter avec le compte de la base système GIMAO
 * Commande: exec gimao.generate_Allviews;
 * Effectuer un commit à la fin de l ’ exécution du package

publication des données de la vue par la fiche
la fiche est utilisée pour afficher un seul enregistrement d ’ une vue. Lorsque plusieurs enregistrements sont interrogés, l ’ application passe automatiquement en mode grille.

La fiche est destinée à présenter les champs de la vue dans leur exhaustivité. Cependant, les champs visibles dans la fiche sont paramétrables par entité.

La fiche permet également de saisir de l ’ information via les contrôles qui publient chaque champ de la vue (rubrique).

Sur la fiche, chaque rubrique peut être paramétrée pour chaque entité via les droits par colonne de vue pour apparaître à l ’ utilisateur sous les états suivants :


 * visible et modifiable lorsque la fiche est en mode création ou modification,
 * visible et modifiable seulement lorsque la fiche est en mode modification,
 * visible et non modifiable (rubrique grisée),
 * non visible.

publication des données de la vue par la grille
la grille est utilisée pour afficher plusieurs enregistrements d ’ une vue. Lorsqu ’ un seul enregistrement est interrogé, l ’ application passe automatiquement en mode fiche.

La grille ne permet pas de réaliser de saisie de données.

Il est possible de paramétrer quels sont les champs de la vue qui apparaissent par défaut sur la grille (dvcol_posdisplay) ainsi que l ’ ordre de tri des données selon ces champs (dvcol_orderposition pour définir l ’ ordonancement des champs pour la prise en compte du tri et dvcol_orderisasc pour préciser si ce champ doit être classé de façon ascendante (dvcol_orderisasc =1) ou descendante (dvcol_orderisasc =0)).

Il est important de noter que ce paramétrage est supplanté par les préférences utilisateur de la grille lorsqu ’ elles sont définies (table gi_ts_dvclg). Ces préférences sont accessibles en modification à l ’ utilisateur via l ’ interface « préférence grille » (cf 7.1) qui permet également de définir pour l ’ entité à laquelle appartient l ’ utilisateur quels sont les champs publiés par la grille et dans quel ordre ils sont triés.

Nota : les grilles publiées dans les sélecteurs simples bénéficient d ’ un traitement particulier en ce qui concerne le paramétrage de leur affichage (cf 9.4.1.1).

le filtrage de la vue applicative sur la grille
est décrit en XML dans le champ DVIEW_CONSTRAINTEXPR.

Ex de filtrage :

< persistentObject > < /type >

< /id >< /persistentObject >

< /criteria >

On peut également définir des critère de restriction sous forme de code c# :

< Restrictions.gt >

COL1271 < /property >

< /Restrictions.gt >

Cf 11.1 pour plus de précisions sur la syntaxe du filtrage XML.

Paramétrage des règles et conditions d ’ affichage des pictogrammes
L ’ application permet d ’ affecter aux vues applicatives des pictogrammes visibles :


 * Dans le treeview,
 * Dans la fiche,
 * Sur chaque ligne de la grille (non implémenté)

Tables permettant de gérer les pictos
Table GI_TS_DVHPX

Cette table permet pour l ’ instant de gérer les pictos par défaut sur une vue sans contrainte, il est utilisé pour les pictos du treeview, de la grille et de la fiche.

Cette table ne permettant pas de gérer correctement les conditions sur les données elle sera remplacée par celles-ci pour permettre de définir des conditions d ’ affichage de certains pictos par vue applicative :

Table GI_TS_DVHPX

Table GI_TS_DVHPXCC

Description d ’ une table CLIENT
Description de la table

Il faut décrire la table MAP_TABLE dans les tables MTDTB et MTDCL.


 * base système - > mapping - > onglet description tables: , choisir
 * Liste des tables: choisir dans la liste déroulante en partie haute de la fenêtre de l ’ application la base cliente (même si cette base apparaît déjà). Choisir dans la liste "charger depuis" la valeur "tables et vues de la base cliente"
 * Choix des tables: cocher les tables et vues dont la définition sera importée
 * Menu "options": les commentaires présents dans oracle sur chaque colonne peuvent être importés en tant que libellé. Cocher l ’ option pour importer les commentaires
 * Menu "publication": lancer "décrire les tables et colonnes sélectionnées"
 * Si une table a déjà été décrites, seules les nouveaux champs seront décrits.
 * Les champs de type INTEGER ou NUMBER sont mal gérés. Utiliser à la place des champs de type NUMBER(38).
 * A la fin de la génération, vérifier dans MTDCL que, pour chaque table, un seul champ est défini en tant que clé primaire.

Enfin, cliquez sur le bouton « générer les tables et colonnes », la génération est faite, vous pouvez le vérifier en consultant les tables et colonnes dans MCD & base client - > MCD - > tables et MCD & base client - > MCD - > colonnes.

Il faut redéfinir la clé primaire et la séquence en passant par MCD & base client - > MCD - > colonnes.

Définition des relations entre tables

Description de la vue applicative
 * Menu MCD et base client > Relations > relations directes
 * Indiquer les tables, les clefs primaires et la cardinalité entre les tables


 * Menu MCD et base client > MCD > tables
 * Sélectionner une ou plusieurs tables et menu Action sur sélection > créer des vues par défaut pour ces talbes
 * Des vues dont le nom correspond au MTDTB_label de la table sont générées
 * Définissez les droits sur l ’ entité par défaut pour ces vues, ainsi que l ’ action double clic. Il faut ensuite se placer sur la vue puis cliquer sur action sur sélection - > créer les colonnes de cette vue
 * Menu Vues > Vues
 * Sélectionner une ou plusieurs vues et menu Action sur selection > créer les colonnes de cette vue
 * Les colonnes des vues sont générées à partir des colonnes de la table maitre. Les libellés des colonnes correspondent aux champs MTDCL_labellong et MTDCL_labelshort
 * Menu Vues > Colonnes de vues > gestion générale: indiquer les droits sur chaque colonne de vue ainsi que l ’ ordre de priorité et de pertinence.

Ajout des menus (optionnel)

En se plaçant sur la vue applicative, on peut ajouter des menus en cliquant sur le bouton « menu particulier ». Il existe une batterie de bouton modèle pour aider à la création des menus.

Définissez ensuite les droits sur les menus.

Paramétrages liés à la grille
Cette rubrique concerne les paramétrages agissant sur l ’ interface grille dans son ensemble. Pour les paramétrages liés aux grilles publiant certaines tables ou vues, voir 5 : Terminologies et références.

Interface préférence grille

 * Pour modifier la liste « Nombre de ligne à afficher » : directement dans le code de GIMAO : \UserLayer\com.GeneraleInfographie.GMAO.UIL.Web\Patrimoine\Grille\Preferences.aspx.cs ligne 84.

Principe général
On décrit les Modules et Menus disponibles dans des tables. Ces descriptions servent à savoir ce que l ’ on met à disposition à l ’ administrateur. C ’ est sur ces descriptions que l ’ administration se ferra.



Les modules et menus au niveau applicatif sont décrits dans un fichier XML. Ce fichier XML, permet de savoir ce que propose le moteur. La partie modules et menus disponibles permet de savoir ce que propose l ’ implémentation du moteur.

''Les « menus de gauche » dans MAORI correspondent aux « entrées » des modules. Ces entrés seront définis dans un premier temps dans les XML applicatifs.''

Les modules
Les modules reprennent la désignation du module dans l ’ application. Le nom du module codé en MD5. C ’ est le couple Module/Nom du module codé qui permet de définir la License sur le module.

Table : GI_TS_DVMOD (table de description des modules)

Intégration dans Fox Web
Pour lancer les anciens modules on s ’ en tient aux droits Fox. Les modules ne vérifient pas de droit particulier sur les modules tant que l ’ on travaille dans l ’ environnement Fox Web.

organisation des menus
Les menus suivants sont gérés :


 * Les menus liés aux droits sur les vues : création, modification, duplication, suppression
 * Les menus liés à la navigation inter module (aller vers les DI …)
 * Les menus liés aux modules : export …
 * Les menus atteindre
 * Les menus spécifiques (lance un Href)

l ’ ensemble des menus par module et/ou par vue est décrit dans la table gi_ts_dvmnu (cf 3.3.12). Les entités permettant de définir les droits sur ces vues.


 * Les menus appartiennent à un module.
 * Les menus sont rattachables à une vue ou peuvent être définis sur toutes les vues du module
 * Des droits sur chaque menu sont définissables par entité
 * Les menus peuvent être imbriqués
 * L ’ application

Description des menus et modules dans l ’ application
Dans l ’ application chaque module est déclaré par un fichier XML. Ce fichier XML contient l ’ ensemble des informations sur le module :


 * Les sous modules
 * Les entrées
 * Les Menus
 * La description du module
 * La description des tables et vues nécessaires aux modules

Les clés des modules sont sur trois lettres. Ce sont ces trois lettres qui servent à nommer le xml : MOD_ [ ID_MODULE ] .XML le Xml se trouve dans APP_DATA.

Les clés des sous modules sont sur trois lettres. Elles sont précédés des trois lettres du module séparé par un point. ''' [ ID_MODULE ]. [ ID_SSMODULE ] '''

Les clés des menus sont incrémentales et sont précédés aussi de ''' [ ID_MODULE ]. [ ID_SSMODULE ]. [ incérement ] '''

< /key >

< /name >

< /comment >

< !--- tables et vues nécessaires--- >



< /model >

[ Description pour le module d ’ administration ]

< /comment >

[ nom de colonne de la base

< /type >

[ Description pour le module d ’ administration ]

< /comment >


 * [ soit « POST », « GET » ]

< /mode >

[ Description pour le module d ’ administration ]

< /comment >

[ D pour DATA, M pour intermodule, N pour none, A atteindre, I pour item (sans action) ]

< /type >

< modulelink / >

< menuparent/ >

[ Description pour le module d ’ administration ]

< /comment >

< /ssmodules >

< / gimodules >

droits sur les menus
Dans l ’ application d ’ administration, la définition des droits sur les menus se fait depuis l ’ interface d ’ édition des menus.

Pour le principe de stockage des droits sur les menus, cf « Des droits sur les fonctionnalités » p. 55.

Activation de la validation sur les menus de la fiche
Il est possible d ’ activer la validation des contrôles de la Fiche, au lancement des menus. Si cette option est active sur un des menus et qu ’ au moins un des contrôles de la fiche n ’ est pas valide :


 * Le lancement du menu est annulé
 * Le logiciel affiche la liste des champs invalides

Pour activer cette option sur un des menus de la fiche :

Dans la table GI_TS_DVMNU, il faut rajouter le mot clé « VALIDATION » dans la colonne DVMNU_ACTION_ACTIVATED, sur la ligne du menu concerné.

les menus atteindre
Les menus atteindre sont également paramétrés dans GI_TS_DVMNU mais nécessitent également la définition d ’ une ligne dans GI_TS_DVLNK afin de définir quelle sera la vue d ’ axe qui permet la mise en relation et quelles sont les colonnes de clef à utiliser.

Application d ’ administration : menu « vue » > menus « lien vers ».

Lancement d ’ un état spécifique (menu impression)
Un module d ’ impression dynamique permet d ’ imprimer un état CrystalReport branché sur un menu de la grille ou de la fiche (si aucun état cystal n ’ est définit, l menu d ’ impression lancera la procédure d ’ impression générique du tableau de données).

Un générateur d ’ état permet d ’ éditer des états CrystalReport depuis la grille ou la fiche GIMAO. Pour cela, il est nécessaire d ’ effectuer le paramétrage suivant :

Remarque :

Dans _TITREDIT préciser les paramètres suivants :

Menus module GIMAO.NET
Les menus de la page d ’ accueil de GIMAO.NET doivent être paramétrer dans GI_TS_DVMNU.

Pour la création de ses menus un module dans GI_TS_DVMOD doit être créé.

Ensuite chacun des menus doit être rempli dans la partie « Menu vue ». Les menus créés doivent être rattaché au module nouvellement créé, chaque menu enfant doit être rattaché à son menu parent (dans le cas d ’ un menu parent ne pas le rattaché) et chaque menu doit être affecté à une entité.

Utilisation dans GIMAO.NET
Le usercontrole wucMenu implémente la logique du paramétrage de l ’ application d ’ administration GIMAO. Il utilise pour cela le service MenuService.

propriétés communes à tous les contrôles
Propriété id :

Contrôle textedit
Propriété cols :

Propriété rows :

Contrôle selector
Permet de sélectionner un (et un seul) enregistrement depuis une table en relation avec la table maître de la vue applicative et d ’ associer cet enregistrement avec l ’ enregistrement en cours (établissement d ’ une relation). La relation entre les 2 tables doit être décrite dans gi_ts_mtdrl.

Propriété filter : permet de définir un filtre sur la grille listant les enregistrements de la table secondaire pour limiter les choix de l ’ utilisateur.

Contrôle multipleselector
Ce sélecteur permet de définir une relation multiple entre la table maître de la vue applicative et une table qui lui est reliée (une relation NN entre les 2 tables doit être décrite dans gi_ts_mtdrl, il doit donc exister une table intermédiaire de relation NN).

Propriété filter : permet de définir un filtre sur la grille listant les enregistrements de la table secondaire pour limiter les choix de l ’ utilisateur.

Contrôle navbar
Pour supprimer la navbar dans la fiche, il suffit de ne pas mettre de valeur dans le champs "DVMNU_TOOLBAR_IMG" de la table "GI_TS_DVCOL".

Contrôle checkbox
Ce contrôle doit être branché sur une liste comportant 2 valeurs (par ex : N et O ou 0 et 1 ou non et oui…) le principe retenu est que si le champ de l ’ enregistrement publié sur la fiche en cours contient la deuxième valeur, le checkbox est coché. Il est décoché dans le cas contraire. La valeur stockée dans la liste sera celle visible sur la grille.

filtrage dynamique sur les sélecteurs
< gipanelid="CABLE_3"version="1.0.1" >    < viewObjectid="cable_3"viewID="3" >   < navbarid="navbar_cable_3"disable="false"/ >   < texteditid="CODE_CABLE"dataSourceID="209"disable="false" type="text"/ >   < selectorid="CODE_MATCABLE"dataSourceID="389" disable="false"cols="100" >     < ! [ CDATA [ < persistentObject > < /type > < /id >< /persistentObject > < Restrictions.eq > COL276 < /property > " ’’+ valueControl( ’’ CODE_CABLE ’’ ) +’’ " < /value >< /Restrictions.eq >< /restriction >< /add >< /criteria >]]>   < /filter >   < /selector >   < texteditid="MATIERE"dataSourceID="390"disable="true"type="text"/ >  ... < /gipanel >

Masques de saisie
Pour tous les champs devant faire l ’ objet d ’ un contrôle par rapport à un masque de saisie, ce format doit être configuré dans le champ : « GI_TS_MTDCL.MTDCL_CONSTRAINTS » (appli d ’ admin : menu « MCD et base client » > « MCD » > « colonnes » )Sous la forme d ’ une expression régulière.

ex : pour un format heure (12h45) : ^[ 0-9 ][ 0-9 ] h [ 0-9 ][ 0-9 ] $ Les masques de saisies sont normalement gérés sur tous les contrôles.

paramétrage de l ’ interactivité des contrôles
Ces paramétrages se font dans le code XML de la description de la fiche

Matrice de capacités des controles

 * L ’ activation/deactivation se fait par l ’ attribut <font color="#000080">disable que l ’ on peut affecter à false ou true.
 * La récupération de la valeur en cours se fait par le mot clef : valueControl

désactivation des contrôles cotés client : l ’ attribut « onChange »
Bilan de la mise en place de la désactivation des contrôles cotés client :


 * Seuls les textbox, combobox, simpleselecteur et multipselecteur supporte les opérations d ’ activation/désactivation ;
 * L ’ événement onChange n ’ est utilisable que les textbox et combobox ;
 * La récupération de valeur n ’ est utilisable que sur les textbox, combobox, simpleselecteur, multiselecteur ;

Il est possible, au niveau du client, d ’ activer ou de désactiver des contrôles. Cette demande s ’ effectue par le biais des deux fonctions javascript suivantes : - disableControl : qui prend en paramètre l ’ identifiant du contrôle à désactiver ; - enableControl : qui prend en paramètre l ’ identifiant du contrôle à activer ; L ’ activation ou désactivation des contrôles peut être conditionnée par la(les) valeur(s) d ’ un(de plusieurs) contrôle(s). Pour réaliser ce comportement, le fichier XML, décrivant la fiche, admet pour chacune de ses balises XML, représentant un contrôle du type zone de texte ou sélecteur, un attribut XML "onChange" qui contient le code javascript à exécuter en cas de changement de valeur. La récupération de la valeur, au niveau client, d ’ un contrôle peut être effectuée via la fonction javascript suivante : - valueControl : qui prend en paramètre l ’ identifiant du contrôle à lire ; Voici un exemple d ’ utilisation :   < ... onchange="if (valueControl( ’ CODE_RUE ’ ) == ’ 12 ’ ) { disableControl( ’ LIBELLE ’ ); } else { enableControl( ’ LIBELLE ’ ) ; } " ... / >

filtrage d ’ un contrôle en fonction de la valeur d ’ un autre contrôle.
voici ce qu ’ il faut inclure dans la description du control (contenu dans la description globale de la fiche) <font color="#000080">:

< selector id="CODE_MATCABLE" dataSourceID="389" disable="false" cols="100" >

< ! [ CDATA [ < persistentObject > < /type > < /id >< /persistentObject > < Restrictions.eq > COL276 < /property > " ’’  + valueControl( ’’ CODE_CABLE ’’ ) +  ’’ " < /value >< /Restrictions.eq >< /restriction >< /add >< /criteria >]]>

< /filter >

< /selector >

Ici, on filtre le selecteur de type de cable en fonction de la valeur déjà saisie dans le contrôle « code_matcable » col276

La GED
objectifs


 * Associer des fichiers numériques ( .doc, images, plans, … ) à des tables de GIMAO (décrites dans GI_TS_MTDTB)
 * Les fichiers numériques restent sur le réseau du client est sont référencés par des chemins de type lecteur réseau sans vérification de l ’ existence ou non du fichier
 * Pour chaque fiche (et uniquement la fiche) ajouter des nouveaux fichiers, associer des fichiers existants, les dissocier ou les supprimer (s ’ ils n ’ y a plus de lien NN avec d ’ autres fiches)

Un (et un seul) contrôle GED peut être ajouté à une fiche. Ce contrôle est particulier car il n ’ est pas encore insérable dans un onglet et apparaît en dessous des autres contrôles. Il n ’ est pas paramétrable via le XML descriptif de la fiche et l ’ on n ’ est donc pas sensible aux droits utilisateurs sur les controles.

Pour associer la GED à une table, suivre les étapes suivantes :

1. déclarer une relation NN dans GI_TS_MTDRL (sur l ’ interface : menu « mcd et base client > relations > relations directes »). Cette relation doit contenir :


 * table parent : table GED, clef primaire : ID_GED
 * table enfant : la table sur laquelle doit être associée la GED et sa clef primaire
 * bien définir GED dans typ lien métier
 * cardinalité : NN
 * la table de relation NN doit être la table lienGED comme ci-dessous :



Figure 1 : le paramétrage d ’ une relation de GED

La GED est un composant qui s ’ ajoute à la fiche si :


 * L ’ utilisateur a droit à la vue GED (KEYWORD : GED)
 * Les champs nécessaires sont ID_GED (identifiant), CHEMIN (Chemin réseau), LIBELLE (Description)

fonctionnement
un contrôle sélecteur (« selector » dans le paramétrage xml de la fiche)doit être lié à une colonne de vue pointant sur une table liée à la table maître (colonne rattachée).

Le sélecteur utilisera la vue de la table liée dont le dview_numview=0.

La position des colonnes apparaissant dans la grille du selecteur est définie grâce au champ dvcol_relevant sur la vue du selecteur.

De même que sur la grille classique, un tri peut être paramétré par colonnes grâce aux champs dvcol_orderposition et dvcol_orderisasc. (les préférences grilles définies dans la table dvclg ne sont pas prises en compte pour les sélecteurs, le tri et la position des colonnes ne sont donc pas des éléments modifiables par l ’ utilisateur depuis l ’ interface web).

paramétrage de la présélection du sélecteur
La presaisie du sélecteur peut être effectuée par les filtres dynamique sur la valeur saisie dans le cadre du selecteur avant d ’ appuyer sur le bouton de selection.

Voici un exemple :  < gipanel id="CABLE_3" version="1.0.1" >                                     < viewObject id="cable_3" viewID="3" >                                    < navbar id="navbar_cable_3" disable="false" / >                                    < textedit id="CODE_CABLE" dataSourceID="209" disable="false"                                               type="text" / >                                    < selector id="CODE_MATCABLE" dataSourceID="389"                                               disable="false" cols="100" >                   < ! [ CDATA [ < persistentObject > < /type > < /id >< /persistentObject > < Restrictions.eq > COL276 < /property > " ’’  + valueControl( ’’ CODE_CABLE ’’ ) +  ’’ " < /value >< /Restrictions.eq >< /restriction >< /add >< /criteria >]]>           < /filter >           < /selector >                                    < textedit id="MATIERE" dataSourceID="390" disable="true" type="text" / >  ... < /gipanel >

fonctionnement
il faut :


 * 3 tables décrites dans GIMAO (table maître, table d ’ éléments à rattacher, table de relation NN)
 * Décrire les relations entre ces 3 tables dans gi_ts_mtdrl en utilisant la relation NN (appli admin :MCD et Base client > relations > relations directe)
 * Créer une vue applicative pour la table maître et la table de relations
 * Dans la vue applicative de la table maître, ajouter un des champs de la table de relations (ex, le champ code)
 * Dans la fiche de la table maître, rattacher ce champ à un contrôle multipleselector.

Utiliser le sélecteur en mode saisie rapide
Il est possible de rendre le selecteur directement éditable afin de permettre à l ’ utilisateur de saisir directement un enregistrement dans la table sur laquelle il réalise une recherche. La fenêtre du sélecteur se mute alors en fiche autorisant une saisie (si le paramétrage et les droits le permettent).

Voici la démarche à suivre pour créer un menu dans un sélecteur permettant de créer un nouvel élément :

1. Insérer une ligne dans « gi_ts_dvmnu » avec les valeurs suivantes (les autres valeurs sont libres et dépendantes du résultat voulu) :


 * DVMOD_ID = 10
 * DVMNU_HREF = « /Patrimoine/Fiche/Default.aspx?rowID=-1&appViewID=%APP_VIEW_ID%&gotourl=%URL% »
 * DVMNU_DEFAULT_ENABLED = 1
 * DVIEW_ID = Le numéro vue sur laquelle le menu doit apparaître

2. Insérer dans « gi_ts_entrg » une ligne donnant doit à l ’ utilisateur d ’ accéder au menu créé

Insertion depuis la fiche
Lors de la création d ’ un élément, la fiche insert d ’ abord des données vides afin de récupérer l ’ id du PK de la table. Cet insert est alors suivi d ’ un update qui remplit

syntaxe de filtrage XML
<font color="#000080">

< persistentObject >

< /type >

< /id >

< /persistentObject >

< Restrictions.eq >

[ NOM ou IDENTIFIANT de la propriété ]< /property >

« [ VALEUR de la propriété ] » < /value >

< /Restrictions.eq >

< /restriction >

< /add >

< Restrictions.ne >

[ NOM ou IDENTIFIANT de la propriété ]< /property >

[ VALEUR de la propriété ]< /value >

< /Restrictions.ne >

< /restriction >

< /add >

< /criteria >


 * Restrictions.ne : différent de
 * Restrictions.eq : égale à

Ex : <font color="#000080">pour filtrer les BT à venir dans l ’ année :

<font color="#000080">  < persistentObject > < /type >     < /id >   < /persistentObject >         < Restrictions.gt >               COL1271 < /property >     "to_date( ’ " + System.DateTime.Now + " ’, ’ DD/MM/YYYY HH24:MI:SS ’ )" < /value >    < /Restrictions.gt >    < /restriction >   < /add >       < Restrictions.lt >               COL1271 < /property >     "to_date( ’ " + System.DateTime.Now.AddYears(1) + " ’ , ’ DD/MM/YYYY HH24:MI:SS ’ )" < /value >    < /Restrictions.lt >    < /restriction >   < /add >   < /criteria >

Les listes de valeurs
Les tables utilisées sont :


 * Gi_ts_mtdls : liste des listes
 * Gi_ts_lstit : valeurs des listes systèmes
 * Gi_tc_lstit : valeurs des listes clientes

Dans l ’ application d ’ administration : menu données

Exemples d ’ utilisation dans oracle :

configurer un multiselecteur
(ex : relation NN entre rue et liste des codes de la liste V_GI_TM_TRAITSURNP)


 * créer la table de relation NN RUESYSPEINTNP et s ’ assurer que les champs clef êtrangères sont bien configurés sur la base.
 * décrire dans mtdtb et mtdcl : les tables rue et V_GI_TM_TRAITSURNP ainsi que la table de relation NN RUESYSPEINTNP. Pour cela : base systeme > mapping > onglet description tables, choisissez dans la liste « charger depuis » les « tables et vues non décrites » (si vos tables n ’ ont jamais été décrites) ou « tables et vues décrites » si les tables sont déjà décrites et qu ’ il s ’ agit simplement de les mettre à jour. La grille des tables se recharge alors, recherchez vos tables rue et V_GI_TM_TRAITSURNP, cochez-les (attention, les autres éléments doivent être décochés, utilisez le contrôle « sélectionner tout » au préalable pour tout désélectionner. Enfin, cliquez sur le bouton « générer les tables et colonnes », la génération est faite, vous pouvez le vérifier en consultant les tables et colonnes dans MCD & base client > MCD > tables et MCD & base client > MCD > colonnes.
 * Attention, la table de relation doit être marquée comme table de relation : MCD & base client > MCD > tables, positionnez vous sur la table de relation et vérifiez que la liste « type de table » est bien sur « table_relation ». Si ce n ’ est pas le cas, modifiez cette propriété en fonction.




 * décrire la relation entre rue et V_GI_TM_TRAITSURNP dans la table gi_ts_mtdrl. appli administration : menu MCD > relations > relation directe. Ajouter une nouvelle relation, définir les clef primaire de chaque table




 * Si elles n ’ existent pas, générer les vues applicatives correspondant aux tables rue et V_GI_TM_TRAITSURNP. Pour cela : menu MCD et Base Client > MCD > tables. Rechercher la table rue, se positionner dessus et la sélectionner puis menu action sur sélection > créer des vues par défaut pour ces tables. Définissez les droits sur l ’ entité par défaut pour ces vues.




 * Si ces vues existent, il suffit de rajouter les nouvelles colonnes, voir le point suivant pour cela.
 * Créez les colonnes de vues associées : menu vues > vues, sur l ’ interface, recherchez la vue V_GI_TM_TRAITSURNP, sélectionnez-là et créez les colonnes de cette vue (menu action sur sélection)




 * Les colonnes de vues sont créées, pour le vérifier cliquez sur le bouton colonnes de l ’ interface précédente.



SELECT * FROM axe18;
 * Cette vue permettra d ’ afficher la grille du sélecteur multiple, il est donc nécessaire de définir les ordres de priorités d ’ affichage des colonnes (dvcol_relevant) et éventuellement de renommer les intitulés courts. Appliquez les droits par défaut sur la première entité pour l ’ ensemble de ces colonnes (lecture-seule est ici suffisant puisque la saisie ne doit pas se faire sur les colonnes de cette vue mais par rattachement).
 * Il reste à créer et décrire la vue d ’ axe permettant de passer d ’ une table à l ’ autre.

CREATE OR REPLACE VIEW axe18 (id_rue,id_lstit_np,id_lstit_pd,id_lstit_pv,id_lstit_pn)

AS SELECT rue.id_rue,v_gi_tm_traitsurnp.lstit_id,v_gi_tm_traitsurpd.lstit_id,v_gi_tm_traitsurpv.lstit_id,v_gi_tm_traitsurpn.lstit_id FROM

rue,v_gi_tm_traitsurnp,RUESYSPEINTNP,RUESYSPEINTPV,RUESYSPEINTPD,RUESYSPEINTPN,v_gi_tm_traitsurpd,v_gi_tm_traitsurpv,v_gi_tm_traitsurpn

WHERE

rue.id_rue=RUESYSPEINTNP.id_rue( + ) AND

rue.id_rue=RUESYSPEINTPD.id_rue( + ) AND

rue.id_rue=RUESYSPEINTPV.id_rue( + ) AND

rue.id_rue=RUESYSPEINTPN.id_rue( + ) AND

RUESYSPEINTNP.lstit_id=v_gi_tm_traitsurNP.lstit_id( + ) and

RUESYSPEINTPD.lstit_id=v_gi_tm_traitsurPD.lstit_id( + ) and

RUESYSPEINTPV.lstit_id=v_gi_tm_traitsurPV.lstit_id( + ) and

RUESYSPEINTPN.lstit_id=v_gi_tm_traitsurPN.lstit_id( + );

Puis décrire la relation via le menu vues > menus lien vers. En utilisant la vue axe18 comme vue de relation (dans l ’ exemple ci-dessous, la relation est nommée sysnp
 * Décrire la vue (pour cela recommencer les étapes précédantes jusqu ’ à la description de la table et des colonnes avec la vue axe18, il n ’ est pas nécessaire de générer la vue applicative pour les vues d ’ axe)




 * Enfin, il ne reste plus qu ’ à regénérer les vues oracle et la dll de mapping générale. Menu base système > mapping > onglet mapping, Dans l ’ onglet liste des tables, chargez les tables depuis les « tables et vues décrites », selectionnez les toutes puis dans l ’ onglet action, définissez les chemins de la dll de mapping à générer, des fichiers de classe et des vues, puis utiliser le bouton « tout régénérer » pour lancer la génération des vues et du mapping.




 * Une fois le traitement terminé (au bout de quelques minutes), arrêter le serveur web et copier la dll à son emplacement définitif.

à réorganiser
récupéré des mails de FPO :

récapitulatif concernant les sous menus du menu « Descendance » :

 * « Ajouter un départ » : Pour gérer ce cas, qui n ’ est pas réglé, il faut ajouter à la fiche un mécanisme qui lui permet de passer d ’ un objet à un autre objet vide tout en transférant la clé du premier au second.
 * « ajouter une prise » : Pour gérer ce cas, qui n ’ est pas réglé, il faut ajouter à la fiche un mécanisme qui lui permet de passer d ’ un objet à un autre objet vide tout en transférant la clé du premier au second.
 * « ajouter un support » : Pour gérer ce cas, qui n ’ est pas réglé, il faut ajouter à la fiche un mécanisme qui lui permet de passer d ’ un objet à un autre objet vide tout en transférant la clé du premier au second.
 * « ajouter un coffret de conn. » : Pour gérer ce cas, qui n ’ est pas réglé, il faut ajouter à la fiche un mécanisme qui lui permet de passer d ’ un objet à un autre objet vide tout en transférant la clé du premier au second.
 * « suppression complète » Pour gérer ce cas, qui est réglé, il faut ajouter dans « GI_TS_DVMNU la valeur » « RECURSIVE_DELETE_PTLUM » pour le champs nommé « DVMNU_KEY ».
 * « ajouter un massif » : Pour gérer ce cas, qui n ’ est pas réglé, il faut ajouter à la fiche un mécanisme qui lui permet de passer d ’ un objet à un autre objet vide tout en transférant la clé du premier au second.
 * « ajouter une console » : Pour gérer ce cas, qui n ’ est pas réglé, il faut ajouter à la fiche un mécanisme qui lui permet de passer d ’ un objet à un autre objet vide tout en transférant la clé du premier au second.
 * « ajouter une lanterne sans console » : Pour gérer ce cas, qui n ’ est pas réglé, je n ’ ai aucune procédure stockée ou programme permettant de répondre à cette problématique.
 * « Ajouter un coffret de prise » : Pour gérer ce cas, qui n ’ est pas réglé, je n ’ ai aucune procédure stockée ou programme permettant de répondre à cette problématique.
 * « rendre cette console fictive » : Pour gérer ce cas, qui n ’ est pas réglé, je n ’ ai aucune procédure stockée ou programme permettant de répondre à cette problématique.
 * « ajouter une lanterne » : Pour gérer ce cas, qui n ’ est pas réglé, il faut ajouter à la fiche un mécanisme qui lui permet de passer d ’ un objet à un autre objet vide tout en transférant la clé du premier au second.
 * « ajouter une lampe » : Pour gérer ce cas, qui n ’ est pas réglé, il faut ajouter à la fiche un mécanisme qui lui permet de passer d ’ un objet à un autre objet vide tout en transférant la clé du premier au second.