Skip to content

Roadmap.es

Doug Blank edited this page Oct 5, 2026 · 3 revisions

🌐 English · Deutsch · Français · 简体中文

Hoja de ruta y limitaciones conocidas

Gramps Connect está en desarrollo activo. Esta página es un relato honesto de lo que todavía no está, extraído de la propia lista de tareas pendientes del proyecto: útil para decidir si ya cubre lo que necesita, o para elegir dónde contribuir.

Las mayores carencias hoy

  • La edición no está completa. A Lugar y a Nota les faltan campos concretos. Consulte Modelo de datos y edición para ver el desglose completo, tipo por tipo.

La fusión de registros duplicados está disponible para todos los tipos excepto Etiqueta (que se fusiona en el cliente); véase Modelo de datos y edición.

Arquitectura y dirección del producto

  • Una capa de presencia (quién está viendo o editando qué en este momento) está prevista como un mecanismo deliberadamente efímero, en memoria/Redis, separado de la ruta de sincronización duradera basada en el historial de transacciones que se describe en Arquitectura.
  • Autenticación/permisos. app/ tiene un formulario de inicio de sesión mínimo que usa credenciales reales (nada fijo en el código fuera de la versión de escritorio), pero todavía no gestiona la rotación de tokens de actualización ni su caducidad. La clase Auth de gramps-web es la referencia que se está siguiendo.
  • La experiencia de fusión/conflictos ante ediciones realmente simultáneas del mismo objeto es una cuestión de diseño abierta, aún sin resolver; el entorno de prueba dev-fixtures/layer3-sync/ (véase Desarrollo) existe precisamente para ejercitar este escenario. Al guardar, ahora se detecta si un registro cambió en el servidor desde que se abrió su formulario de edición y se rechaza sobrescribirlo (véase Modelo de datos y edición), pero eso es detección de conflictos, no resolución: todavía no hay forma de ver las dos versiones lado a lado ni de fusionarlas.
  • Una carencia de delegación de filtros en gramps-web-api: el endpoint más antiguo GrampsObjectsResource.get() sigue cargando incondicionalmente todos los objetos antes de aplicar filter/rules/gql/oql, un problema de rendimiento conocido en árboles muy grandes. Un endpoint más nuevo, ObjectQueryResource (del que dependen los propios endpoints /query/ de Gramps Connect y GOQL), ya delega realmente en SQL por otra ruta de código; si eso hace innecesario corregir el endpoint antiguo sigue siendo una cuestión abierta.
  • Un rediseño completo de la interfaz del modelo de objetos, un sistema de diseño propiamente dicho y la búsqueda como forma de navegación son direcciones que se están considerando, aún sin definir.

Ideas de funciones y pendientes

  • Permitir que los Gramplets editen o creen objetos, no solo que los lean (actualmente son de solo lectura mediante filter()/get_object()).
  • Admitir más tipos de complementos de Gramps además de los Gramplets: herramientas, informes.
  • Generar formularios PDF (necesitaría un importador de PDF).
  • Trasladar el proyecto a la organización gramps-project de GitHub; entre otras cosas, esto podría abrir la puerta a traducciones mediante la infraestructura de Weblate que ya tiene Gramps.
  • Elementos visitados recientemente.
  • Deshacer, ahora que el historial de cambios por objeto (véase Modelo de datos y edición) da a la interfaz un lugar desde el que ofrecerlo; una implementación real seguiría necesitando su propia revisión de corrección y de manejo de conflictos (qué significa «deshacer» cuando otra persona ha editado el registro desde entonces), no solo un botón conectado a los datos de diferencias existentes.
  • Enlaces <a href> reales para la navegación dentro de la aplicación (el título de un registro, «Abrir en su página de lista», ...) en lugar de los clics con aspecto de botón de hoy, para que funcionen el clic derecho nativo del navegador «Abrir en una pestaña nueva» y el clic central: útil para comparar dos registros lado a lado.
  • Un vínculo real, a nivel de Gramps, entre una superposición de imagen sobre el mapa y el lugar al que está asociada. Hoy el KML de la superposición incrusta el handle de la imagen de origen de una forma interna de la aplicación que el propio Gramps no puede ver, así que no aparecerá en una búsqueda de «referenciado por» y la herramienta de eliminar objetos no utilizados de Gramps de escritorio no sabrá que están relacionados; si la imagen se desvincula más tarde de todo lo demás que la referencia, la superposición se rompería sin aviso.
  • La edición de nombres alternativos de Lugar (véase Modelo de datos y edición) también permitiría que la visibilidad por fechas de una superposición del mapa se leyera de un nombre alternativo concreto en lugar de exigir un registro de lugar distinto por época; hoy, dos superposiciones con distintos rangos de fechas en el mismo punto físico necesitan cada una su propio lugar, ya que la fecha de un lugar está en su nombre (principal).

CI y control de compilaciones

Ahora se ejecuta un flujo de trabajo CI en cada push y pull request: pruebas, comprobación de tipos y una compilación, de modo que un commit roto se detecta automáticamente en lugar de depender de que alguien ejecute todo esto a mano. build-docker.yml y build-standalone.yml siguen siendo de activación manual (necesitan subir imágenes a un registro o runners específicos de cada plataforma, y no vale la pena gastarlos en cada commit). Todavía no hay ningún linter (ESLint/Prettier) configurado en el repositorio; si añadir uno se sigue como trabajo pendiente. Consulte Desarrollo para ver los comandos de pruebas y de comprobación de tipos que ejecuta la CI.

Dónde vive esta lista

Esta página es una instantánea. La versión de referencia, actualizada de forma continua, es TODO.md en el repositorio de gramps-connect: consúltela allí (y en el gestor de incidencias del repositorio) para conocer el estado actual antes de suponer que algo de esta lista sigue pendiente.

Clone this wiki locally