Help

Feuille de route

Quand est-ce que la prochaine version sera disponible ? Quand elle sera prête, merci de ne pas demander 😅

Les bugs sont corrigés et publiés dans le tag stable, les nouvelles fonctionnalités sont ajoutées dans la version de développement (branche dev) qui sera publiée quand les objectif de cette version seront atteints (voir plus bas).

Une liste plus précise de fonctionnalités demandées est également listée dans les tickets (mais on n'a pas forcément le temps de créer un ticket pour chaque fonctionnalité !). j

État actuel des fonctionnalités

Fonctionnalité Statut État Remarques
Membres Implémenté Satisfaisant
Comptabilité Implémenté Satisfaisant Quelques fonctionnalités manquantes
Activités et cotisations Implémenté À revoir Refonte prévue
Documents / fichiers Implémenté Satisfaisant Complet. Gestionnaire de fichiers web serait mieux en JS.
Site web Implémenté Satisfaisant Manque édition WYSIWYG
Mailing Implémenté En cours de refonte (1.4) Manque suivi/archivage des mails envoyés, pièces jointes, rédaction WYSIWYG
Documentation Plutôt bonne En cours À mettre mieux en évidence dans le logiciel directement
Tests unitaires Inexistants ou presque À écrire…
Tests fonctionnels En cours Hannaeko et Lesanges

Prochaines versions

Version 1.4.0 (à faire)

  • Ajout de la possibilité de définir des règles d'import des fichiers bancaires, permettant de simplifier l'import bancaire
  • Extension "Outils comptables avancés" :
    • Suppression de l'outil "Affectation automatique de comptes"
    • Les règles configurées pour cet outil sont automatiquement migrées vers les règles d'import de relevé bancaire

Version 1.4.0 (fait)

  • Nouvelle extension HelloAsso permettant d'importer les adhésions : création de membre, inscription à une activité, et de créer des écritures comptables à partir des paiements
  • Comptabilité :
    • Interface : le sous-menu "Suivi des écritures" a été supprimé, son contenu est désormais accessible dans le menu principal "Comptabilité" (merci @Ressuscycle pour le retour UX)
    • Correctif : il manquait les comptes 741 et 742 dans le plan comptable associatif 2025
  • Activités et tarifs :
    • ajout des totaux sur la page listant les tarifs des activités
    • ajout d'une page "historique" listant toutes les inscriptions de tous les membres
    • ajout d'une page "Inscriptions" qui liste toutes les inscriptions, avec la possibilité d'exporter (merci @Jamel)
    • ajout de la possibilité de mettre à jour les inscriptions via l'import, pour mettre à jour par exemple la date d'inscription ou d'expiration
    • ajout d'un bouton d'export pour la liste des activités et la liste des tarifs
    • déplacement du bouton d'export dans la liste des tarifs et des activités, pour que ça soit plus cohérent avec les autres écrans (amélioration UX)
  • Rappels :
    • On peut désormais choisir qu'un rappel ne soit pas envoyé avant le jour de sa création (pour éviter d'envoyer un rappel à plein de membres)
    • Permettre de ne pas supprimer l'historique des rappels lors de la suppression d'un rappel.
  • Site web :
    • on peut désormais choisir l'ordre de liste des pages dans les catégories du site
  • Le texte de la page d'accueil est désormais au format Markdown (au lieu de Skriv) et permet l'inclusion de balises Brindille (merci @Eric)
  • Réorganisation de la navigation dans Configuration → Avancé → SQL
  • Ajout de la possibilité d'activer le profileur dans Configuration → Avancé → SQL→ Options développeur⋅euse

Brindille

  • Le filtre gettype renvoie désormais int et bool au lieu de integer et boolean, pour être cohérent avec les versions récentes de PHP
  • Le paramètre explain a été supprimé de toutes les sections, activer le profileur à la place
  • Ajout d'un stockage de données sous forme de tables SQL dans les modules :
    • Ajout d'un paramètre version dans le fichier module.ini
    • Ajout d'un nouveau squelette spécial migration.tpl qui sera appelé en cas de première utilisation d'un module, ou de mise à jour
    • Nouvelles fonctions : table et column
    • Nouveau fonctionnement et paramètres pour les fonctions save et delete et les sections load et list (voir la documentation)
    • Nouveau filtre : version_compare
    • Section load : le paramètre check a été renommé checkable, le paramètre disable_user_sort a été renommé user_sorting=false
  • Le stockage de données sous forme de document JSON dans les modules est maintenant découragé (deprecated) :
    • Il pourrait être supprimé dans une version majeure future (horizon : 3 à 5 ans minimum)
    • Les fonctions save et delete et les sections load et list continueront de fonctionner comme avant pour le moment. Si un nom de table est spécifié, c'est le nouveau comportement qui sera utilisé.
    • Cette logique avait été adoptée avec l'espoir d'attirer plus de développeurs "modernes", plus à l'aise avec JSON qu'avec SQL, mais ça a été un échec et c'est beaucoup plus complexe à utiliser au final.
    • Voir la documentation pour une aide à la migration.
    • Attention, dans la section load : le paramètre each a été supprimé pour des raisons de sécurité

