Documentation du dispositif provisoire de centralisation en ligne en MySQL des données relatives aux candidats et de communication de documents en page Web, en CSV ou en OpenOffice.org

Données des candidats

Dans ce système provisoire de niveau 2, les données sont en ligne dans une base de données MySQL dans mon domaine personnel.

Outils utilisés

OpenOffice.org Base

Il y a une connexion « native » OOo Base avec MySQL. Je l'ai essayée et ça fonctionne, mais la connexion se coupe très rapidement et c'est donc inutilisable en pratique, tant que ce problème n'est pas résolu.

phpMyAdmin

phpMyAdmin admet des importations en CSV. J'ai pu ainsi préparer en les améliorant mes données des années antérieures en OOo et les importer dans la table perso.

phpMyAdmin propose divers format d'exportation de tables, dont CSV et OOo Calc. Il est donc possible d'utiliser MySQL comme base de données de départ et, pour ce qui ne peut encore être fait automatiquement, de travailler en OOo selon les méthodes inspirées de 2009 telles qu'elles sont formalisées dans Documentation du dispositif provisoire de centralisation en ligne des données relatives aux candidats et de communication de documents. Il est donc possible de travailler d'emblée dans ce système en ligne et de l'automatiser pogressivement.

Publier la structure à partir de phpMyAdmin par Thunderbird

phpMyAdmin propose un format imprimable de la structure d'une table, mais la source HTML en est invisble parce que la page de phpMyAdmin est en frames. Firebug permet de remonter au contenu des frames, mais ici c'est du JavaScript qui exécute des requêtes MySQL. Ce qu'on peut faire, c'est copier le contenu de la page imprimable et le coller dans un nouveau message HTML de Thunderbird. Sélectionner tout (Ctrl+A) et Insérer/HTML… pour voir la source. Sélectionner tout et copier (Ctrl+A, Ctrl+C) et coller dans Bluefish. Le résultat est parfait.

Table perso des données de base

Dans la table perso, je retiens les champs ID, dateimport, provparti, prenombul, nombul, masculin, prenoms, nom, paysnat, numnat, datenaiss, profession, beroep, ruedomi, numdomi, btedomi, cpdomi, commdomi, email, phone, gsm, plus, professionalt, beroepalt, profil, profiel. Détails sur ces champs, voir annexe 1.

Je découvre parce que l'importation d'un CSV bloque à 127 que TINYINT(3) ne va pas jusque 999, mais de − 127 à 127, ou de 1 à 255 non signé. Pour nos besoins, il faut au moins SMALLINT(3).

Majuscules et minuscules

Majuscules seulement aux noms propres des candidats, des localités et des rues. Donc minuscule aux professions et aux mots « rue », « avenue »…

Format du genre

Je découvre que dans MySQL un champ BOOLEAN est un TINYINT (1). Le masculin est vrai (= 1) pour les hommes et faux (= 0) pour les femmes. Sera traduit dans une vue dans les F ou M du Pbis. Peut être traduit en homme, femme, man, vrouw, monsieur, madame, mevrouw, mijnheer dans d'autres contextes.

Pays de nationalité

Les élections fédérales, régionales et communales imposent des conditions de nationalité différente. J’indique ici le code pays en ISO 3166-1 alpha-2 modifié européen (EL pour la Grèce et UK pour le Royaume-Uni).

Attention que ce champ n’a rien à voir ni avec l’adresse, ni avec le pays d’origine.

Format du numéro national

Le Pbis demande une chaîne de onze chiffres sans blancs ni ponctuations et c’est sur cette forme aussi que j’ai écrit ma formule de contrôle. Il n’y a cependant pas intérêt à en faire un entier puisque les calculs de contrôle ne portent que sur des sous-chaînes.

J’adopte donc ce format dans la table. Une requête de nettoyage est donnée en annexe 2.

Format de dates

MySQL attend en importation le format AAAA-MM-JJ, comme 1943-04-28 pour ma naissance. C’est dans les vues ou requêtes qu’il faudra éventuellement en changer, comme pour le Pbis.

Format des numéros de téléphone

