elections

Elections

Fonctionnalités

• Visualisation des résultats sous forme de cartographie, flux d'actualité, ou résultats détaillés par circonscription ou ville
• Saisie des résultats par bureau de vote pour les personnes ayant le droit de saisie et administrateurs
• Gestion des élections :
  • création du modèle d'une élection (découpage en circonscription, ville puis bureau)
  • gestion des listes de candidats par circonscription
  • gestion des tendances politiques
  • plannification des tours
  • validation des résultats
  • identification des candidats pouvant poser problème (cumul de mandat) et possibilité de supprimer les candidats refusant leur élection pour prendre automatiquement le suivant.

Une documentation utilisateur est disponible dans l'application après connexion dans le menu "Aide"

Démarrage pour tests / dev

Identifiants de démonstration

Trois comptes de démonstrations permettent de tester l'application avec trois profils différents : admin (rôle d'administrateur), capturer (rôle de saisisseur), et visualizer (rôle de visualiseur). Ces trois comptes ont pour mot de passe password

Avec VS Code

Il est nécessaire d'avoir un environnement de développement GO installé et opérationnel sur le poste.

Télécharger le dépot

git clone https://forge.grandlyon.com/gestion-des-assemblees/elections.git

Ouvrir le dépôt avec VS Code puis dans l'onglet Debug, démarrer le projet avec Debug elections with Mock OAuth2

La démo est accessible avec l'url https://elections.127.0.0.1.nip.io:1443

Avec Docker

Installer sur le poste Docker et docker-compose

Télécharger le dépot

git clone https://forge.grandlyon.com/gestion-des-assemblees/elections.git
cd elections

Dans le fichier docker-compose.yml décommenter la ligne command: -debug (ATTENTION : cette ligne doit être commentée lors d'un passage en prod et ne sert que pour tester ou débuger l'application)

docker-compose up -d

La démo est accessible avec l'url https://elections.127.0.0.1.nip.io

Architecture

Arborescence fichier

• ./data contient les bases de données locales sqlite, users.db pour les utilisateurs et test.db pour le modèle de donnée
• ./dev-certificates contient les fichiers nécessaires pour servir l'application en HTTPS durant le développement.
• ./internal contient les paquets nécessaires au développement de l'application
  • ./auth contient la gestion des utilisateurs et des droits sur l'application
  • ./mocks permet de mocker l'API d'authentification pour passer les tests
  • ./models permet de définir le modèle de données et les API qui seront servies par le back-end
  • ./rootmux contient le fichier rootmux.go qui permet de servir les APIs, de gérer l'authentification, de servir le site web et la gestion des cookies utilisateurs. Le répertoire contient également tous les tests d'intégration sur les APIs.
• ./miscellaneous/keycloack contient un environnement Keycloack qui peut être utilisé pour déployer un environnement OAuth2
• ./web est le répertoire où est stocké l'application front-end en JavaScript natif et avec le framework CSS Bulma publié par le serveur back-end.

Le répertoire ./web/assets/maps contient les cartes qui peuvent être utilisé dans l'application. Pour en ajouter de nouvelles en production copier les fichiers désirés dans ce répertoire.

Avec docker-compose : docker cp <fichier-à-importer> :/app/web/assets/maps/<fichier-à-importer>

Utilisateurs et droits

Utilisateurs techniques Les utilisateurs techniques permettent de s'authentifier à l'application et d'accéder aux API en fonction du rôle de l'utilisateur qui définit alors ses droits. La source de création et d'authentification des utilisateurs technique est double. Elle peut soit provenir directement de la base de donnée locale d'utilisateurs de l'application (./data/users.db) ou d'un fournisseur d'identité avec le protocole OAuth2 (configuré dans le fichier .env).

