Réunion YesWiki Association pour les prochains développements


mercredi 27 octobre 2021 9h-10h15

Prise de notes en direct : https://pad.coop.tools/p/yeswiki-dev
copié ici le 27/20/21 11:33 à garder en lien avec Chantiers à finir et Chantiers à Ouvrir


RÉUNION YESWIKI ASSOC 27/10/21 9H-10H15
présents : Romain, Vincent, Jeremy, mélanie, gatien
point compta 5000€ de treso non affecté

Nous avons balayé les différents points d'attention proposés par Jérémy. La plupart des points est importante (pas tous) mais ils tous des degrés d'urgence différents (le degré d'urgence étant déterminé par le fait que ce soit bloquant pour développer d'autres fonctionnalités ou sinon parce que c'est demandé de nombreuses fois par les utilisateurs). Nous avons donc privilégié le financement des points les plus urgents uniquement. Les points qui sont pour le moment uniquement embêtant pour quelques sites sont mis de côté en invitant les sites en question à les financer directement.

Décisions
  • ce que l'association YesWiki financerait :
    • 1. forcer l'usage de mots de passe plus robustes (50 €)
    • 2. empêcher d'avoir deux comptes YesWiki avec la même adresse e-mail (50 €)
    • 3. refactor / récriture de la partie de gestion des utilisateurs (User.class) (300 €)
    • 4. sauvegarde des mots de passe en SHA-1 (200 €)
    • 7. amélioration de {{userstable}} (300 €)
    • 8. ajouter un utilisateur dans un groupe avec le champ utilisateur_wikini (si pas financé par habitat participatif)
    • 13. réparer le template calendrier.tpl.html (600 €)
    • 6. mettre en place les fichiers de traduction (300 €) (prévenir sylvain et sarah)
    • Total : 1800€ (sans le point 8.)
  • ce qu'il faut voir si Habitat participatif le financerait (car Jérémy est déjà en discussion avec eux pour ces sujets et qu'ils utilisent ces fonctions) :
    • 8. ajouter un utilisateur dans un groupe avec le champ utilisateur_wikini (100 €)
    • 9. améliorer/réparer le tempalte tableau pour afficher les fiches bazar et permettre les suppresions par groupe ()
    • 10. vérification des champs bazar requis même avec des onglets
  • ce que l'association YesWiki financerait plus tard à court terme :
    • 5.mettre en place un système de jeton d'authentification dans les cookies et retirer le mot de passe des cookies
    • 15. implémenter les nouveaux thèmes de margot (Gatien voit avec qui)
    • ensuite le 14 (backup par user dès que le reste est réalisé)
  • pas encore pris en compte :
    • 11. réparer la détection d'un champ texte long html requis mais vide

