Data Model and Editing.fr

🌐 English · Deutsch

Modèle de données et édition

Gramps Connect fonctionne avec le même modèle d'objets que Gramps lui-même. Il y a dix types de fiches, chacun avec sa propre vue de liste, son propre champ de recherche consultable (texte simple par défaut, ou GOQL via une case à cocher), et son propre endpoint REST sur gramps-web-api :

Type	Vue de liste	Endpoint de requête
Person	Individus	/api/people/query/
Family	Familles	/api/families/query/
Event	Événements	/api/events/query/
Place	Lieux	/api/places/query/
Repository	Dépôts	/api/repositories/query/
Source	Sources	/api/sources/query/
Citation	Citations	/api/citations/query/
Media	Media	/api/media/query/
Note	Notes	/api/notes/query/
Tag	Étiquettes	/api/tags/query/

Puisqu'un arbre peut circuler librement entre Gramps Desktop, gramps-web, et Gramps Connect (voir Aperçu), ce sont exactement les types de fiches et les champs que Gramps XML et GEDCOM portent déjà — Gramps Connect n'en ajoute ni n'en retire aucun.

Parcourir

Choisir une fiche dans une liste, et tout ce qui s'y rapporte — événements, famille, photos, notes, sources — apparaît à côté. Cliquer sur l'un d'eux ouvre ses propres détails en dessous, tandis que la liste et la sélection d'origine restent où elles étaient, quelle que soit la profondeur atteinte (voir Aperçu).

Éditer

Cliquer sur le bouton de modification de n'importe quelle fiche ouvre son formulaire d'édition complet pour les propres détails de cette fiche (un nom, une date, une description) ou ses connexions avec d'autres fiches — exactement comment un enfant est apparenté à ses parents, par exemple.

Pour des changements plus petits et quotidiens, les boutons « + » et « − » sont un raccourci : attacher une citation, une photo ou une personne existante sans ouvrir un formulaire complet, ou en retirer une déjà liée. Ils ne changent que ce à quoi une fiche est connectée, pas les propres détails de la fiche.

Ce qui est entièrement modifiable aujourd'hui

Les fiches Person et Family sont les plus complètes, avec une exception notable : les ordinances mormones (LDS) sont entièrement en lecture seule — aucune modification, ajout, ou détachement.

Ce qui est partiellement modifiable, par type

• Place — la hiérarchie englobante/parente d'un lieu peut désormais être remplie via une recherche Wikidata (rechercher par nom, confirmer une correspondance, et cela crée ou lie la chaîne ville/comté/région/pays avec les propres coordonnées de chaque niveau) ; il n'y a toujours aucun moyen d'ajouter, retirer, ou réordonner un lieu englobant à la main, indépendamment de Wikidata. Le champ Type de chaque niveau est aussi deviné depuis Wikidata, depuis une table couvrant environ 2700 classes de division administrative et d'agglomération à travers la plupart des pays (pas seulement la chaîne ville/comté/région/pays à l'américaine) ; une classe non reconnue laisse quand même Type vide sur l'écran de confirmation, à remplir à la main. Chaque niveau créé par la recherche obtient un titre descriptif qui inclut ses ancêtres confirmés (par ex. « Marion County, Indiana, United States »), pas seulement son propre nom nu — son champ de nom sous-jacent reste le nom nu, pour qu'une recherche ultérieure puisse encore le reconnaître comme le même lieu. L'éditeur d'un tout nouveau lieu demande d'abord s'il faut l'ajouter manuellement ou depuis Wikidata, plutôt que de montrer la recherche comme un simple champ de plus parmi les manuels ; un lieu déjà enregistré, en cours de nouvelle édition, garde plutôt la recherche comme un simple bouton d'enrichissement. Cette même recherche peut aussi optionnellement récupérer un contour depuis Wikidata (une case à cocher sur l'écran de confirmation, activée par défaut) — pour chaque niveau nouvellement créé et pour le lieu ajouté lui-même — pour que la carte montre sa véritable frontière plutôt qu'une simple épingle à ses coordonnées — attaché de la même façon qu'une forme de carte dessinée à la main, donc modifiable/supprimable ensuite depuis la vue Media comme toute autre pièce jointe, et colorée selon le type du lieu et son identifiant Wikidata pour que différents lieux n'aient pas tous le même remplissage par défaut. Les niveaux existants/réutilisés dans la hiérarchie n'en reçoivent pas un rétroactivement. Le propre nom (principal) d'un lieu peut désormais porter une date et une langue, le même éditeur de date utilisé pour les événements et les citations — c'est ce que lit la visibilité basée sur la date de la fonctionnalité de superposition de carte (voir Aperçu). Toujours manquant : les noms alternatifs (ajouter/modifier/retirer — la liste alt_names d'un lieu s'affiche en lecture seule mais n'a pas d'éditeur ; chaque entrée est son propre nom avec sa propre date/langue, par ex. pour enregistrer un nom plus ancien et l'époque à laquelle il s'appliquait), les emplacements historiques, et le code.
• Note — manquant : la mise en forme du texte/les liens (les notes sont uniquement du texte brut), et l'indicateur de format (Continu/Formaté).
• Media — la description, la date, et la confidentialité sont modifiables via un bouton Modifier ; le fichier lui-même, son type, et sa somme de contrôle restent dérivés côté serveur à partir de l'envoi. Les attributs, citations, notes, et étiquettes sont déjà modifiables via les mêmes sections de fiches liées que tout autre type de fiche utilise. Les photos s'ouvrent déjà en pleine taille au clic ; un élément Media (ou Output) dont le fichier est un PDF, une vidéo, un clip audio, un SVG, ou un format textuel (HTML, JSON, texte brut, CSV, GEDCOM, KML/XML, …) obtient à la place un bouton Voir à côté, ouvrant le même fichier dans le navigateur plutôt que d'exiger un téléchargement. Les aperçus HTML s'affichent dans un bac à sable (aucun script) pour que la mise en forme d'un rapport généré s'affiche sans jamais rien exécuter dedans (bien qu'aucune ressource qu'il lie par chemin relatif ne se charge, puisque seul ce fichier est disponible, pas un dossier de fichiers frères).