Dans le cas d'une connexion avec OAuth2, l'utilisateur est créé dans la base locale d'utilisateurs avec son identifiant OAuth2 qui permet de faire le lien avec l'utilisateur technique. Dans le cas d'une connexion avec OAuth2, l'utilisateur doit obligatoirement faire parti d'un groupe applicatif autorisé (cf variable d'environnement ADMIN_GROUP et VISUALIZER_GROUP). Un rôle différent est attribué automatiquement à l'utilisateur en fonction de son groupe.

ATTENTION : le rôle "ADMIN" est obligatoire dans l'application car permet de gérer les utilisateurs et leurs droits. Sans celui-ci est sans utilisateurs ayant ce rôle dans la base, il est impossible de gérer les utilisateurs !

Utilisateurs applicatif Les utilisateurs applicatifs sont créés dans la base locale de données (./data/test.db) avec l'identifiant de l'utilisateur technique qui permet de faire la jointure entre un utilisateur applicatif et un utilisateur technique.

Les utilisateurs techniques sont :

• Les administrateurs admin qui créent le modèle de donnée des élections, valident les votes et crée les utilisateurs en leur affectant des droits.
• Les saisisseurs capturer qui peuvent saisir les résultats des bureaux de votes qui leurs sont affectés.
• Les visualiseurs visualizer qui peuvent simplement consulter les résultats.

Tests

Tests unitaires Les tests unitaires sont définis dans le répertoire de chaque paquet (ex : auth_test.go dans le package auth)

Tests d'intégration Les tests d'intégration sont dans le répertoire ./rootmux. Les tests métiers (ex : marqué un bureau de vote comme complété lorsque tous les votes ont étaient saisis pour ce bureau) sont définis dans le fichier rootmux_test.go. Les tests concernant les droits et les réponses attendues par utilisateur (ex : un saisisseur ne peut saisir les votes que des bureaux qui lui sont rattachés et pas aux autres) sont écrits dans des fichiers différent par type de droits différent (ex : capturer_test.go pour tester les droits des saisisseurs).

Ajouter un type d'élection

Pour ajouter un type d'élection il faut ajouter le code qui permet de déterminer les élus.

Pour ce faire, dans le fichier web/services/calculate-election-generic.js ajouter une fonction qui permet de calculer les élus pour le nouveaux mode de scrutin (par exemple : getElectedsMyNewBallotType). Modifier le switch case de la fonction getElecteds pour prendre en compte le nouveau scrutin en appelant la fonction que vous venez de créer.

switch (election.BallotType) {
  case "local-counsil-direct":
    return this.getElectedsLocalCounsilDirect(area);
  case "my-new-ballot-type":
    return this.getElectedsMyNewBallotType(area);
}

Puis pour que ce mode de scrutin puisse être pris en compte pour une élection, modifier le menu de sélection du type de scrutin d'une élection pour ajouter une nouvelle option dans le fichier web/components/management/election.js

<div class="control select">
  <select name="ballot-type" id="election-modal-ballot-type">
    <option value="local-counsil-direct"
      >Conseil communautaire au suffrage direct</option
    >
    <option value="my-new-ballot-type">Mon nouveau type de scrutin</option>
  </select>
</div>

Design

Pour modifier le design de l'application sans en altérer le code source, récupérer le répertoire miscellaneous/bulma en local.

Modifier les règles SCSS pour les adapter à vos besoins. (doc Bulma)

Dans le répertoire miscellaneous/bulma exécuter la commande npm run build-perso (nécessite npm d'installer sur le poste) pour construire le fichier minifié CSS prenant en compte la personnalisation.

Placer ensuite ce fichier à côté du fichier docker-compose.yml et décommenter la ligne appropriée dans le fichier docker-compose.yml puis exécuter la commande docker-compose up -d pour lancer le conteneur.

Contribution

Un bug découvert ? Une demande d'amélioration ? Une contribution à la documentation ?

Utilisé le système d'issue pour expliquer votre découverte ou votre poposition.

Vous voulez contribuez directement au code ?

Créer une issue pour expliquer votre contribution, créer une branche à partir de cette issue, développer votre fonctionnalité sur la branche et faite une merge request.