Il est préférable de séparer des groupes de chiffres, surtout le préfixe, pour la lisibilité. On sépare seulement par des blancs. Il est difficile de positionner automatiquement les blancs de manière correcte, il faut les ajouter à la main, mais on peut remplacer automatiquement d’autres ponctuations indésirées comme les barres et les points. Une requête de nettoyage est donnée en annexe 3.

Données de profession et de profil

Le champ profession est destiné à l’acte de présentation. Dans des listes destinées à la presse, on utilise parfois des professions alternatives plus valorisantes, comme délégué ou président du PTB au lieu d’ouvrier ou d’employé (exemple, Solidaire n^o 23, p. 12 et 13, http://www.ptb.be/nieuws/artikel/les-listes-choisissez-le-ptb-partout-en-belgique.html) ; c’est le champ professionalt. Dans certaines circonstances, on met dans Solidaire une description d’une phrase (exemple, « 80 syndicalistes sur les listes PTB+ », n^o 22, p. 10 et 11, http://www.pvda.be/nieuws/artikel/vakbondsmilitanten-op-de-lijsten-van-pvda.html) ; c’est le champ profil. On ne met pas dans profil un article complet, même court (exemple, Solidaire n^o 23, p. 10 et 11) ; ça c’est à convenir directement avec la rédaction. On peut avoir besoin de ça dans les deux langues, d'où les beroep, altberoep et profiel.

Adresse de contact alternative

Non repris. C’est intéressant, mais assez minoritaire. Je propose que les provinces tirent leur plan avec ça. C’est surtout elles qui ont un éventuel problème de contact. Par contre, je maintiens bien sûr l’e-mail et les numéros de téléphone. J'ai une hésitation sur un numéro de téléphone de travail. Il me semble que je ne vais pas téléphoner au travail à quelqu'un que je ne connais pas bien.

Absence prévue

Non repris. Rare et circonstanciel. Je propose que les provinces tirent leur plan avec ça. C’est elles qui ont un problème de contact pour les signatures, etc.

Publication des données de base en html

Communication des données par les provinces

Elles consultent les données et m’envoient les modifications ou additions. Leur proposer un modèle de tableur avec les colonnes voulues.

Autres vues

Des tas de vues partielles peuvent se révéler intéressantes. Pour la centralisation des données, les provinces doivent voir ce qui manque, donc elles doivent tout voir et pour cela la consultation de perso est suffisante et moins que ça ne suffirait pas. On pourrait cependant imaginer des vues par province.

Il serait intéressant de fournir une vue par personne aussi, pour envoyer à la personne et lui demander de vérifier.

Constitution des listes

Tables de composition

Format effectif/suppléant

Plutôt qu’un champ booléen comme le genre, je choisis de mettre en texte directement les E et S demandés par le Pbis. Sera traduit dans certaines publications.

Déposants des listes et témoins

Les déposants et les témoins sont mentionnés dans l'acte. On doit donc les avoir aussi de manière centrale. Je me propose d'ajouter des lignes Y1, Y2, Y3 pour les déposants et Z1, Z2 pour les témoins.

Communication des listes par les provinces

Elles consultent les données et m’envoient les modifications ou additions. Leur proposer un modèle de tableur

Elles ont une confirmation que j’ai bien reçu la liste et que les ID sont exacts et bien placés en consultant les divers documents de sortie ci-dessous.

Actes et autres documents

Listes à consulter

Liste de travail

Vue de la liste à usage plutôt interne, de travail, pour examiner une liste provisoire ou incomplète et en discuter, pour organiser les signatures, et cetera. Je nomme ces vues en élection-trav-Circonscription, par exemple fedtravLux pour la circonscription du Luxembourg aux éléctions fédérales.

On y met la position, le prénom et le nom usuel. J'ajoute le Plus pour juger de l'ouverture de la liste, le genre pour voir si on a bien respecté l'équilibre homme/femme, la profession pour voir si on a un bon équilibre ouvriers/employés, l'âge pour voir si on a une pyramide des âges raisonnable, les e-mail, téléphone et gsm

Documents à imprimer

Annexes

Annexe 1, structure de la table `perso`

More…

Annexe 2, structure de la table `fedcompLux`