Roadmap.fr

🌐 English · Deutsch

Feuille de route et limitations connues

Gramps Connect est en développement actif. Cette page est un état des lieux honnête de ce qui n'est pas encore là, tiré de la propre liste des points ouverts du projet — utile pour décider si cela couvre déjà ce dont vous avez besoin, ou pour choisir où contribuer.

Plus grandes lacunes aujourd'hui

• La couverture d'édition n'est pas complète. Place et Note ont chacun des champs manquants spécifiques. Voir Modèle de données et édition pour la répartition complète, type par type.

La fusion de fiches en double est prise en charge pour tous les types sauf Étiquette (qui fusionne côté client à la place) — voir Modèle de données et édition.

Architecture et orientation produit

• Une couche de présence (qui consulte ou modifie quoi en ce moment) est prévue comme un mécanisme délibérément éphémère, en mémoire/Redis, gardé séparé du chemin durable de synchronisation par historique de transactions décrit dans Architecture.
• Authentification/permissions. app/ a un formulaire de connexion minimal utilisant de vraies informations d'identification (rien de fixé en dur en dehors de la version pour ordinateur), mais pas encore de rotation de jeton de rafraîchissement ni de gestion d'expiration. La propre classe Auth de gramps-web est la référence par rapport à laquelle c'est construit.
• UX de fusion/conflit pour des modifications réellement concurrentes du même objet est une question de conception ouverte, pas encore résolue — la fixture dev-fixtures/layer3-sync/ (voir Développement) existe spécifiquement pour exercer ce scénario. Un enregistrement détecte désormais quand une fiche a changé sur le serveur depuis l'ouverture de son formulaire d'édition et refuse de l'écraser (voir Modèle de données et édition), mais c'est de la détection de conflit, pas une résolution — il n'y a toujours aucun moyen de voir les deux versions côte à côte ou de les fusionner.
• Une lacune de filter-pushdown dans gramps-web-api : l'ancien endpoint GrampsObjectsResource.get() charge encore inconditionnellement chaque objet avant d'appliquer filter/rules/gql/oql — un problème de performance connu sur de très grands arbres. Un endpoint ObjectQueryResource plus récent (celui dont dépendent les propres endpoints /query/ de Gramps Connect et GOQL) fait déjà du vrai SQL pushdown via un chemin de code différent ; la question de savoir si cela rend inutile la correction de l'ancien endpoint reste ouverte.
• Une refonte complète de l'interface du modèle d'objets, un véritable système de design, et la recherche-comme-navigation sont toutes des directions envisagées, pas encore planifiées.

Idées de fonctionnalités et arriéré

• Permettre aux Gramplets de modifier ou créer des objets, pas seulement de les lire (en lecture seule actuellement via filter()/get_object()).
• Prendre en charge plus de types d'add-ons Gramps au-delà des Gramplets — outils, rapports.
• Générer des formulaires PDF (nécessiterait un importateur PDF).
• Déplacer le projet sous l'organisation GitHub gramps-project — entre autres choses, cela pourrait ouvrir la porte à des traductions via l'infrastructure Weblate existante de Gramps.
• Éléments récemment consultés.
• Annulation, maintenant que l'historique des modifications par objet (voir Modèle de données et édition) donne à une interface un endroit d'où la proposer — une véritable implémentation aurait encore besoin de sa propre revue de correctitude et de gestion des conflits (ce que « annuler » signifie une fois que quelqu'un d'autre a modifié la fiche depuis), pas seulement un bouton branché sur les données de diff existantes.
• De vrais liens <a href> pour la navigation interne à l'application (le titre d'une fiche, « Ouvrir dans sa page de liste », …) au lieu des clics actuels stylisés comme des boutons, pour que le clic droit natif « Ouvrir dans un nouvel onglet »/clic central d'un navigateur fonctionne dessus — pratique pour comparer deux fiches côte à côte.
• Un vrai lien au niveau de Gramps entre une superposition d'image de carte et le lieu auquel elle est attachée. Aujourd'hui, le KML de la superposition intègre le handle de l'image source d'une façon interne à l'application que Gramps lui-même ne peut pas voir, elle n'apparaîtra donc pas dans une recherche « référencé par », et l'outil de suppression des objets non utilisés de Gramps Desktop ne saura pas que les deux sont liés — si l'image est plus tard détachée de tout ce qui la référence par ailleurs, la superposition se casserait silencieusement.
• L'édition des noms alternatifs pour Place (voir Modèle de données et édition) permettrait aussi à la visibilité par date d'une superposition de carte de lire depuis un nom alternatif précis plutôt que d'exiger une fiche de lieu séparée par époque — aujourd'hui, deux superpositions avec des plages de dates différentes au même endroit physique ont chacune besoin de leur propre lieu, puisque la date d'un lieu réside sur son nom (principal).

CI et contrôle de build

Un workflow CI s'exécute désormais à chaque push et pull request : tests, vérification de type, et un build, pour qu'un commit défectueux soit détecté automatiquement plutôt que de compter sur quelqu'un pour les exécuter à la main. build-docker.yml et build-standalone.yml restent à déclenchement manuel uniquement (ils nécessitent un push vers un registre ou des runners spécifiques à la plateforme, pas la peine de les dépenser à chaque commit). Il n'y a toujours aucun linter (ESLint/Prettier) configuré nulle part dans le dépôt — la question d'en ajouter un est suivie comme travail ouvert. Voir Développement pour les commandes de test et de vérification de type que CI exécute.

Où vit cette liste

Cette page est une photographie instantanée. La version faisant autorité, mise à jour en continu, est TODO.md dans le dépôt gramps-connect — vérifier là-bas (et le suivi des issues du dépôt) pour l'état actuel avant de supposer que quelque chose listé ici est encore en attente.