jappel/leistungsbilanz-ts
1
0
Fork 1
Code Issues 6 Pull requests Projects Releases Packages Wiki Activity Actions

Gebäudestruktur: neue Ebene „Gebäude“ über Etagen und eigene Seite Gebäude → Etagen → Räume #6

New issue
Closed
opened 2026-09-26 12:17:42 +02:00 by Grovy311 · 2 comments
Grovy311 commented 2026-09-26 12:17:42 +02:00
Collaborator
Copy link

Ziel

Projekte mit mehreren Gebäuden sollen sich sauber gliedern lassen. Dafür bekommen Etagen eine übergeordnete Ebene Gebäude. Die Pflege von Gebäuden, Etagen und Räumen zieht von der Projektübersicht auf eine eigene Seite mit eigenem Eintrag in der Seitenleiste.

Bevor ich das als Branch baue, würde ich gern mit dir abstimmen, ob das Datenmodell so in dein System passt. Es berührt Befehle, Snapshots und Transfer.

Vorschlag Datenmodell

  • neue Tabelle buildings: id, project_id (FK, cascade), name, sort_order
  • floors.building_id: nullable FK auf buildings. Bestehende Etagen bleiben ohne Gebäude und erscheinen als „Ohne Gebäude“. Es gibt keine Zwangsmigration und kein automatisch angelegtes Standardgebäude.
  • Räume und Verteilungen bleiben an der Etage. Das Gebäude ergibt sich aus der Etage, eine zweite Zuordnung gibt es nicht.

Befehle, Undo/Redo, Snapshots

  • neue Befehle nach dem Muster von project-floor.*: project-building.insert, project-building.update, project-building.delete, jeweils mit Inverse
  • project-floor.update bzw. project-floor.insert bekommen buildingId als neue Payload-Version. Die alte Version bleibt lesbar, ein fehlendes Feld behält den aktuellen Wert, so wie bei project.update-settings v2 → v3.
  • Löschen eines Gebäudes mit zugeordneten Etagen wird abgelehnt, analog zu Etagen mit Räumen oder Verteilungen.
  • Projekt-Snapshot und Transfer: Schema 7 mit buildings und floor.buildingId. Ältere Snapshots laufen über den Upgrade-Pfad mit leerer Gebäudeliste und buildingId = null.
  • Basis wäre feature/print-view, weil dort Migration 0007/0008 und Snapshot-Schema 6 liegen. Die Migration wäre dann 0009.

Oberfläche

  • neue Seite /projects/:projectId/struktur mit drei Spalten Gebäude → Etagen → Räume
    • Klick auf ein Gebäude zeigt nur dessen Etagen, Klick auf eine Etage nur deren Räume, „Alle“ hebt den Filter auf
    • in jeder Spalte Hinzufügen/Bearbeiten/Löschen mit Icons wie in der Stromkreisliste
  • Seitenleiste: neuer Eintrag „Gebäudestruktur“. Die Anker „Etagen“ und „Räume“ und die beiden Karten verschwinden aus der Projektübersicht, die KPI-Kacheln verlinken auf die neue Seite.
  • Etagenauswahl in Verteilungs- und Raumdialogen gruppiert nach Gebäude

Fragen an dich

  1. Passt eine eigene Tabelle buildings mit nullable floors.building_id, oder hast du für Gebäude schon etwas anderes vorgesehen, etwa aus Revit?
  2. Revit: Soll das Gebäude später aus einem Revit-Parameter kommen (z. B. Projekt- oder Ebenenparameter) und über die bestehende CSV-Zuordnung gemappt werden?
  3. Löschen: ablehnen, wenn Etagen zugeordnet sind (Vorschlag), oder Etagen auf „Ohne Gebäude“ zurücksetzen?
  4. Ist Schema 7 für Snapshot/Transfer für dich okay, oder willst du Schemaänderungen bündeln?

Wenn das für dich passt, baue ich es als Branch feature/building-structure mit Tests und Doku, wie bei den anderen Branches.

