Voir les traceurs | Bugs | Exporter au format CSV

Date :
08/10/2015 12:18 		Priorité :
3
État :
Closed
Proposé par :
francois raynaud (fraynaud) 		Confié à :
Nobody (None)
Severity :
minor		 Résolution :
none
Version concernée :
none		 Version cible :
none
Résumé :
prefecture.php gestion de la correspondance prefecture dans la base et non dans le code

Description détaillée
Il y a un problème de cohérence dans le traitement préfecture entre le script prefecture.php et la structure de la table type_election qui a été modifié en version 1.15. (ALTER TABLE typeelection ADD typeelection_code varchar(8) NOT NULL AFTER typeelection;)

en ligne 76 de prefecture.php on récupére typeelection_code d'après typeelection

$sql = "SELECT typeelection_code
FROM typeelection
WHERE typeelection='".$election_infos['typeelection']."'";

$typeelection_code = $f->db->getOne($sql);

donc ligne 160

case "REG":
$scrutin = "RG2";

ne peut marcher que si
typeelection_code = "REG" ... a quoi ca sert d avoir 2 champs redondants : un champ typeelection et un champ typeelection_code ?

De deux choses l une :
ou la correspondance se fait dans type_election alors le test "case" est inutile car on recupére le bon code (celui que l utilisateur a paramétré en fonction de la note de la prefecture)
ou c est le programme qui gere la correspondance et il n est pas nécessaire d avoir un champ typeelection_code dans type_election

La première solution est meilleure : une gestion de correspondance dans la base car le logiciel est adaptable sans intervention d'un codeur, l'ajout de ce nouveau champ typeelection_code est une bonne idée si on supprime le test ligne 144 a 171
switch ($typeelection_code){
...
case "REG":
$scrutin = "RG2";
...
}
Message  ↓
Date : 09/10/2015 10:26
Expéditeur : Sofien TIMEZOUAGHT

Bonjour,

En effet, j'ai délibérément laissé le switch dans prefecture.php et garder le même "code" pour le champ typeelection_code, pour ne pas trop déranger les habitudes des utilisateurs.

Mais je partage aussi votre avis sur le fait que ce point peut évoluer.

Cordialement,

--
Sofien TIMEZOUAGHT
atReal - http://www.atreal.fr/

Date : 09/10/2015 08:34
Expéditeur : Florent MICHON

Bonjour,

En réalité l'objectif ici était de pouvoir créer plusieurs types d'élection de même type la même année pour pouvoir gérer notamment dans une même commune une élection qui a lieu sur deux circonscriptions électorales différentes.

Par exemple :

1- premier type d'élection :
typeelection 'LGA'
typeelection_code 'LEG'

2- second type d'élection :
typeelection 'LGB'
typeelection_code 'LEG'

Le champ typeelection_code est ensuite utilisé pour trouver la correspondance avec le code préfecture directement dans le code. Ce n'est pas la solution la plus souple mais elle répond à l'objectif énoncé initialement.

De la documentation sur ce point est disponible ici : http://docs.openmairie.org/projects/openresultat/fr/1.15/manuel_utilisateur/parametrage.html#types-d-election

Voilà pour l'explication de l'existant.

Je partage complètement ton avis sur le fait qu'il est possible d'améliorer ce point en utilisant le champ 'typeelection_code' directement dans l'export préfecture.

--
Florent MICHON
atReal - http://www.atreal.fr/

Pas de documents joints

Champ Ancienne valeur Date Par
Version cibleà déterminer11/06/2021 16:04Florent MICHON
status_idOpen23/10/2019 18:12francois raynaud
close_dateAucun(e)23/10/2019 18:12francois raynaud
details Il y a un problème de cohérence dans le traitement préfecture entre le script prefecture.php et la structure de la table type_election qui a été modifié en version 1.15. (ALTER TABLE typeelection ADD typeelection_code varchar(8) NOT NULL AFTER typeelection;) en ligne 76 de prefecture.php on récupére typeelection_code d'après typeelection $sql = "SELECT typeelection_code FROM typeelection WHERE typeelection='".$election_infos['typeelection']."'"; $typeelection_code = $f->db->getOne($sql); donc ligne 160 case "REG": $scrutin = "RG2"; ne peut marcher que si typeelection_code = "REG" ... a quoi ca sert d avoir 2 champs redondants : un champ typeelection et un champ typeelection_code ? De deux choses l une : ou la correspondance se fait dans type_election alors le test "case" est inutile car on recupére le bon code (celui que l utilisateur a paramétré en fonction de la note de la prefecture) ou c est le programme qui gere la correspondance et il n est pas nécessaire d avoir un champ typeelection_code dans type_election La première solution est meilleure : une gestion de correspondance dans la base car le logiciel est adaptable sans intervention d'un codeur, l'ajout de ce nouveau champ typeelection_code est une bonne idée si on supprime le test ligne 144 a 171 switch ($typeelection_code){ ... case "REG": $scrutin = "RG2"; ... } 08/10/2015 12:23francois raynaud
Version cible1.1508/10/2015 12:23francois raynaud
FEDER Powered By FusionForge Collaborative Development Environment Charte d'utilisation / Nous contacter / Mentions légales Haut de page