API

  • Refonte de la documentation de l'API pour être plus lisible
  • Route sql : ajout du support des paramètres nommés (merci @Henri)
  • Refonte de l'API pour la gestion du site web (attention : changement de certaines routes, voir la documentation) :
    • La route web/list a été supprimée (utiliser web tout court à la place)
  • La route accounting/years/current/account/journal?code={CODE} a été renommée accounting/years/current/journal/{CODE}
  • La route accounting/years/current/account/journal?id={ID} a été renommée accounting/years/current/journal/={ID}
  • Ajout de nouvelles routes :
    • GET user/categories
    • GET user/category/{ID}.{FORMAT}
    • POST user/search
    • POST user/new
    • GET user/{ID}
    • DELETE user/{ID}
    • POST user/{ID}
    • POST user/{ID}/subscribe (merci @Romain pour le patch)
    • GET accounting/years/{ID_YEAR}/export/{TYPE}.{FORMAT}

Évolutions techniques :

  • Évolution des versions minimales requises :
    • PHP 8.2 minimum (sortie en 2022, arrêt du support de PHP 7.4, 8.0 et 8.1)
    • SQLite 3.34 minimum (sortie en 2020, intégrée à Debian Bullseye en 2021)
  • Plugins :
    • Déplacement du répertoire des plugins par défaut de data/plugins vers plugins tout court (à la racine de Paheko)
    • Correctif : les plugins packagés sous forme de fichier .tar.gz ne fonctionnaient plus (merci @zou)
  • Connexion externe (OIDC) : ajout du nom de la personne connectée dans le journal d'audit et comme créateur d'une écriture comptable (merci @Neil), même si la personne connectée ne correspond pas à un membre Paheko
  • Il n'est plus nécessaire d'activer les liens symboliques quand on installe depuis Fossil
  • Schéma SQL :
    • la table services_users a été renommée services_subscriptions
    • la colonne id_service_user de la table acc_transactions_users a été renommée id_subscription

## Version 1.4.xx (en cours)

Emails :

  • Refonte du code d'envoi des e-mails
  • Ajout de la possibilité de définir le texte d'extrait (preheader) des messages collectifs
  • Séparation de l'édition de message en deux : un formulaire pour modifier sujet, extrait et expéditeur, et un pour modifier le contenu
  • Ajout d'une prévisualisation du message lors de la modification du sujet, extrait ou expéditeur (comme il sera peut-être vu par le destinataire)
  • Affichage de l'adresse e-mail expéditeur forcée, dans le cas où MAIL_SENDER est défini
  • Changement de la logique pour les listes de destinataires :
    • On commence maintenant par créer une liste de destinataires pour pouvoir envoyer un message
    • Une liste peut être constituée de plusieurs cibles : catégorie de membres, champ de fiche membre, recherche avancée, activité
    • On peut cumuler les critères d'une cible, exemple : je cible les membres à jour de cotisation, dans la catégorie "Membres actifs", ayant coché la case "Lettre d'info"
    • Les champs de type case à cocher ajoutés à une cible peuvent être décochés par le membre depuis les messages reçus
    • Pour simplifier la transition, une liste a été créée pour chacune des case à cocher de la fiche membre
  • Ajout d'une constante MAIL_SENDER_EXPLAIN pour avoir un texte indiquant pourquoi l'adresse d'expédition ne peut être modifiée dans le cas d'hébergement multi-sites par exemple.

À intégrer (branche dev) :

En cours :

  • Gestion des e-mails :
    • refonte / nettoyage code envoi de mails
    • permettre d'envoyer des messages bruts dans la file d'attente
    • suivi de la file d'attente via l'interface
    • pouvoir signer un mail en DKIM directement depuis Paheko
  • Messages collectifs :
    • permettre les fichiers joints aux messages collectifs
    • Pouvoir envoyer une adresse mail en temps réel et donc vérifier une adresse mail en direct à l'inscription

