Data Model and Editing

Data Model and Editing

Gramps Connect works with the same object model as Gramps itself. There are ten record types, each with its own list view, its own searchable (plain-text by default, or GOQL via a checkbox) search box, and its own REST endpoint on gramps-web-api:

Type	List view	Query endpoint
Person	People	/api/people/query/
Family	Families	/api/families/query/
Event	Events	/api/events/query/
Place	Places	/api/places/query/
Repository	Repositories	/api/repositories/query/
Source	Sources	/api/sources/query/
Citation	Citations	/api/citations/query/
Media	Media	/api/media/query/
Note	Notes	/api/notes/query/
Tag	Tags	/api/tags/query/

Because a tree can move freely between Gramps Desktop, gramps-web, and Gramps Connect (see Overview), these are exactly the record types and fields Gramps XML and GEDCOM already carry — Gramps Connect doesn't add or remove any.

Browsing

Pick a record from a list, and everything related to it — events, family, photos, notes, sources — appears alongside it. Click into any of those and its own details open below, while the list and your original selection stay where they were, however deep you go (see Overview).

Editing

Clicking the edit button on any record opens its full editing form for that record's own details (a name, a date, a description) or its connections to other records — exactly how a child relates to their parents, for instance.

For smaller, everyday changes, the "+" and "−" buttons are a shortcut: attach an existing citation, photo, or person without opening a full form, or remove one that's already linked. They only change what a record is connected to, not the record's own details.

What's fully editable today

Person and Family records are the most complete, with one notable exception: LDS ordinances are fully read-only — no edit, add, or detach.

What's partially editable, by type

• Place — a place's enclosing/parent hierarchy can now be filled in via a Wikidata lookup (search by name, confirm a match, and it creates or links the city/county/state/country chain with each level's own coordinates); there's still no way to add, remove, or reorder an enclosing place by hand, independent of Wikidata. Each level's Type field is guessed from Wikidata too, from a table covering ~2700 administrative- division and settlement classes across most countries (not just the U.S.-shaped city/county/state/country); an unrecognized class still leaves Type blank on the confirmation screen for you to fill in by hand. Every level the lookup creates gets a descriptive title that includes its confirmed ancestors (e.g. "Marion County, Indiana, United States"), not just its own bare name — its underlying name field stays the bare name, so a later lookup can still recognize it as the same place. A brand-new place's editor asks up front whether to add it manually or from Wikidata, rather than showing the lookup as just another field alongside the manual ones; an already-saved place being re-edited keeps the lookup as a plain enrichment button instead. That same lookup can optionally fetch an outline from Wikidata too (a checkbox on the confirmation screen, on by default) — for each newly-created level and for the place being added itself — so the map shows its actual boundary rather than only a pin at its coordinates — attached the same way a hand-drawn map shape is, so it's editable/removable from the Media view afterward like any other attachment, and colored by the place's type and Wikidata ID so different places don't all default to the same fill. Existing/reused levels in the hierarchy don't get one retrofitted. A place's own (primary) name can now carry a date and language, the same date editor used for events and citations — this is what the map overlay feature's date-based visibility reads (see Overview). Still missing: alternate names (add/edit/remove — a place's alt_names list is displayed read-only but has no editor; each entry is its own name with its own date/language, e.g. for recording an older name and the era it applied), historical locations, and code.
• Note — missing: text formatting/links (notes are plain text only), and the format flag (Flowed/Formatted).
• Media — description, date, and privacy are editable via an Edit button; the file itself, its type, and its checksum stay server-derived from the upload. Attributes, citations, notes, and tags are already editable via the same related-records sections every other record type uses. Photos already open full-size on click; a Media (or Output) item whose file is a PDF, video, audio clip, SVG, or text-like format (HTML, JSON, plain text, CSV, GEDCOM, KML/XML, ...) gets a View button next to it instead, opening the same file in the browser rather than requiring a download. HTML previews render sandboxed (no scripts) so a generated report's formatting shows without ever executing anything in it (though any asset it links by relative path won't load, since only that one file is available, not a folder of siblings).

Merging duplicate records

Every record type except Tag can be merged: select two records of the same type (ctrl/cmd+click in a list), then Merge. Pick which one survives — its own defining fields (name, title, date, etc., depending on type) are kept and the other's are discarded, while list-shaped things like notes, citations, media, and attributes are combined from both. Every other reference to the record that didn't survive is repointed to the one that did before it's deleted. Family is the one type that can disagree on a parent between the two records being merged; when that happens you're asked, per role (father/mother), which side to keep. Tags have no merge route in Gramps itself, so merging two tags is handled client-side instead — everything tagged with the discarded tag is retagged with the survivor, which is then deleted.

Viewing edit history

Every record has a History button alongside its Map/Timeline/Graph links. It opens a log of that record's own changes — who made each one, when, and whether it was an add, update, or delete — newest first, a page at a time. Click any entry to see exactly what changed: a field-by-field before/after diff, not just the fact that something changed. This is the after-the-fact complement to live sync (see Architecture), which only shows edits as they arrive; both read from the same gramps-web-api transaction log.

There's no undo yet — reverting a change means editing the record back by hand. See Roadmap and Known Limitations for where that stands.

Cross-cutting gaps

• GrampsType fields are mostly free text. Family's relationship type, and Attribute/Url's own type, have a real dropdown with autocomplete against Gramps' known list of values. Other GrampsType fields are functionally editable as plain text, just without that autocomplete or validation yet.
• Concurrent edits are caught, not merged. If a record changed on the server after you opened its edit form — someone else, or another tab of your own — saving is refused with an error rather than silently overwriting their change. There's still no way to see what changed or merge the two edits; you just have to reopen and redo yours.

See Roadmap and Known Limitations for where these stand in terms of active work.