Skip to content

ADR-0030: QGIS-Plugin als Capture-UI, DB pro Organisation

  • Status: accepted
  • Datum: 2026-08-27
  • Phase: QGIS Plugin / Multi-Tenant
  • Bezug: ADR-0002 (PgBouncer mTLS), ADR-0008 (QGIS-Export), ADR-0025 (Schema-CMS), ADR-0026 (Import)

Kontext

Der Tauri-Editor liefert vor allem Datenmodell, Schema-CMS, Import-Mapper und Projekt-/Layer-Hierarchie. GIS-Erfassung (Canvas, Digitize, Snapping) ist in QGIS stärker. Planer sollen nur QGIS nutzen und dort ein Linetra-Plugin installieren — keine zweite Desktop-App.

Isolation: eine Organisation / Kunde = eine Postgres-Datenbank; Planer derselben Org teilen die DB vollständig (keine Tabellen-/Spalten-Isolation). Dashboard und Bauleiter-App bleiben Hybrid-Clients über FastAPI gegen dieselbe(n) Tenant-DB(s).

Entscheidung

  1. Capture-UI: PyQGIS-Plugin unter Workspace-Pfad linetra-plugin/. Läuft ausschließlich in QGIS nach Installation (ZIP/Symlink). Kein Companion-Prozess. Zielversionen: QGIS 3.40 LTR und QGIS 4.2 (eine Codebasis, Qt5/Qt6 scoped enums; qgisMaximumVersion=4.99).
  2. Plugin liefert: Verbindungsassistent (Client-Zertifikat → PgBouncer), API-Login, Projektwahl, Layer/Feature-Hierarchie (Stage-Gruppen), Schema-CMS-UI, GIS-Import-Mapper. Schema-Schreiben über FastAPI (ADR-0025); Geometrie-Schreiben über QGIS Postgres-Provider.
  3. QGIS liefert: Canvas, Digitize, Snapping, Layout, Analyse.
  4. Multi-Tenant (Ziel): DB linetra_<slug> pro Organisation; Control-Plane-DB für Tenants, app_users, Cert-Metadaten. Cert pro Person/Gerät; Mapping auf Tenant-Rolle + dbname (ADR-0002 teils superseded).
  5. MVP-Backend: ~~eine DB linetra, Cert→linetra_edit / linetra_read.~~ Superseded durch ADR-0031: Control-DB linetra, Fach-DB linetra_<slug>, Cert-CN {slug}_edit / {slug}_read.
  6. Tauri-Editor: nicht Primärpfad für GIS-Erfassung; Wartung, kein Feature-Paritätsziel zum Plugin.

Begründung

Branchenüblich ist QGIS + Fach-Plugin für Schema/Workflow, nicht ein paralleler Web-Canvas. Database-per-tenant gibt starke Kundenisolation ohne RLS; Hybrid-API hält Dashboard/App konsistent. Plugin-only UX erfüllt „nur QGIS installieren“.

Verworfene Alternativen

Alternative Warum verworfen
Tauri-Editor bleibt Primär-Capture Doppelter Canvas; Nutzer wollen QGIS
React/WebEngine-Dock in QGIS Fremde UX; doppelte Map
Shared DB + RLS Widerspricht „keine Isolation in der DB“; komplex für QGIS
Schema-per-tenant Schwächere Isolation; verwirrende search_path-Setups
Nur API, kein Live-Postgres für QGIS Digitize über HTTP unnötig langsam; Value Relations brauchen Tabellen
Schema nur per QGIS DB-Manager DDL Drift zu FastAPI/Dashboard (ADR-0025)
Companion-Desktop neben QGIS Widerspricht „nur QGIS“

Folgen

  • Code: linetra-plugin/ (Host-Python/QGIS, kein Compose).
  • Docs/Lastenheft: QGIS+Plugin = Capture; Export (ADR-0008) bleibt Zusatz.
  • ADR-0002: weiter PgBouncer mTLS; künftig Cert→Tenant-Rolle+dbname statt global eine DB.
  • Folgearbeit: Control Plane, CREATE DATABASE, Cert-Bind, Alembic pro Tenant.
  • 2026-09: Schema-Schreiben liegt in Linetra Web (ADR-0033). Das Plugin liest das effektive Projektschema und wendet Layer/Formulare an; Kind-Create im Plugin entfällt. Isolation bleibt eine Org-DB, nicht eine DB pro Projekt.