Fait :

  • E-mails :
    • le formulaire de contact du site utilise désormais l'adresse e-mail de la personne qui fait le contact comme adresse pour les réponses à adresser (champ Reply-To)
  • Messages collectifs :
    • Une adresse e-mail destinataire peut désormais choisir le type de messages qu'elle souhaite recevoir : aucun message, messages collectifs, rappels d'expiration, etc.
    • Pour créer un message collectif il faut désormais déjà créer une liste de destinataires, cela permettra aux destinataires de pouvoir choisir à quelles listes ils souhaitent s'abonner ou non
    • Les événements liés à une adresse e-mail (vérification, bounce, désinscription) sont désormais journalisés, permettant de justifier l'inscription d'une personne à une liste selon le RGPD

Version 1.4.XXX (planifié)

Prévu :

  • Suppression/anonymisation automatique des fiches des anciens adhérents
  • Modifier le sélecteur de couleur dans "Personnalisation" pour utiliser le sélecteur de teinte (HSL)
  • API : générer la doc en markdown, puis en HTML, à partir de la spéc OpenAPI (YAML)
  • Activités :
    • [Inscription à une activité : avertir si le membre a déjà une inscription valide (en cours) à l'activité]
    • [Inscriptions aux activités : pouvoir savoir qui a inscrit un membre à une activité]

Version 1.5 — Refonte inscription aux activités + paiements (2026-28 ?)

  • Refonte des activités :

    • création d'un nouveau menu "Activités" avec sous-menus : "Encaisser"
    • nouveau type de droits pour les catégories de membre, permettant de ne donner accès qu'à l'inscription aux activités / encaissement
    • possibilité d'inscrire plusieurs membres à une activité en même temps, via l'encaissement
    • Tous les tickets liés aux activités : https://fossil.kd2.org/paheko/rptview?rn=9

  • Encaissement intégré (voir wiki:Dev/Paiements)

    • Fusion du plugin "Caisse" dans Paheko (qui deviendra le sous-menu "Encaisser")
    • Intégration de l'encaissement / produits de l'extension caisse
    • Renommage de "note" en "panier"
    • Ajout de la possibilité de faire un encaissement ponctuel (sans ouvrir une session de caisse)
    • Ajout de la possibilité de calculer le prix d'un produit de manière dynamique avec un calcul SQL
    • Les tarifs des activités seront transformés en "sous-activités" (meilleur nom à trouver), cf. retours sur le forum
    • Il sera possible d'associer un produit à une activité ou "sous-activité" (comme c'est le cas actuellement avec les tarifs)
    • Il faudra permettre de décompter le nombre de personnes ayant payé une activité par produit (exemple : tarif réduit / tarif plein)
    • La gestion des paiements d'une inscription à une activité renverra vers l'encaissement
    • Création automatique d'écriture à partir d'encaissements ponctuels
    • Création de demandes d'encaissement liées à une activité / produit (= commandes)
    • ~~Création de membre à partir d'un encaissement~~ (déjà fait dans la 1.3.13)
    • Formulaire d'inscription de membre
    • Possibilité de choisir entre des écritures comptables consolidées (comme actuellement, une par session de caisse) ou multiples (une écriture par panier par exemple)
    • Supprimer l'affichage des dettes/créances des membres dans "Mes activités" au profit des ardoises de la caisse

  • Intégration de l'interfaçage avec les prestataires de paiement

    • Chaque prestataire de paiement s'intègre sous forme de plugin
    • HelloAsso, Mollie, Stripe, Stancer, etc.

Divers

  • Refonte de l'éditeur markdown, en mode WYSIWYG/blocs
  • Rédaction WYSIWYG de mailing

Modules

Modules en cours :

  • Immobilisations simplifiées (@lesanges)
  • Module Devis et factures
  • Module Bilan expert: Présente le bilan comptable selon le modèle du plan comptable associatif 2024. Ce modèle est parfois demandé en cas de demande de subvention.

Extensions qu'il serait chouette de porter en modules :

  • ~~Matériels permet de gérer une liste de matériels ainsi que de suivre les prêts de matériel — JBThePenguin n'est pas dispo pour la porter~~ (porté en module par @lesanges)
  • Comptages : compter le nombre de participants à une manifestation, de véhicules passant dans une rue, etc.

Liste pêle-mêle des fonctionnalités prévues mais pas encore planifiées

Prioritaire

Fichiers :

  • Possibilité de restreindre un fichier/dossier à certains membres / catégories

