2. La version 4.3¶

2.1. Les nouveautés de la version 4.3¶

…

2.2. Mettre à niveau depuis openMairie 4.2 vers 4.3¶

Cette procédure permet de mettre à niveau une application utilisant openMairie version 4.2.0 vers openMairie 4.3.0.

Pour conserver une application fonctionnelle tout au long de la mise à niveau, il est vivement conseillé de:

suivre les étapes de cette procédure dans l’ordre;
ne pas utiliser le générateur lorsque ce n’est pas indiqué.

Consultez la section sur les erreurs connues si des erreurs persistent après la mise à niveau.

2.2.1. Étape 1: mettre à jour les surcharges du framework¶

2.2.1.1. Classe `application`¶

Supprimer l’utilisation de l’attribut:

<?php

var $permission_if_right_does_not_exist = true;

?>

S’il est utilisé dans une surchage, il doit être remplacée par:

<?php

$this->config['permission_if_right_does_not_exist'];

?>

Les méthodes surchargés de la classe om_application doivent être mises à jour avec leur nouvelle implémentation.

2.2.1.2. Classe `dbForm`¶

Les méthodes surchargés de la classe dbForm doivent être mises à jour avec leur nouvelle implémentation.

2.2.1.3. Classe `formulaire`¶

Les méthodes surchargés de la classe formulaire doivent être mises à jour avec leur nouvelle implémentation.

2.2.1.4. Classe `table`¶

Les méthodes surchargés de la classe table doivent être mises à jour avec leur nouvelle implémentation.

Supprimer l’utilisation de la méthode:

<?php

function countHrefColumns($href = array())

?>

Si elle est utilisée dans une surchage, elle doit être remplacée par:

<?php

function countActions($actions)

?>

2.2.2. Étape 2: mettre à jour la base de données¶

2.2.2.1. La structure¶

La structure de la base de données d’openMairie a changée sensiblement depuis la version 4.2.0. Pour mettre à jour la base de données depuis cette version il faudra exécuter le script SQL ver_4.3.0.sql.

Pour MySQL:

/data/mysql/ver_4.3.0.sql

Pour PostgresSQL:

/data/pgsql/ver_4.3.0.sql

2.2.2.2. Les tables métier¶

Le générateur gère maintenant plusieurs contraintes:

PRIMARY KEY
FOREIGN KEY
UNIQUE
NOT NULL

En fonction de ces contraintes les fichiers de l’application sont générés différemment par rapport à openMairie version 4.2.0.

2.2.2.2.1. `PRIMARY KEY`¶

Ajouter la contrainte SQL PRIMARY KEY.

Le générateur peut maintenant utiliser les clés primaires. Pour créer le champ identifiant, il faudra utiliser la contrainte PRIMARY KEY à la place des noms de table en tant que nom de colonne.

2.2.2.2.2. `FOREIGN KEY (PostgresSQL)`¶

Ajouter la contrainte SQL FOREING KEY.

Le générateur gère également les clés étrangères des bases PostgresSQL. Pour créer des références, il faudra utiliser la contrainte FOREIGN KEY à la place des noms de table étrangères en tant que nom de colonne.

2.2.2.2.3. `UNIQUE`¶

Ajouter la contrainte SQL UNIQUE.
Mettre a jour les fichiers de surcharge du répertoire obj/.

La contrainte UNIQUE permet maintenant de gérer automatiquement les champs uniques. Il n’est plus nécessaire de surcharger la méthode verifier des modèles pour gérer ce type de champ. Il faudra nettoyer les surcharges de verifier en supprimant la vérification manuelle des champs requis et les remplacer par des contraintes UNIQUE dans la base de données.

2.2.2.2.4. `NOT NULL`¶

Ajouter la contrainte NOT NULL aux champs requis.
Supprimer la clause DEFAULT des champs requis.
Supprimer la contrainte NOT NULL des champs non-requis ou ajouter la clause DEFAULT en fonction du besoin.
Mettre a jour les fichiers de surcharge du répertoire obj/.
Générer.