Fusionner des fiches en double

Tout type de fiche sauf Étiquette peut être fusionné : sélectionner deux fiches du même type (ctrl/cmd-clic dans une liste), puis Fusionner. Choisir laquelle survit — ses propres champs définissants (nom, titre, date, etc., selon le type) sont conservés et ceux de l'autre sont abandonnés, tandis que les éléments de type liste comme les notes, citations, médias, et attributs sont combinés des deux. Toute autre référence à la fiche qui n'a pas survécu est redirigée vers celle qui a survécu avant sa suppression. Family est le seul type qui peut présenter un désaccord sur un parent entre les deux fiches fusionnées ; quand cela arrive, il est demandé, par rôle (père/mère), quel côté garder. Les Étiquettes n'ont pas de chemin de fusion dans Gramps lui-même, fusionner deux étiquettes est donc géré côté client à la place — tout ce qui portait l'étiquette abandonnée est réétiqueté avec la survivante, qui est ensuite supprimée.

Consulter l'historique des modifications

Chaque fiche a un bouton Historique à côté de ses liens Carte/Chronologie/Graphe. Il ouvre un journal des propres modifications de cette fiche — qui a fait chacune, quand, et si c'était un ajout, une mise à jour, ou une suppression — du plus récent au plus ancien, une page à la fois. Cliquer sur une entrée pour voir exactement ce qui a changé : une comparaison avant/après champ par champ, pas seulement le fait que quelque chose a changé. C'est le complément a posteriori à la synchronisation en direct (voir Architecture), qui ne montre que les modifications au moment où elles arrivent ; les deux lisent le même journal de transactions de gramps-web-api.

Il n'y a pas encore d'annulation — annuler une modification signifie rééditer la fiche à la main pour revenir en arrière. Voir Feuille de route et limitations connues pour l'état de la question.

Lacunes transversales

• Les champs GrampsType sont surtout du texte libre. Le type de relation de Family, et le propre type de Attribute/Url, ont un vrai menu déroulant avec autocomplétion contre la liste de valeurs connues de Gramps. Les autres champs GrampsType sont fonctionnellement modifiables comme texte brut, simplement sans cette autocomplétion ou validation pour l'instant.
• Les modifications concurrentes sont détectées, pas fusionnées. Si une fiche a changé sur le serveur après l'ouverture de son formulaire d'édition — par quelqu'un d'autre, ou un autre onglet personnel — l'enregistrement est refusé avec une erreur plutôt que d'écraser silencieusement leur modification. Il n'y a toujours aucun moyen de voir ce qui a changé ou de fusionner les deux modifications ; il faut simplement rouvrir et refaire la sienne.

Voir Feuille de route et limitations connues pour l'état de ces points en termes de travail actif.