Factures (septembre 2026) :

Divers :

  • Tests unitaires et d'intégration
  • (Ajouter un droit services pour différencier gestion activités et gestion membres)

Securité :

  • OTP : Enregistrer des codes de secours à usage unique à utiliser en cas de perte du code secret qui génère des OTP

Comptabilité :

  • Paiement d'activité en ligne directement depuis Paheko
  • Ajout stockage relevé bancaire (joindre un fichier) dans le rapprochement, par période
  • Ajout total débit/crédit par mois dans le rapprochement
  • Archivage des données de l'exercice lors de la clôture
  • Suivre les instructions du ministère des finances concernant l'archivage des données comptable, cf. PDF

Adhérents :

  • Inscription autonome en ligne, avec une page utilisée comme "conditions d'inscription" à accepter à l'inscription
  • Suppression/anonymisation automatique des fiches des anciens adhérents
  • Log des accès aux fiches de membre en lecture

Moins prioritaire

Comptabilité :

  • lier les membres aux lignes de l'écriture et non à l'écriture elle-même
  • supprimer une écriture comptable à la suppression d'une cotisation
  • supprimer une cotisation à la suppression d'une écriture comptable
Internationalisation
  • Traduction intégrale de l'interface en anglais
  • Traduction de l'interface
  • Choix de la langue et de la localisation par membre
  • Gestion de fuseaux horaires différents selon les membres
  • Localisation des dates, poids, formats de monnaie (gros boulot)
  • Mise en place d'une infrastructure de traduction communautaire, via Weblate par Yunohost par exemple

Ce qui ne sera pas fait

Généralement, pour déterminer si une fonctionnalité doit être intégrée, nous réfléchissons de cette manière :

  • la fonctionnalité doit être disponible au plus grand nombre d'associations : sur Paheko.cloud, et en auto-hébergement ;
  • nous devons pouvoir être capables de maintenir la fonctionnalité sur le temps long (5, 10, 15 ans, etc.) ;
  • nous devons pouvoir être capables de supporter la charge qu'elle générerait en termes de messages envoyés au support ;
  • la fonctionnalité doit répondre à un besoin qui fait sens à l'usage et le public de Paheko.

Connexion automatique aux banques pour récupérer les écritures

Les banques ne permettent pas de se connecter à leurs APIs respectives à n'importe qui, seuls les entreprises agréées par la banque de france le peuvent. De plus chaque banque a une API différente, et chaque API demanderait plusieurs mois de travail.

Ça demanderait d'avoir un accord avec une société commerciale (type Powens) pour avoir accès à leur API, ce qui ne serait pas faisable pour les associations auto-hébergées, donc peu d'intérêt à développer une solution qui ne profiterait pas à tout le monde. De plus cela risque de coûter assez cher, en plus de prendre plusieurs mois à implémenter.

Alternativement, il serait possible d'utiliser Woob par exemple, comme le font Cozy Cloud, mais :

  • des connexions à certaines banques (backends) peuvent rester cassées plusieurs mois ;
  • ça générerait donc une surcharge de messages au support Paheko, et on ne pourrait pas régler les problèmes (pas de compétences en Python, ni le temps) ;
  • un backend cassé voudrait dire que pour toutes les assos utilisant cette banque ne peuvent plus utiliser la connexion donc retour à la procédure manuelle ;
  • le risque de vol de ces données critiques (identifiant et mot de passe d'accès au compte bancaire !) n'est pas nul, même en essayant de sécuriser au maximum. Dans ce cas les conséquences (vol d'argent) seraient désastreuses !

Cette solution ne serait donc acceptable que dans le cadre d'un auto-hébergement. Dans ce cas, c'est le contraire, ça n'intéresserait pas Paheko.cloud et autres hébergeurs de Paheko, donc le nombre d'associations concernées serait faible.

Nous préférons consacrer notre temps et énergie à implémenter des formats interopérables comme l'import de CSV, QIF ou OFX. Ceux-ci sont plus durables vu que nous travaillons sur le temps long.

Remplissage automatique de formulaires administratifs (type CERFA)

Généralement ces formulaires ne peuvent pas être remplis intégralement de manière automatisée, et quand certaines données peuvent être renseignées, elles ne prendraient que quelques minutes à recopier, alors que développer le remplissage automatique du formulaire demanderait plusieurs semaines de travail.

De plus, ces formulaires ont tendance à changer régulièrement, tous les 3 à 5 ans, il faut alors souvent beaucoup de travail pour se mettre à jour.