Toutes les colonnes NOT NULL généreront des champs requis. Des champs qui n’étaient pas requis dans la version 4.2.0 peuvent donc l’être dans la version 4.3.0 après une génération. Il faut donc supprimer la contrainte NOT NULL des colonnes qui ne sont pas réellement requises par l’application ou ajouter une valeur par defaut avec la clause DEFAULT.

Concernant les champs requis par l’application. Il n’est plus nécessaire de surcharger la méthode verifier des modèles pour gérer ce type de champ. Il faudra nettoyer les surcharges de verifier en supprimant la vérification manuelle des champs requis et les remplacer par des contraintes NOT NULL sans clause DEFAULT dans la base de données.

Important

Vous pouvez générer à nouveau l’application à partir d’ici.

2.2.3. Étape 3: mettre à jour les fichiers de surcharge du répertoire `sql/`¶

2.2.3.1. Alias des tables étrangères¶

Prefixer le nom des colonnes étrangères par l’alias généré dans gen/sql/.

Le générateur peut donner à une table étrangère un alias unique. Cela permet d’effectuer plusieurs jointures sur une même table sans avoir d’erreur d’ambiguïté avec les nom des colonnes. Pour cela, dans les fichiers du répertoire sql/ contenant plusieurs référence vers une même table étrangère, les noms des colonnes provenant de ces tables étrangères devront être préfixés par l’alias adéquat. Cet alias apparaît dans la définition de la variable $table dans les fichiers générés du répertoire gen/sql/.

2.2.3.2. La clause `ORDER BY`¶

Supprimer les surcharges de la variable $tri = “ORDER BY libelle”, ce tri est généré par défaut.

Le générateur crée maintenant une clause SQL ORDER BY pour chaque modèle. Le tri par défaut se fait sur une éventuelle colonne libelle. Si elle n’existe pas la deuxième colonne de la table est utilisée, sinon la clé primaire.

Note

Dans le cas où la deuxième colonne d’une table est utilisée comme libellé, si cette colonne est une clé étrangère, alors le tri se fera sur le libellé de la table étrangère.

2.2.3.3. Les actions du tableau¶

2.2.3.3.1. Les actions d’openMairie¶

Remplacer $href[0] par $tab_actions[“corner”][“ajouter”].
Remplacer $href[1] par $tab_actions[“left”][“modifier”].
Remplacer $href[2] par $tab_actions[“left”][“supprimer”].

Pour surcharger l’action ajouter, il faut maintenant surcharger $tab_actions['corner']['ajouter'] et non plus $href[0]:

<?php

$tab_actions['corner']['ajouter'] =
    array('lien' => 'form.php?obj='.$obj.'&amp;action=0',
          'id' => '&amp;advs_id='.$advs_id.'&amp;tricol='.$tricol.'&amp;valide='.$valide.'&amp;retour=tab',
          'lib' => '<span class="om-icon om-icon-16 om-icon-fix add-16" title="'._('Ajouter').'">'._('Ajouter').'</span>',
          'rights' => array('list' => array($obj, $obj.'_ajouter'), 'operator' => 'OR'),
          'ordre' => 10,);

?>

Pour surcharger l’action modifier, il faut maintenant surcharger $tab_actions['left']['modifier'] et non plus $href[1]:

<?php

$tab_actions['left']['modifier'] =
    array('lien' => 'form.php?obj='.$obj.'&amp;action=1'.'&amp;idx=',
          'id' => '&amp;premier='.$premier.'&amp;advs_id='.$advs_id.'&amp;recherche='.$recherche1.'&amp;tricol='.$tricol.'&amp;selectioncol='.$selectioncol.'&amp;valide='.$valide.'&amp;retour=tab',
          'lib' => '<span class="om-icon om-icon-16 om-icon-fix edit-16" title="'._('Modifier').'">'._('Modifier').'</span>',
          'rights' => array('list' => array($obj, $obj.'_modifier'), 'operator' => 'OR'),
          'ordre' => 20,);

