Wijzigingssets en Git

1. Eén live tenant, geïsoleerde wijzigingssets

Elke tenant heeft één canonieke live Git-revisie op de ingestelde hoofdbranch. Firestore is de exact toegepaste runtimeprojectie van die commit. Elke wijzigingsset hoort één-op-één bij een echte Git-branch en gebruikt een tenant-scoped previewlaag; er wordt geen verborgen previewtenant en geen persistente Git-werkmap gemaakt.

2. Workflow in Dashview

1. Maak via de topbar of Admin → Git een wijzigingsset. Dashview maakt meteen een branch vanaf de actuele hoofdbranch.
2. Kies een bestaand concept in de topbar om de preview direct te openen, of open het vanuit Admin → Git. Wijzig daarna dashboards, datasources, Elements, runtime vars, semantic contexts of eigen automations.
3. Wil je een grote gewijzigde datasource testen, kies dan in Administration → Datasources Draftcache opbouwen. Dashview bouwt een geïsoleerde parquetcache voor alleen deze wijzigingsset; de live cache en geplande refreshes blijven ongewijzigd.
4. Kies Controleren. Dashview vergelijkt elk resource-ID met de basis en huidige live versie.
5. Los elk conflict op met Concept behouden of Live gebruiken. De gekozen live basis wordt atomair opnieuw vastgelegd, zodat een volgende controle echt kan slagen.
6. Kies Publiceren. Dashview voegt de draftbranch samen met de actuele doelbranch, pusht zonder force en past vervolgens exact de resulterende commit live toe.
7. Kies Verwijderen wanneer de wijzigingen niet nodig zijn; live blijft dan ongewijzigd.

3. Externe Git-wijzigingen

Technische gebruikers kunnen dezelfde repo gewoon lokaal clonen, vanaf de geëxporteerde configuratie een branch maken, committen en pushen. Gebruik daarna de aparte actie Externe Git-branch importeren. Dashview importeert de branch in een tijdelijke checkout, valideert de configuratie en verwijdert de checkout weer.

• De branch moet al remote bestaan en een geldige tenant.yaml voor dezelfde tenant bevatten.
• Oudere Dashview-branches met een onvolledige resourceTypes-lijst worden veilig herkend. Aanwezige resources worden overgenomen, terwijl niet-gedeclareerde en ontbrekende resourcegroepen in het concept behouden blijven in plaats van als verwijderingen te worden gezien.
• Dashview valideert de volledige snapshot voordat bestaande conceptresources worden vervangen; een ontbrekende, lege of ongeldige branch kan daardoor niet als massale verwijdering worden geïnterpreteerd.
• Elke geslaagde wijziging in Dashview wordt automatisch op de achtergrond naar dezelfde featurebranch gecommit en gepusht; er is geen aparte synchronisatieknop. De wijziging zelf is al opgeslagen, zodat je kunt doorwerken. Snelle opeenvolgende saves worden samengevoegd tot de nieuwste wachtende revisie voordat Git wordt bijgewerkt.
• Bij openen of vernieuwen synchroniseert Dashview de branch met een three-way merge vanaf de laatst toegepaste commit. Niet-overlappende Git- en Dashview-wijzigingen worden automatisch samengevoegd.
• Wanneer beide kanten hetzelfde bestand wijzigden, kies je expliciet Git gebruiken of Dashview behouden. De remote branch wordt nooit geforceerd overschreven en een nieuwe commit tijdens de conflictcontrole blokkeert de sync.
• Publiceren mergt met de nieuwste doelbranch en gebruikt normale non-force Git-semantiek. Overlappende wijzigingen worden als conflict getoond.
• Als voor een bestaande repository nog geen canonieke live revisie bekend is, maakt Dashview eerst automatisch een volledige initiële commit vanuit de actuele live configuratie. Daarmee worden oude gedeeltelijke tenant.yaml-manifests veilig gemigreerd.
• Na die initialisatie wordt een externe wijziging op main bij de eerstvolgende Dashview-reconciliatie gevalideerd en als exacte live Firestore-projectie toegepast.
• Als een live editorwijziging met een externe commit botst, bewaart Dashview die wijziging op een herstelbranch, zet live terug op de erkende hoofdbranchcommit en toont de herstelbranch in Admin → Git.
• GitHub pull requests kunnen naast Dashview review worden gebruikt. Dashview maakt geen tenantclone per branch.

4. Scope en beveiliging

• Wijzigingssets zijn altijd tenant-scoped en alleen toegankelijk voor eigenaar, expliciete collaborators of bevoegde admins.
• Secrets, LLM-credentials, Git-remoteconfiguratie, notification credentials, runtime secrets, gebruikersrechten en forced filters worden niet in wijzigingssets of Git gekopieerd. Handmatig opgebouwde draftcaches zijn tijdelijke runtime-artifacts en geen Git-resources.
• Tenantconfig houdt gevoelige live waarden vast tijdens publiceren, ook wanneer de Git-snapshot die velden niet bevat.
• Een datasource-preview gebruikt eerst de draftconfiguratie rechtstreeks. Na Draftcache opbouwen gebruikt dezelfde preview het geïsoleerde cachepad en de geïsoleerde incremental checkpoints van die wijzigingsset. Publiceren of verwijderen ruimt deze tijdelijke cache op.
• Geplande parquetrefreshes blijven altijd live-only. Een wijzigingsset kan alleen via een handmatige, expliciet gekozen datasource worden gematerialiseerd en publiceert geen live zoekindex.
• Elementversies en geüploade draftbestanden blijven in de wijzigingsset geïsoleerd en worden bij publiceren met het Element overgenomen. Een Element-backed draftdatasource voert tijdens een draftcache-refresh de laatst gepubliceerde Elementversie uit dezelfde wijzigingsset uit; publiceer gewijzigde Elementcode dus eerst binnen het concept.
• Interactieve Autoflow-tests gebruiken draftdatasources en draft-gepubliceerde Elementversies; geplande productieruns blijven altijd op live configuratie draaien.
• Dashbot en MCP ontvangen alleen het actieve wijzigingsset-ID; de backend valideert het opnieuw tegen tenant en gebruiker.
• De oude branch-previewtenant- en gebruikerswerkmaproutes zijn verwijderd. Legacy previews worden door Cleaner opgeruimd.

Repo-URL, standaardbranch en authenticatie configureer je onder Tenant Config → Git sync.