## Ziel Projekte mit mehreren Gebäuden sollen sich sauber gliedern lassen. Dafür bekommen Etagen eine übergeordnete Ebene **Gebäude**. Die Pflege von Gebäuden, Etagen und Räumen zieht von der Projektübersicht auf eine **eigene Seite** mit eigenem Eintrag in der Seitenleiste. Bevor ich das als Branch baue, würde ich gern mit dir abstimmen, ob das Datenmodell so in dein System passt. Es berührt Befehle, Snapshots und Transfer. ## Vorschlag Datenmodell - neue Tabelle `buildings`: `id`, `project_id` (FK, cascade), `name`, `sort_order` - `floors.building_id`: nullable FK auf `buildings`. Bestehende Etagen bleiben ohne Gebäude und erscheinen als „Ohne Gebäude“. Es gibt keine Zwangsmigration und kein automatisch angelegtes Standardgebäude. - Räume und Verteilungen bleiben an der Etage. Das Gebäude ergibt sich aus der Etage, eine zweite Zuordnung gibt es nicht. ## Befehle, Undo/Redo, Snapshots - neue Befehle nach dem Muster von `project-floor.*`: `project-building.insert`, `project-building.update`, `project-building.delete`, jeweils mit Inverse - `project-floor.update` bzw. `project-floor.insert` bekommen `buildingId` als neue Payload-Version. Die alte Version bleibt lesbar, ein fehlendes Feld behält den aktuellen Wert, so wie bei `project.update-settings` v2 → v3. - Löschen eines Gebäudes mit zugeordneten Etagen wird abgelehnt, analog zu Etagen mit Räumen oder Verteilungen. - Projekt-Snapshot und Transfer: Schema 7 mit `buildings` und `floor.buildingId`. Ältere Snapshots laufen über den Upgrade-Pfad mit leerer Gebäudeliste und `buildingId = null`. - Basis wäre `feature/print-view`, weil dort Migration 0007/0008 und Snapshot-Schema 6 liegen. Die Migration wäre dann 0009. ## Oberfläche - neue Seite `/projects/:projectId/struktur` mit drei Spalten **Gebäude → Etagen → Räume** - Klick auf ein Gebäude zeigt nur dessen Etagen, Klick auf eine Etage nur deren Räume, „Alle“ hebt den Filter auf - in jeder Spalte Hinzufügen/Bearbeiten/Löschen mit Icons wie in der Stromkreisliste - Seitenleiste: neuer Eintrag „Gebäudestruktur“. Die Anker „Etagen“ und „Räume“ und die beiden Karten verschwinden aus der Projektübersicht, die KPI-Kacheln verlinken auf die neue Seite. - Etagenauswahl in Verteilungs- und Raumdialogen gruppiert nach Gebäude ## Fragen an dich 1. Passt eine eigene Tabelle `buildings` mit nullable `floors.building_id`, oder hast du für Gebäude schon etwas anderes vorgesehen, etwa aus Revit? 2. Revit: Soll das Gebäude später aus einem Revit-Parameter kommen (z. B. Projekt- oder Ebenenparameter) und über die bestehende CSV-Zuordnung gemappt werden? 3. Löschen: ablehnen, wenn Etagen zugeordnet sind (Vorschlag), oder Etagen auf „Ohne Gebäude“ zurücksetzen? 4. Ist Schema 7 für Snapshot/Transfer für dich okay, oder willst du Schemaänderungen bündeln? Wenn das für dich passt, baue ich es als Branch `feature/building-structure` mit Tests und Doku, wie bei den anderen Branches.
Grovy311 commented 2026-09-26 13:12:49 +02:00
Author
Collaborator
Copy link

Branch vorbereitet: feature/building-structure (Basis feature/print-view).

Umgesetzt wie oben vorgeschlagen:

  • buildings + nullable floors.building_id (Migration 0009)
  • project-building.insert/.update/.delete mit Inversen; Löschen wird bei zugeordneten Etagen abgelehnt
  • Etagenbefehle Version 2 mit buildingId. Version-1-Befehle aus bestehender Historie werden vor Ausführung und Speicherung mit buildingId = null hochgestuft; Vorwärts- und Inversbefehl haben dadurch dieselbe Version.
  • Snapshot-Schema 7, Upgrade von 1–6 ohne Gebäude; Restore und Transfer inklusive Gebäude
  • Seite /projects/:id/struktur mit drei Spalten, die sich gegenseitig filtern; die Seitenleiste bleibt auf allen Seiten außer der Seitenansicht sichtbar
  • Doku: docs/building-structure.md, API-Doku, AGENTS.md