?>

Pour surcharger l’action de contenu, il faut maintenant surcharger $tab_actions['content'] et non plus $href[1]:

<?php

 $tab_actions['content'] = $tab_actions['left']['modifier'];

?>

Pour surcharger l’action supprimer, il faut maintenant surcharger $tab_actions['left']['supprimer'] et non plus $href[2]:

<?php

$tab_actions['left']['supprimer'] =
    array('lien' => 'form.php?obj='.$obj.'&amp;action=2&amp;idx=',
          'id' => '&amp;premier='.$premier.'&amp;advs_id='.$advs_id.'&amp;recherche='.$recherche1.'&amp;tricol='.$tricol.'&amp;selectioncol='.$selectioncol.'&amp;valide='.$valide.'&amp;retour=tab',
          'lib' => '<span class="om-icon om-icon-16 om-icon-fix delete-16" title="'._('Supprimer').'">'._('Supprimer').'</span>',
          'rights' => array('list' => array($obj, $obj.'_supprimer'), 'operator' => 'OR'),
          'ordre' => 30,);

?>

2.2.3.3.2. Les actions personnalisées¶

Redéfinir les actions avec la nouvelle manière.

Les actions personnalisées doivent être défini selon la nouvelle manière. Exemple:

<?php

$tab_actions['left']['edition'] = array(
    'lien' => '../pdf/pdfetat.php?obj=om_collectivite&amp;idx=',
    'id' => '',
    'lib' => '<span class="om-icon om-icon-16 om-icon-fix pdf-16" title="'._('Edition').'">'._('Edition').'</span>',
    'ajax' => false,
    'ordre' => 21,
);

?>

2.2.3.3.2.1. Définition de l’action¶

La première clé de $tab_actions permet choisir la position d’affichage:

corner pour les actions en coin;
left pour les actions de gauche.

La seconde clé de $tab_actions permet de définir la nouvelle action. Cette clé doit être différente de: ajouter, consulter, modifier et supprimer.

Les clés lien, id et lib s’utilise de la même manière qu’avant.

2.2.3.3.2.2. Définition du mode d’affichage en sous-tableau¶

La clé ajax permet d’indiquer si l’action doit être affichée en ajax ou non dans les sous-tableaux:

true, l’action utilisera la fonction ajaxIt();
false, l’action n’utilisera pas la fonction ajaxIt().

2.2.3.3.2.3. Définition de l’ordre d’affichage¶

La clé ordre permet de déterminer l’odre d’affichage par rapport aux autres actions.

Chaque action dispose d’une valeur numérique permettant de définir sa place au sein d’une position. L’action numéro 1 s’affichera en premier, l’action numéro 10 s’affichera après les actions de numéro inférieur, etc.

Ordre des actions par défaut d’openMairie:

ajouter à pour ordre 10 dans la position corner;
consulter à pour ordre 10 dans la position left.

Si la position corner est sélectionnée:

9, l’action s’affichera avant l’action ajouter;
11, l’action s’affichera après l’action ajouter.

Si la position left est sélectionnée:

9, l’action s’affichera avant l’action consulter;
11, l’action s’affichera après l’action consulter.

2.2.3.3.2.4. Définition des droits d’affichage¶

La clé rights permet de définir le ou les droits nécessaire à l’utilisateur pour visualiser cette action. Cette clé est optionnelle. Si rights n’existe pas, tous les utilisateurs pourront visualiser cette action s’ils peuvent visualiser le tableau correspondant.

La clé list permet de définir le tableau des droits nécessaire.

La clé operator permet de définir l’opérateur utilisé pour pour vérifier les droits de la liste list:

OR, l’utilisateur doit avoir au moins un droit;
AND, l’utilisateur doit avoir tous les droits.