Page en cours de rédaction
Ça ne veut pas dire que vous ne pouvez pas participer (au contraire), mais ça veut dire que si vous la lisez aujourd'hui et que vous revenez dans 2 jours (ou 2 ans), elle aura peut-être pas mal changé !
Les enfants de cette page :
/BaseLdap /CrRi2012 /Git /HowToRespoinfo /InventaireLocalServeurs /ServeursBde /WireGuard |
La NoteKfet : Vous trouverez ici les infos relatives à la Note
Quelques pages intéressantes : Certificats de la Note, Application à LDAPS
Sommaire
Projets en cours
Ce qu'on aimerait faire dans un avenir pas trop lointain qui concerne les respo-info du BDE.
Maintenir cette liste le plus à jour possible est pratique pour les passations sans trop de pertes.
Sur la note
NoteKfet/NoteKfet2015/ToDo (y'a possiblement des doublons avec ici)
bugfix/corrections
- Proprifier l'interface de trez (ids en string, noms de fonctions. factorisation ?)
- Rationnaliser l'appli WEI pour qu'elle soit réutilisable tous les ans sans intervention d'un respo-info (ou de manière minime)
Les messages d'erreur pour quand une transaction est passée en valide=False parce qu'il n'y avait pas les droits forced/overforced ne s'affichent plus !
- Il faut aussi afficher les warnings quand une transaction forced/overforced a été faite
Euh, "chez moi ça marche"™, à vérifier sur kfet -- Wiki20-100 2016-03-14 07:17:15
- Il faut aussi afficher les warnings quand une transaction forced/overforced a été faite
Sur mon écran (1024x600), avec tous les droits, il y a trop d'onglets, donc ils devraient collapser en un symbole ≡, mais en fait non, il y a une zone intermédiaire (pile quand je mets mon navigateur en fullscreen) dans laquelle le pseudo et le lien de déco s'affichent en dessous des onglets, mais le cadre principal ne descend pas, donc le haut de la page est caché en dessous.
- Apparemment Hamza l'a réglé sur la branche bootstrap3
Décider quoi faire pour utils/note.nginx et son .example (qui gitter, qui ignorer), mais ça peut pas rester comme ça
- en profiter pour voir tous les fichiers de conf et comment les versionner (pour pas perdre l'historique) tout en pouvant modifier selon la machine et en ne publiant pas de données confidentielles (mots de passes, clés de certifs,…)
Dans update_compte, Django envoie systématiquement au backend le champs "sexe". Normalement il ne doit envoyer que ce qui a changé.
Quand on tente de faire consommer un vieux (quand on le cherche par #idbde ou quand on active le kludge permettant de les afficher), la transaction n'est pas du tout insérée dans la table, et la ligne de log ne contient pas les infos de la transaction qui a échoué. Proposition de fix : afficher sur la ligne de log (pas la table, la ligne, celle qui s'écrit dans le fichier) toutes les infos pour qu'on puisse refaire la transaction plus tard si besoin.
Quand on a les droits transactions_admin, comme c'est le premier test qui est fait, il est affiché dans les logs (table et fichier) que c'est normal used. Il faudrait changer complètement l'ordre des tests pour voir si on a effectivement besoin de transactions_admin et l'écrire si il a été nécessaire.
dev
- L'interface trésorerie.
- L'interface d'entrée aux pots.
- Penser à avoir la feature "mettre en évidence les vieux" pour le pot vieux.
Envoyer un mail pour avertir qu'une activité est en attente de validation. (À peaufiner par PapyCo)
Faire en sorte que ce tableau soit rempli de manière automatique avec les données à jour.
- La vérification que les adresses e-mail sont valides.
À ce propos, actuellement, un compte ne peut pas modifier sa propre adresse mail sans… adherents_strong ?
- Mettre en évidence le 1er bouton de chaque lettre de l'alphabet (en mettant la première lettre du label d'une autre couleur ?).
- Mettre en évidence (en surbrillance jaune) le terme qu'on recherche sur la recherche de compte.
- Cette modif a été faite, elle doit traîner quelque part dans une branche ou un stash, il faudrait la proprifier et la commiter
Peut-être adapter la durée du countdown sur une recherche de compte parce qu'il est sans doute un peu court et cherche souvent inutilement beaucoup de comptes avant qu'on ait fini de taper. (50 -> 100 ?) -> tester pour voir ce qui est bien à l'usage…
Fusionner un_compte.html et modifier_compte.html.
puis factoriser tout ce boxon (parce que ça se répète quand même vachement) en utilisant PRIORITY_FIELDS et NEEDED_ACL pour savoir dans quel ordre les mettre et lesquels cacher.
- Faire un common_config importé dans django et le backend ?
Genre pour les droits. Et des trucs comme le mapping droits -> pages.
- Et puis les champs pas modifiables de certains formulaires en fonction des droits.
- Et utile peut-être aussi pour l'inclure dans une lib…
- Ajouter un masque de droits "droits puissants" (ou whatever name), qui ait tous les droits (pour laisser son compte à quelqu'un quand on est puissant pour un cas particulier) mais qui vire les trucs vraiment graves (du genre overforced, transactions_admin, peut-être adherents_strong,…).
- Penser une hiérarchie de droits, un masque pour chaque niveau.
- Implémenter pour de vrai un timeout de droits hiérarchisé avec les masques dont on parle juste au-dessus : plus le temps passe, plus tu descends dans les niveaux de droits si tu ne les utilises pas.
settings.py : lire la clé django dans un fichier à côté (non gitté), créer automatiquement ce fichier s'il n'existe pas.
- Factoriser les codes d'inscription et de réadhésion. Et en faisant ça correctement pour que l'appli WEI aussi fasse la même chose (et en appelant le même code).
- Factoriser crédit/retrait.
À propos de factoriser, form_contents.html a l'air cool, on pourrait démocratiser PRIORITY_FIELDS et un autre paramètre qui contiendrait le mapping droit -> champ à "griser" si t'as pas le droit.
- Pour la réadhésion, pré-remplir le champ section avec section++ :
On parse le début de la section, si on trouve un nombre suivi d'autre chose, on fait +1 sur le nombre et on garde le reste, et on propose ça.
Si on trouve pas de nombre, on laisse vide pour forcer à fournir une section (ou alors on la met en pré-remplissage qui disparaît quand on clique dessus (placeholder)).
- Mettre un vrai message d'erreur quand la section n'est pas fournie.
- Rajouter un bouton en bas de la page conso pour afficher plus de transactions, dans une certaine limite (à mettre dans la table de configurations) (la fonction backend existe déjà).
Penser à nettoyer la table des mails envoyés dans la BDD nkmails. Le scripter/croner.
- Mailer les trésoriers en cas d'opération d'un montant supérieur à 1000 € (montant à mettre dans la table de configurations).
Créer un droit ouvrir qui fait apparaître un bouton sur la page d'Index "ouvrir la kfet" et qui changerait une valeur quelque part indiquant que la kfet est ouverte. On peut aussi faire une détection de consos notées (en vérifiant que c'est depuis l'ordi kfet et pendant des heures d'ouverture autorisée). Cette valeur pourrait être utilisée pour afficher si la kfet est ouverte sur la note elle-même, et sur #bde, et à d'autres endroits si on veut.
- Pour les préinscriptions, rajouter un champ "date" qui correspondrait à la date de la préinscription.
- Pour les préinscriptions, rajouter un champ "validé par le bureau". Il ne serait pas nécessaire pour valider l'inscription, mais utile pour ceux dont l'adhésion doit être validée par le bureau pour enregistrer le fait qu'il a été accepté entre le moment où le bureau a dit oui et le moment où il vient effectivement payer son adhésion.
- Envisager de lui envoyer automatiquement un mail quand on coche la case comme quoi le bureau a dit oui ?
- Déhardcoder les conditions d'invitation à une activité. Le template affiche les données (20h, 3 invités/personne, 5 invitations/an) en dur, il faudrait faire la demande au serveur pour que ça se modifie tout seul si un jour on les change.
Des scripts
Remettre alerte_conso en fonction.
- Lui apprendre ce que sont les vacances.
- Détecter la non-tenue d'une perm/une kfet fermée par absence totale de conso et donc ne pas être surpris qu'il y a pas eu de bouffe notée.
Les serveurs
- On cherche en ce moment à virtualiser au maximum les serveurs au Crans pour arrêter de gérer le matériel. Il reste encore :
bde3 qui, modulo une acceptation de la Monopo[list] à ce qu'on nuke le Wordpress en le remplaçant par une redirection vers la page AccueilAdmis, pourra rejoindre ses camarades Karkasses
bde-test qui est à remplacer par son homologue virtualisé
Je me sens aussi responsable de zavoyarde, serveur de la Mèd, dont je voudrais mettre l'interface de gestion des BDs sur la page perso zamok de la Mèd, pour pouvoir le bazarder, dans le cadre du projet du paragraphe suivant.
Rationnaliser l'enregistrement des machines BDE au Crans. Le BDE a deux clubs enregistrés au Crans (cid=1 et cid=49). Ceci a été mis en place le jour où un upload massif a été fait depuis kfet par erreur, donc le BDE a été blacklisté et donc la Note Kfet et le site des admissibles n'étaient plus accessibles depuis l'extérieur. L'idée est donc que le club Serveurs-bde (cid=49) possède les machines qui doivent absolument rester joignables depuis l'extérieur (la note, le site des admissibles si on le garde), et le club Bureau des Élèves (cid=1) tout le reste.
- Il faudrait donc faire du tri dans tout ce boxon parce qu'il y a plein de trucs qui sont enregistrés mais n'existent plus, la moitié des caméras enregistrées de chaque côté, et la sémantique plus du tout respectée (notez qu'elle est dans la remarque du club).
Les sites
Demander à la DSI de faire en sorte que bde.ens-cachan.fr soit un CNAME vers bde.crans.org comme ça on pourra gérer le DNS comme on veut côté Crans et non pas leur demander à chaque fois.
Bazarder le Wordpress pas maintenu et qui de toutes façons demande déjà aux gens d'aller sur AccueilAdmis pour remplacer vers une redirection directement. Éventuellement embellir la page cible.
Documenter http://clubs.ens-cachan.fr/bde/wordpress/ sinon il ne passera pas les passations.
- éventuellement le passer directement à la racine après avoir compressé dans un coin la page de l'adrénalist pour la mémoire