Geprüft: alle drei tsc-Konfigurationen, npm test 448/448 auf dem Branch, 480/480 zusammen mit den übrigen offenen Branches, Produktions-Build, Migration auf einer bestehenden Datenbank, Browsertest (Anlegen, Zuordnen, Filtern, Löschsperre, Undo/Redo).

Deine Fragen 1–4 oben sind weiter offen. Das Datenmodell lässt sich noch ändern, solange der Branch nicht gemergt ist.

Branch vorbereitet: `feature/building-structure` (Basis `feature/print-view`). Umgesetzt wie oben vorgeschlagen: - `buildings` + nullable `floors.building_id` (Migration `0009`) - `project-building.insert/.update/.delete` mit Inversen; Löschen wird bei zugeordneten Etagen abgelehnt - Etagenbefehle Version 2 mit `buildingId`. Version-1-Befehle aus bestehender Historie werden vor Ausführung und Speicherung mit `buildingId = null` hochgestuft; Vorwärts- und Inversbefehl haben dadurch dieselbe Version. - Snapshot-Schema 7, Upgrade von 1–6 ohne Gebäude; Restore und Transfer inklusive Gebäude - Seite `/projects/:id/struktur` mit drei Spalten, die sich gegenseitig filtern; die Seitenleiste bleibt auf allen Seiten außer der Seitenansicht sichtbar - Doku: `docs/building-structure.md`, API-Doku, AGENTS.md Geprüft: alle drei `tsc`-Konfigurationen, `npm test` 448/448 auf dem Branch, 480/480 zusammen mit den übrigen offenen Branches, Produktions-Build, Migration auf einer bestehenden Datenbank, Browsertest (Anlegen, Zuordnen, Filtern, Löschsperre, Undo/Redo). Deine Fragen 1–4 oben sind weiter offen. Das Datenmodell lässt sich noch ändern, solange der Branch nicht gemergt ist.
jappel commented 2026-09-27 11:17:35 +02:00
Owner
Copy link

Danke, das passt so, wie es umgesetzt ist. Integriert mit #16 (Merge-Commit 868f48e7ac).

  1. Datenmodell: Die eigene Tabelle buildings mit optionalem floors.building_id ist bestätigt. Räume und Verteilungen bleiben an der Etage, das Gebäude ergibt sich daraus.
  2. Revit: Eine Übernahme des Gebäudes aus Revit ist derzeit nicht geplant. Die Revit-Arbeit ist insgesamt zurückgestellt und läuft später über die CSV des Linear-Plugins, nicht über Dynamo (siehe docs/spec/revit-csv-integration-requirements.md, Abschnitt 1).
  3. Löschen: Das Ablehnen bei zugeordneten Etagen bleibt so, analog zu Etagen mit Räumen oder Verteilungen.
  4. Snapshot-Schema 7: okay, eine Bündelung ist nicht nötig.

Die Doku ist nachgezogen: 57a62b7e4a.

Danke, das passt so, wie es umgesetzt ist. Integriert mit #16 (Merge-Commit 868f48e7aca9c5a19566d1ba63a1ec9f8915519d). 1. **Datenmodell:** Die eigene Tabelle `buildings` mit optionalem `floors.building_id` ist bestätigt. Räume und Verteilungen bleiben an der Etage, das Gebäude ergibt sich daraus. 2. **Revit:** Eine Übernahme des Gebäudes aus Revit ist derzeit nicht geplant. Die Revit-Arbeit ist insgesamt zurückgestellt und läuft später über die CSV des Linear-Plugins, nicht über Dynamo (siehe `docs/spec/revit-csv-integration-requirements.md`, Abschnitt 1). 3. **Löschen:** Das Ablehnen bei zugeordneten Etagen bleibt so, analog zu Etagen mit Räumen oder Verteilungen. 4. **Snapshot-Schema 7:** okay, eine Bündelung ist nicht nötig. Die Doku ist nachgezogen: 57a62b7e4ae90d234a3e7caafebf5de4ddc7e46b.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
security-baseline
feat/tab-icon
archive/dynamo-vorueberlegungen
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: jappel/leistungsbilanz-ts#6
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?