Les modèles sont faits à l'arrache

lstephan commented

2020-12-19 00:30:51 +01:00

(Migrated from git.eleves.ens.fr)

Quelques problèmes pêle-mêle :

si on veut supporter d'autres modes de vote (i.e. condorcet), il faut quasiment tout réécrire
la gestion des users est réduite au minimum (quid des créations d'utilisateurs pour une élection ?)
même si on fait confiance aux sysadmins, il faut peut être un minimum de mesures de sécurité

Quelques problèmes pêle-mêle : - si on veut supporter d'autres modes de vote (i.e. condorcet), il faut quasiment tout réécrire - la gestion des users est réduite au minimum (quid des créations d'utilisateurs pour une élection ?) - même si on fait confiance aux sysadmins, il faut peut être un *minimum* de mesures de sécurité

thubrecht commented

2020-12-20 14:39:38 +01:00

(Migrated from git.eleves.ens.fr)

Pour d'autres types de votes, je pensais faire des apps séparées, parce que un vote condorcet c'est pas mal différent d'une élection classique par assentiment

thubrecht commented

2020-12-20 14:49:16 +01:00

(Migrated from git.eleves.ens.fr)

Sur la question des users, on a deux cas différents, la DG qui utilise CAS et le COF/BDS qui ont des listes d'électeurs et une connexion par identifiant + mdp spécifiques pour l'élection. Pour les élections COF/BDS, on peut créer des users avec un login du type {election.short_name}__{login}, et pour voter à cette élection on fait avec les identifiants reçus par mail, alors que pour les élections ouvertes à tou·te·s on utilise le CAS, dans ce cas on pourrait utiliser AuthENS pour gérer les connexions

Sur la question des users, on a deux cas différents, la DG qui utilise CAS et le COF/BDS qui ont des listes d'électeurs et une connexion par identifiant + mdp spécifiques pour l'élection. Pour les élections COF/BDS, on peut créer des users avec un login du type `{election.short_name}__{login}`, et pour voter à cette élection on fait avec les identifiants reçus par mail, alors que pour les élections ouvertes à tou·te·s on utilise le CAS, dans ce cas on pourrait utiliser AuthENS pour gérer les connexions

lstephan commented

2020-12-20 16:35:42 +01:00

(Migrated from git.eleves.ens.fr)

Il reste quand même pas mal de logique commune ; la méthode de dépouillement se fait au niveau de chaque question, donc pourquoi artificiellement empêcher de mêler des questions condorcet ou non ?

lstephan commented

2020-12-20 16:38:22 +01:00

(Migrated from git.eleves.ens.fr)

J'avais comme idée de base de changer DEFAULT_USER_MODEL avec un User custom avec un champ Election, et de faire un backend d'auth custom qui prend aussi l'élection en argument... Ça me paraissait le plus propre :slight_smile:

J'avais comme idée de base de changer `DEFAULT_USER_MODEL` avec un `User` custom avec un champ `Election`, et de faire un backend d'auth custom qui prend aussi l'élection en argument... Ça me paraissait le plus propre :slight_smile:

thubrecht commented

2020-12-23 21:56:47 +01:00

(Migrated from git.eleves.ens.fr)

En effet, je pense que ce qu'on pourrait faire c'est rajouter un champ dans Question pour savoir de quel type de question il s'agit (condorcet, assentiment, ...), ensuite on peut gérer le dépouillement dans le modèle Question. Pour condorcet, il suffirait de rajouter un champ rang dans le modèle des choix et les gens rempliraient les rangs qu'ils affectent à chaque choix

En effet, je pense que ce qu'on pourrait faire c'est rajouter un champ dans `Question` pour savoir de quel type de question il s'agit (condorcet, assentiment, ...), ensuite on peut gérer le dépouillement dans le modèle `Question`. Pour condorcet, il suffirait de rajouter un champ `rang` dans le modèle des choix et les gens rempliraient les rangs qu'ils affectent à chaque choix

Les modèles sont faits à l'arrache #1