Todo
  • 1. prévoir une meilleure gestion de la modal user => ne pas devoir repasser par roue crantée si erreur de mot de passe
  • 2. rendre visible dans la roue crantée le fait qu'on est connecté
  • 3. faire des spécifications pour pouvoir configurer les couleurs dans les calendriers et les implémenter
  • 4. ajouter un bouton d'ajout de fichiers ou d'image dans le champ userfield (actuellement ça n'est pas possible)

Pour info
non pas de cookies couverts par le RGPD
mais y a bien un cookie qui conserve longin/mot de passe (voir la page de la CNIL https://www.cnil.fr/fr/cookies-et-traceurs-que-dit-la-loi)
info à repartager dans le coucou

contexte
  • pour avancer sur la roadmap à venir : y a des choses à faire avant ou sinon ça retarde
  • huntr.dev nous sollicite souvent pour dire qu'ils ont trouvé des "mini bugs"

  • 1) gestion des mots de passe
    • * ajout d'une méthode pour vérifier la complexité du mot de passe et afficher un message adapté (dans /tools/security/controllers/SecurityController .php) à utiliser lors de l'installation et à chaque modification de mot de passe 1h/50€
      • * ok pour la complexité => mais bien faire gaffe à l'UX pour pas perturber les gens
      • * https://checklists.opquast.com/fr/assurance-qualite-web/ faire une recherche sur mot de passe
        • * s'en inspirer (aussi pour les dévs qui gravitent autour de yeswiki et pas seulement pour yeswiki)
  • 2) ajout de la vérification de non-existence de l'adresse e-mail avant de valider le changement d'e-mail dans ParametresUtilisateurs 1/50€
    • * ok
  • 3) refactor de la partie création d'utilisateur/gestion des mots de passe (remplacer User.class.php en services) 6h/300 €
    • * finançable par le commun sinon sans doute jamais
  • 4) sauvegarde des mots de passe en SHA1 au lieu de md5 (2h/100 €) : hyper important
    • * nécessaire avant de faire les backups par user
  • 5) mise en place d'un système de jeton dans les cookies pour éviter d'y mettre le mot de passe en md5 (ou SHA1) 1j/400 € (mais il risque y avoir du temps de concertation à prévoir entre nous aussi pour les spécifications)
    • * actuellement on sauvegarde : nom user ou mot de passe en md5 (mais trop facile)
    • * shA1 : permet déjà de sécuriser un peu
    • * idéal passer par des jetons
    • * moindre degré d'urgence mais à prévoir quand même
  • 6) création de tous les fichiers de traduction en français pour le PHP et le javascript : 6h (300 €)
    • * traduction n'est pas dans la presta mais mise en place de la fonction
  • 7) amélioration de usertable : 6h (300 €) (permettre la suppression groupée de comptes spam ou l'ajout groupé de comptes dans un groupe)
    • * permettre l'ajout d'un user direct via le tableau user table
    • * créer un utilisateur depuis usertable pour les admins
  • 8) UserField (utilisateur_wikini) via habitat participatif ??? à vérifier
    • * importance de pouvoir placer un user direct dans un groupe lors de sa création via un formulaire
  • 9) possibilité d'utiliser le template tableau pour afficher les fiches bazar (avec deux colonnes à a fin / edit / delete)
    • * postpose ou hab participatif qui finance
  • 10) vérification de champs requis dans les formulaires bazar : 4h (200 €)
    • * voir avec ludo habitat participatif
    • * réécriture/correction de la fonction js de validation des champs requis pour la rendre compatible des affichages avec onglets.
  • 11) correction de la détection du champ vide summernote textelong mode html
    • * champ texte long vides passent quand même s'ils sont vides (mais uniquement quand ils sont en mode html)
    • * en discutant autre sujet bloquant pour certains dans les textes long : pouvoir joindre un fichier dans un champ long wiki
  • 12) vérifications et tests que les autres champs sont bien détectés comme vides et que le message d'erreur est affiché s'ils sont requis
    • * mis de côté car chiant : à prévoir
    • * Florian : Et pour la validation des champs bazar requis , idéalement il faudrait des méthodes génériques pour les fields ->clientSideCheckField() qui rajoute le js coté client pour la validation du formulaire et ->serverSideCheckField() pour les opérations coté serveur , a mon avis ce serait plus modulaire que l'approche un fichier bazar.js avec tous les controles dedans.
  • 13) Pour le champ calendrier, nous avons le souci qu'il n'est pas compatible avec les facettes et le changement de mois. Pour qu'il le devienne, il faudrait le passer en dynamic et en plus ça accélèrera le chargement s'il y a beaucoup de données mais effectivement, pour le premier besoin pour l'affichage jour et semaine, une simple mise à jour de la librairie pourrait suffire.
    • * voir avec les users et faire les spec
    • * pour ensuite faire un chiffrage derrière
    • * estimation pour debug uniquement 1j-1,5j (400/600€)
    • * => https://fullcalendar.io/docs/vue
  • 14) backup de wiki directement par les users : les soucis de migration coop.tools poussent à ça...
    • * il faut d'abord sécuriser les mots de passe AVANT mais c'est ok, ce sera financé
    • * chantier benevole qui avance à petit pas
    • * en mode presta ce serait 2 J
  • 15) thèmes new yeswiki : sebastian pourrait peut-être @gatien peut lui demander
    • * Gatien voit avec flo et sebastian dès que possible