Roadmap

Roadmap and Known Limitations

Gramps Connect is under active development. This page is an honest account of what's not there yet, drawn from the project's own open-items list — useful for deciding whether it already covers what you need, or for picking somewhere to contribute.

Biggest gaps today

• Editing coverage isn't complete. Place and Note are each missing specific fields. See Data Model and Editing for the full, type-by-type breakdown.

Merging duplicate records is supported for every type except Tag (which merges client-side instead) — see Data Model and Editing.

Architecture and product direction

• A presence layer (who's currently viewing or editing what) is planned as a deliberately ephemeral, in-memory/Redis mechanism, kept separate from the durable transaction-history sync path described in Architecture.
• Auth/permissions. app/ has a minimal login form using real credentials (nothing hardcoded outside the desktop build), but no refresh-token rotation or expiry handling yet. gramps-web's own Auth class is the reference being built against.
• Merge/conflict UX for genuinely concurrent edits to the same object is an open design question, not yet resolved — the dev-fixtures/layer3-sync/ fixture (see Development) exists specifically to exercise this scenario. A save now detects when a record changed on the server since its edit form opened and refuses to overwrite it (see Data Model and Editing), but that's conflict detection, not resolution — there's still no way to see the two versions side by side or merge them.
• A gramps-web-api filter-pushdown gap: the older GrampsObjectsResource.get() endpoint still unconditionally loads every object before applying filter/rules/gql/oql — a known performance issue on very large trees. A newer ObjectQueryResource endpoint (the one Gramps Connect's own /query/ endpoints and GOQL depend on) already does real SQL pushdown via a different code path; whether that supersedes fixing the older endpoint is still an open question.
• A full object-model UI redesign, a proper design system, and search-as-navigation are all directions being considered, not yet scoped.

Feature ideas and backlog

• Letting Gramplets edit or create objects, not just read them (currently read-only via filter()/get_object()).
• Supporting more Gramps add-on types beyond Gramplets — tools, reports.
• Generating PDF forms (would need a PDF importer).
• Moving the project under the gramps-project GitHub organization — among other things, this could open the door to translations through Gramps' existing Weblate infrastructure.
• Recently-visited items.
• Undo, now that per-object change history (see Data Model and Editing) gives a UI a place to offer it from — a real implementation would still need its own review of correctness and conflict handling (what "undo" means once someone else has edited the record since), not just a button wired to the existing diff data.
• Real <a href> links for in-app navigation (a record's title, "Open in its list page", ...) instead of today's button-styled clicks, so a browser's native right-click "Open in new tab" / middle-click work on them — handy for comparing two records side by side.
• A real Gramps-level link between a map image overlay and the place it's attached to. Today the overlay's KML embeds the source image's handle in an app-internal way that Gramps itself can't see, so it won't show up in a "referenced by" search and desktop Gramps' remove-unused-objects tool won't know the two are related — if the image is later detached from whatever else references it, the overlay would silently break.
• Alternate-name editing for Place (see Data Model and Editing) would also let a map overlay's date-visibility read from a specific alternate name instead of requiring a separate place record per era — today, two overlays with different date ranges at the same physical spot each need their own place, since a place's date lives on its (primary) name.

CI and build gating

A CI workflow now runs on every push and pull request: tests, type checking, and a build, so a broken commit is caught automatically instead of relying on someone running these by hand. build-docker.yml and build-standalone.yml stay manual-trigger only (they need a registry push or platform-specific runners, not worth spending on every commit). There's still no linter (ESLint/Prettier) configured anywhere in the repo — whether to add one is tracked as open work. See Development for the test and typecheck commands CI runs.

Where this list lives

This page is a snapshot. The authoritative, continuously-updated version is TODO.md in the gramps-connect repo — check there (and the repo's issue tracker) for the current state before assuming something listed here is still outstanding.