Pour les développeurs¶

Mise à jour de l’architecture fichier¶

Le Codex est un projet libre de droit, déposé sur github (http://github.com/fedecbn/codex). La mise à jour des fichiers se fait directement par l’utilisation de de git (git pull).

Le schema application¶

Le schema application est le schema utilisé par l’application pour faire la gestion des rubriques, des onglets, des utlisateurs des droits...

bug

(obsolète) Table rassemblant tous les bugs remontés par les utilisateurs.

droit

Table rassemblant les règles de gestion des droit. La gestion des droits est basée sur un système de rôle non hierarchisé : un rôle (colonne role) à accès à un objet (colonne objet), présent dans un onglet (colonne onglet) d’une rubrique particulière (colonne rubrique). Ces droits sont classé par type (colonne typ_droit), décrit dans le chapitre Les niveaux de droits.

log

Table rassemblant les logs généraux de l’application selon les utilisateurs (colonne id_user = identifiant de l’utilisateur, référentiel = applications.utilisateur).

onglet

Table rassemblant la description (colonne nom pour le nom de l’onglet, colonne ss_titre pour le sous-titre de l’onglet) des différents onglets de chaque rubrique

pres

Table rassemblant les textes d’en-tête (colonne page = ‘header’) et de pied de page (colonne page = ‘footer’) de la page d’acceuil (colonne pres) en fonction du module (colonne id_module).

rubrique

Table rassemblant les informations nécessaire pour l’affichage du bouton d’accès au rubrique : son identifiant (colonne id_module), sa position les unes par rapport aux autres (colonne pos), son icone de représentation (colonne icone), son chemin d’accès vers les fichiers (colonne link), son type (colonne typ - ‘list’ = rubrique classique, ‘admin’ = rubrique d’administration).

suivi

Table rassemblant toutes les modifications réalisé dans une rubrique. A chaque enregistrement, cette table historise les valeurs anciennes et nouvelles de chaque table.

update_bdd

Table rassemblant l’historique des mises à jour de la base de données. Ce système, permettant de mettre à jour la base en même temps que les mises à jour logiciels est décrit dans le chapitre Mise à jour de la base de données.

utilisateur

Table rassemblant tous les utilisateurs, leur identifiant (colonne id_user), leur cbn (colonne id_cbn), leur nom et prénom. Les colonnes ref et niveau étaient utilisées pour la gestion des droits. Ces colonnes sont obsolètes.

utilisateur_role

Table rassemblant les rôles de chaque utilisateurs (colonne id_user) pour chaque rubrique (colonne rubrique). Chacune des autres colonnes correspondent aux rôles disponible pour cette rubrique.

Les schemas “rubrique”¶

Afin d’avoir une approche le plus modulaire possible, chaque rubrique possède son schema propre de base de données. l’architecture de ces schemas (tables, champs...) sont propre à chaque rubrique SAUF pour certaines tables, qui sont générique à chaque rubrique et que l’on retourve dans chaque schema (ayant subit une généralisation) :

discussion

Table rassemblant les éléments de discussion réalisé au niveau des fiches. En bas de chaque fiche, il est possible, pour un utilisateur avec le rôle de “participant”, d’ajouter un commentaire spécifique à la fiche. Dans ce cas, ce commentaire sera enregistrer dans la table discussion et sera affiché en bas de la fiche. Un projet de développement est de sortir centraliser ces discussions dans le schema application

Le schema référentiel¶

Le schema référentiel rassemble les référentiels utilisés par les rubriques. La majorité de ces référentiels ont été implémenté pour la rubrique “liste rouge” (schema lr). Un développement à prévoir est de rappatrier ces référetiels au sein même du schéma, pour plus de modularité. 2 tables extrèmement importantes sont présentent dans ce schema :

champs

Table rassemblant la description de toutes les tables de toute les rubriques. Cette table permet de renseigner toutes les informations nécessaire à l’application pour afficher et gérer les champs de ces rubriques à travers, notamment, son typage personnalisé (colonne type), son libellé court (colonne description) et long (colonne description_longue), le référentiel auquel il est rattaché (colonne referentiel), sa position dans le tableau de synthèse (colonne pos), la taille et style de la colonne (colonne jvs_desc_column) et les paramètre de filtrage de la colonne (colonne jvs_filter_column).

champs_ref

Table rassemblant les informations correspondantes aux référentiels utilisés par les champs. On y retrouve le nom du référentiel (colonne nom_ref - ce nom est totalement arbitraire), le système de clé-valeur du référentiel (colonne cle et colonne valeur), ainsi que l’endroit où le référentiel se trouve (colonne schema et colonne table_ref).

Mise à jour de la base de données¶

La mise à jour de la base de données n’est pas automatique avec la mise à jour du code. Un procédure parallèle doit être réalisé à chaque mise à jour de la base.

Dans le cas où vous souhaitez simplement mettre à jour la base de données suivant les modifications réalisées par les autres développeurs, le fonctionnement est le suivant :

• Comparez les mises à jours : dans la base de données, regarder le contenu de la table applications.update_bdd et vérifiez les dernières mises à jours réalisées. Un fois la mise à jour logiciel réalisée avec git (cf. Mise à jour de l’architecture fichier). Comparez avec le numéro des dernièrs fichiers présent dans le dossier _SQL/update_bdd.
• Lancez les mise à jour : tous les fichiers dont le nom n’apparait pas dans la table applications.update_bdd devront être lancés. Assurez-vous, dans les variables initiales qu’il n’est pas nécessaire de renseigner quelquechose au début du fichier.

Cette procédure manuelle pourrait être, à terme, automatisé à chaque nouveau fichier sql ajouté (détection d’un nouveau fichier par rapport à l’historique des mise à jour).

Dans le cas où vous souhaitez vous même proposer une nouvelle modification à la base, le fonctionnement est le suivant :

• Création d’un fichier sql : Lors d’un développement nécesitant la mise à jour de la base de données, cette modification doit êter scripté en sql ET générique (applicable à toute les situations possibles, générique face aux utilisateurs impactés). Ce fichier doit être positionner avec les autres fichiers de mise à jours (dossier _SQL/update_bdd) et doit être nommé de tel manière qu’il vient à la suite des autres fichiers (nomenclature numérique). Il est FORTEMENT conseillé de s’inspiré des fichiers précédents.
• Le contenu :
  • une première partie paramétrage permet, ponctuellement, de passer un certain nombre de variables nécessaire à la mise à jour (ex : user_codex nom du rôle administrateur, spécifique à la base de données - phase qui permet de gerer une phase de test de la mise à jour de la base si nécessaire).
  • une deuxieme partie permet de réaliser les modifications à réaliser sur la base (ALTER TABLE, INSERT/UPDATE...). ATTENTION, il est impératif que le script de mise à jour puisse être répété (par exemple, si le script comprend un CREATE TABLE, il faudra auparavant un DROP TABLE IF EXISTS).
  • une troisième partie permet de gérer la traçabilité de la mise à jour. Il faut alors ici décrire la raison de la mise à jour, le code du dernier commit ainsi que le nom du fichier sql en question.
• La phase de test : avant de mettre votre script en production, assurez-vous que la variable phase soit bien égal à test et lancer/modifier autant que souhaitez le script.
• Lancement du fichier sql : Une fois que le script est finalisé, commentez/décommentez les lignes de la variable phase pour qu’elle soit égal à prod. Lancez une dernière fois le fichier. Ainsi, l’historique de votre base sera à jour.
• Commit des modifications : ce nouveau fichier pourra alors être le fruit d’un commit spécificique, et pourra êter partagé avec les autres développeurs.

Les niveaux de droits¶

Les niveaux de droits, ou type de droit, sont une manière de faciliter la gestion globale des droits. On distingue les niveaux suivant :

• d1 : droit d’accès aux fichiers. Ce type de droit permet de définir quel role peut accéder à quel fichier fichier. Dans ce cas, l’objet est le fichier,
• d2 : droit d’accès aux objets de la rubrique. Ce type de droit permet de définir quel rôle peut accéder à quel objet d’une rubrique. Dans ce cas, l’objet peut être un bouton, une image...,
• d3 : droit d’accès spécifique à l’utilisateur. Ce type de droit permet de définir, en fonction de l’utilisateur, quel accès il possède (ex : dans la partie “administration > utilisateurs”, un CBN ne peut voir que les utilisateurs de son CBN),
• d4 : droit d’accès à une champ. Ce type de droit permet de définir quel rôle peut, dans une fiche, modifier un champ. Dans le cas contraire, le champ sera bloqué,
• d5 : droit de modification de la base. Ce type de droit permet de définir sur quel rôle a le droit de modifier la base de données (ajout, modification, suppression).

A ce jour, seulement les niveaux de droit d1 et d2 ont été mis en place.

Les rôles¶

Pour chaque rubrique, l’utilisateur possède un ou plusieurs rôles. Le rôle par défaut d’un utilsateur à sa création est “pas d’accès” (en base de donnéées, “pas d’accès” = TRUE). Un utilisateur qui a accès à une rubrique a au moins un rôle activé (en base de données “nom_du_role = TRUE”) ET la colonne “pas d’acces” = FALSE. La gestion des rôle pour chaque utilisateur est géré, dans la base de données, dans la table utilisateur_role.

Définir les droits¶

Au sein de la base de données, la table droit fait le lien entre les rôles et les niveaux de droit. Ainsi, il est possible de définir dans cette table quel rôle a accès à quel droit sur tel objet d’une rubrique. Aujourd’hui, la gestion de la définition des droits n’a pas été interfacé avec le codex (gestion direct en base de données).

• Ajouter une règle d’accès

La première étape lors pour définir les droits est de se poser la question de “quel rôle aura le droit de réaliser cette action?”. En répondant à cette question, il est alors possible de rajouter une ligne dans la table droit qui correspond à la réponse à cette question. Ensuite, il est possible d’accèder à cette nouvelle règle en utilisant dans le code à la fonction ref_droit.

• Ajouter des rôles

La gestion des droits n’étant pas hierarchisée, il est possible d’ajouter des rôles en fonction du besoin dans le cas où les rôles existants ne suffisent pas. Ex : ajout du rôle de validateur. Pour se faire, il est nécessaire d’ajouter une colonne à la table utilisateur_role et d’attribuer le rôle correspondant aux utilisateurs. Les règles correspondantes à ce nouveau rôle devront être décrit dans la table droit