Roadmap.nl

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

Roadmap en bekende beperkingen

Gramps Connect wordt actief ontwikkeld. Deze pagina is een eerlijk overzicht van wat er nog niet is, gebaseerd op de eigen lijst met open punten van het project — handig om te beslissen of het al dekt wat u nodig hebt, of om een plek te kiezen om bij te dragen.

Grootste hiaten vandaag

• Bewerken is nog niet volledig. Bij Plaats en Notitie ontbreken elk bepaalde velden. Zie Datamodel en bewerken voor het volledige overzicht per type.

Het samenvoegen van dubbele records wordt ondersteund voor elk type behalve Label (dat in plaats daarvan aan de clientzijde samenvoegt) — zie Datamodel en bewerken.

Architectuur en productrichting

• Een aanwezigheidslaag (wie op dit moment wat bekijkt of bewerkt) is gepland als een bewust vluchtig mechanisme in het geheugen/in Redis, gescheiden gehouden van het duurzame synchronisatiepad via de transactiegeschiedenis dat in Architectuur wordt beschreven.
• Authenticatie/rechten. app/ heeft een minimaal inlogformulier met echte inloggegevens (niets hardgecodeerd buiten de desktopversie), maar nog geen rotatie van refresh-tokens of afhandeling van verlopen tokens. De eigen klasse Auth van gramps-web is de referentie waartegen wordt gebouwd.
• UX voor samenvoegen/conflicten bij echt gelijktijdige bewerkingen van hetzelfde object is een open ontwerpvraag die nog niet is opgelost — de fixture dev-fixtures/layer3-sync/ (zie Ontwikkeling) bestaat speciaal om dit scenario te oefenen. Bij het opslaan wordt nu gedetecteerd wanneer een record op de server is gewijzigd sinds het bewerkformulier werd geopend, en wordt overschrijven geweigerd (zie Datamodel en bewerken), maar dat is conflictdetectie, geen oplossing — er is nog steeds geen manier om de twee versies naast elkaar te zien of samen te voegen.
• Een hiaat in filter-pushdown in gramps-web-api: het oudere endpoint GrampsObjectsResource.get() laadt nog steeds onvoorwaardelijk elk object voordat filter/rules/gql/oql wordt toegepast — een bekend prestatieprobleem bij zeer grote stambomen. Een nieuwer endpoint ObjectQueryResource (waarvan de eigen /query/-endpoints van Gramps Connect en GOQL afhankelijk zijn) doet via een ander codepad al echte SQL-pushdown; of dat het repareren van het oudere endpoint overbodig maakt, is nog een open vraag.
• Een volledig herontwerp van de gebruikersinterface van het objectmodel, een echt designsysteem en zoeken-als-navigatie zijn allemaal richtingen die worden overwogen, maar nog niet zijn uitgewerkt.

Ideeën voor functies en backlog

• Gramplets objecten laten aanmaken. Records wijzigen en verwijderen werkt al (zie Gramplets).
• Meer typen Gramps-add-ons ondersteunen naast Gramplets — hulpmiddelen, rapporten.
• PDF-formulieren genereren (zou een PDF-importeur vereisen).
• Het project onderbrengen bij de GitHub-organisatie gramps-project — dat zou onder meer de deur kunnen openen naar vertalingen via de bestaande Weblate-infrastructuur van Gramps.
• Recent bezochte items.
• Ongedaan maken, nu de wijzigingsgeschiedenis per object (zie Datamodel en bewerken) een gebruikersinterface een plek geeft om het aan te bieden — een echte implementatie zou nog wel een eigen beoordeling van correctheid en conflictafhandeling nodig hebben (wat "ongedaan maken" betekent als iemand anders het record inmiddels heeft bewerkt), niet alleen een knop die aan de bestaande diff-gegevens is gekoppeld.
• Echte <a href>-links voor navigatie binnen de app (de titel van een record, "Openen in de lijstpagina", ...) in plaats van de huidige klikken in knopstijl, zodat de eigen rechtermuisklik "Openen in nieuw tabblad" / middelklik van de browser erop werkt — handig om twee records naast elkaar te vergelijken.
• Een echte koppeling op Gramps-niveau tussen een kaartoverlay met een afbeelding en de plaats waaraan die is gekoppeld. Vandaag bevat de KML van de overlay de handle van de bronafbeelding op een app-interne manier die Gramps zelf niet kan zien, zodat die niet verschijnt in een zoekactie naar "waarnaar verwezen door" en het hulpmiddel van Gramps Desktop voor het verwijderen van ongebruikte objecten niet weet dat de twee bij elkaar horen — als de afbeelding later wordt losgekoppeld van alles wat er verder naar verwijst, zou de overlay ongemerkt kapotgaan.
• Het bewerken van alternatieve namen voor Plaats (zie Datamodel en bewerken) zou het ook mogelijk maken dat de datumzichtbaarheid van een kaartoverlay van een specifieke alternatieve naam wordt gelezen, in plaats van een aparte plaatsrecord per tijdperk te vereisen — vandaag hebben twee overlays met verschillende datumbereiken op dezelfde fysieke plek elk hun eigen plaats nodig, omdat de datum van een plaats bij haar (primaire) naam hoort.

CI en build-controles

Een CI-workflow draait nu bij elke push en pull request: tests, typecontrole en een build, zodat een kapotte commit automatisch wordt opgemerkt in plaats van erop te vertrouwen dat iemand deze met de hand uitvoert. build-docker.yml en build-standalone.yml blijven alleen handmatig te starten (ze hebben een push naar een registry of platformspecifieke runners nodig, wat het niet waard is bij elke commit). Er is nog nergens in de repository een linter (ESLint/Prettier) geconfigureerd — of er een wordt toegevoegd, staat als open werk op de lijst. Zie Ontwikkeling voor de test- en typecontrolecommando's die CI uitvoert.

Waar deze lijst wordt bijgehouden

Deze pagina is een momentopname. De gezaghebbende, voortdurend bijgewerkte versie is TODO.md in de gramps-connect-repository — kijk daar (en in de issuetracker van de repository) voor de actuele stand voordat u aanneemt dat iets wat hier staat nog openstaat.