🌐 English · Español · Français · Nederlands · 简体中文

Gramps Connect wird aktiv weiterentwickelt. Diese Seite ist eine ehrliche Bestandsaufnahme dessen, was noch fehlt, aus der eigenen Liste offener Punkte des Projekts — nützlich, um zu entscheiden, ob es bereits das abdeckt, was gebraucht wird, oder um eine Stelle zum Mitwirken auszusuchen.

• Die Bearbeitungsabdeckung ist nicht vollständig. Place und Note fehlen jeweils bestimmte Felder. Siehe Datenmodell und Bearbeitung für die vollständige Aufschlüsselung nach Typ.

Das Zusammenführen doppelter Datensätze wird für jeden Typ außer Tag unterstützt (das stattdessen clientseitig zusammenführt) — siehe Datenmodell und Bearbeitung.

• Eine Präsenzschicht (wer gerade was ansieht oder bearbeitet) ist als bewusst kurzlebiger, speicherinterner/Redis-Mechanismus geplant, getrennt vom dauerhaften Transaktionsverlauf-Synchronisierungsweg, der in Architektur beschrieben ist.
• Auth/Berechtigungen. app/ hat ein minimales Login-Formular mit echten Zugangsdaten (nichts fest codiert außerhalb der Desktop-Version), aber noch keine Refresh-Token-Rotation oder Ablaufbehandlung. Die eigene Auth-Klasse von gramps-web ist die Referenz, gegen die entwickelt wird.
• Merge-/Konflikt-UX für wirklich gleichzeitige Bearbeitungen desselben Objekts ist eine offene Designfrage, noch nicht gelöst — die Fixture dev-fixtures/layer3-sync/ (siehe Entwicklung) existiert eigens, um genau dieses Szenario auszuüben. Ein Speichervorgang erkennt inzwischen, wenn sich ein Datensatz auf dem Server geändert hat, seit sein Bearbeitungsformular geöffnet wurde, und verweigert das Überschreiben (siehe Datenmodell und Bearbeitung), aber das ist Konflikt-Erkennung, keine -Auflösung — es gibt weiterhin keine Möglichkeit, die beiden Versionen nebeneinander zu sehen oder sie zusammenzuführen.
• Eine Filter-Pushdown-Lücke in gramps-web-api: der ältere Endpunkt GrampsObjectsResource.get() lädt weiterhin bedingungslos jedes Objekt, bevor filter/rules/gql/oql angewendet wird — ein bekanntes Performance-Problem bei sehr großen Stammbäumen. Ein neuerer Endpunkt ObjectQueryResource (der, von dem die eigenen /query/-Endpunkte von Gramps Connect und GOQL abhängen) macht bereits echtes SQL-Pushdown über einen anderen Codepfad; ob das die Reparatur des älteren Endpunkts überflüssig macht, ist noch eine offene Frage.
• Eine vollständige Neugestaltung der Objektmodell-Oberfläche, ein richtiges Designsystem und Suche-als-Navigation sind allesamt in Erwägung gezogene Richtungen, noch nicht eingeplant.

• Gramplets erlauben, Objekte anzulegen. Datensätze ändern und löschen funktioniert bereits (siehe Gramplets).
• Mehr Gramps-Add-on-Typen über Gramplets hinaus unterstützen — Werkzeuge, Berichte.
• PDF-Formulare erzeugen (würde einen PDF-Importer brauchen).
• Das Projekt unter die GitHub-Organisation gramps-project verschieben — das könnte unter anderem die Tür zu Übersetzungen über Gramps' bestehende Weblate-Infrastruktur öffnen.
• Kürzlich besuchte Objekte.
• Rückgängig, jetzt, wo der Änderungsverlauf pro Objekt (siehe Datenmodell und Bearbeitung) einer Oberfläche eine Stelle gibt, es anzubieten — eine echte Umsetzung bräuchte noch eine eigene Prüfung von Korrektheit und Konfliktbehandlung (was „rückgängig“ bedeutet, sobald jemand anderes den Datensatz seitdem bearbeitet hat), nicht nur einen an die bestehenden Diff-Daten angeschlossenen Knopf.
• Echte <a href>-Links für die App-interne Navigation (der Titel eines Datensatzes, „In seiner Listenseite öffnen“, …) statt der heutigen, wie Schaltflächen gestalteten Klicks, damit das native Rechtsklick-„In neuem Tab öffnen“/Mittelklick eines Browsers darauf funktioniert — praktisch, um zwei Datensätze nebeneinander zu vergleichen.
• Eine echte Verbindung auf Gramps-Ebene zwischen einer Kartenbild-Überlagerung und dem Ort, an dem sie hängt. Heute bettet das KML der Überlagerung das Handle des Quellbilds auf eine app-interne Weise ein, die Gramps selbst nicht sehen kann, es taucht also in einer „referenziert von“-Suche nicht auf, und das Werkzeug zum Entfernen ungenutzter Objekte von Gramps Desktop weiß nicht, dass die beiden zusammengehören — wird das Bild später von allem, was sonst noch darauf verweist, gelöst, würde die Überlagerung stillschweigend kaputtgehen.
• Bearbeitung alternativer Namen für Place (siehe Datenmodell und Bearbeitung) würde auch erlauben, dass die datumsbasierte Sichtbarkeit einer Kartenüberlagerung von einem bestimmten alternativen Namen ausliest, statt einen separaten Ortsdatensatz pro Epoche zu verlangen — heute brauchen zwei Überlagerungen mit unterschiedlichen Datumsbereichen am selben physischen Ort jeweils einen eigenen Ort, da das Datum eines Orts an seinem (primären) Namen hängt.

Ein CI-Workflow läuft jetzt bei jedem Push und Pull Request: Tests, Typprüfung und ein Build, sodass ein defekter Commit automatisch erkannt wird, statt sich darauf zu verlassen, dass jemand das von Hand ausführt. build-docker.yml und build-standalone.yml bleiben nur manuell auslösbar (sie brauchen einen Registry-Push oder plattformspezifische Runner, nicht wert, bei jedem Commit ausgegeben zu werden). Es gibt weiterhin keinen Linter (ESLint/Prettier) irgendwo im Repository konfiguriert — ob einer hinzugefügt werden soll, wird als offene Arbeit verfolgt. Siehe Entwicklung für die Test- und Typprüfungsbefehle, die CI ausführt.

Diese Seite ist eine Momentaufnahme. Die maßgebliche, laufend aktualisierte Version ist TODO.md im gramps-connect-Repository — dort (und im Issue-Tracker des Repositorys) nach dem aktuellen Stand schauen, bevor angenommen wird, dass etwas hier Aufgeführtes noch aussteht.