Tenant Config: tenantbrede instellingen

1. Config onderdelen

Tenantconfig overzicht

• Links wissel je tussen secties zoals branding, navigatie en integraties.
• Rechts staat steeds de actieve editor voor de gekozen tenantinstellingen.
• De theme preview helpt stylingwijzigingen direct te toetsen zonder live pagina's te openen.

Secties in de UI

• Branding en typografie
• Globale weergaveregels
• Standaardnotaties
• Uplink API-sleutels
• Git sync en tenantbrede repo-instellingen
• Themapresets en preview
• Licht en donker thema met groepen voor foundation, navigatie, controls, statussen, formulieren, vlakken/effecten en Dashbot
• Rapportkleuren
• Notificatie-e-mail

Deze handleiding volgt alleen de secties en velden die in de normale tenant-admin frontend zichtbaar zijn.

2. Branding en typografie

Gebruik deze sectie voor naam, logo en typografie die direct door de frontend worden overgenomen.

3. Globale weergaveregels

4. Standaardnotaties

5. Zoeken

De zoeksectie beheert hoe de topbar zoekgeschiedenis gebruikt voor autocomplete. Standaard is dit tenantbreed, zodat veelgebruikte zoekopdrachten voor iedereen in dezelfde tenant sneller beschikbaar zijn.

6. Uplink API keys

In deze sectie beheer je tenantgebonden API-sleutels voor de Uplink-ingestieservice. De UI is bewust ingericht rond veilig sleutelbeheer: Dashview bewaart alleen de hash en toont de ruwe sleutel alleen direct na genereren.

Git sync

Git sync maakt van een deel van je tenantconfiguratie een Git-beheerde gewenste staat. Niet-technische gebruikers kunnen gewoon via de web-UI blijven werken, terwijl technische gebruikers dezelfde configuratie ook via GitHub en een lokale IDE kunnen beheren.

Wat Git sync nu beheert

• Datasources
• Datasource schema-/categoriedefinities
• Dashboard pages en page views
• Elements
• Tenantconfiguratie zonder gevoelige server-side velden
• Tenant runtime vars

Deze resourcefamilies worden naar een canonieke repo-structuur geschreven. De repo is dus geen ruwe Firestore-dump, maar een leesbare configuratieboom met YAML en losse SQL-bestanden waar dat logisch is.

Verwachte repo-structuur

tenant.yaml
tenant-config/
  resource.yaml
runtime-vars/
  <var-id>/
    resource.yaml
datasources/
  <datasource-id>/
    resource.yaml
    query.sql
datasource-schemas/
  <schema-id>/
    resource.yaml
pages/
  <page-id>/
    resource.yaml
    views/
      <view-id>/
        resource.yaml
        query.sql
elements/
  <element-id>/
    resource.yaml
    main.py
    requirements.txt
    files/...

Eerste setup

1. Ga naar Administration → Config → Git sync.
2. Zet Git sync aan voor de tenant.
3. Vul Remote URL, Remote name en de standaardbranch in.
4. Kies of de remote publiek is of een GitHub token nodig heeft.
5. Sla de tenant Git sync instellingen op.
6. Ga daarna naar Administration → Git voor werkmapstatus, Open Branch-voorwaarden en operationele Git-acties.

Voor private GitHub repo’s gebruik je een GitHub token in de tenantconfiguratie. Dat token is dus voor git-server → GitHub authenticatie, niet voor eindgebruikerslogin in Dashview.

Bootstrap van een bestaande tenant

Gebruik Export naar werkmap wanneer een bestaande tenant nog niet volledig in de repo staat. Deze actie:

• schrijft de huidige ondersteunde tenantresources naar de repo in git-server
• vult ontbrekende mappen zoals tenant-config/ en runtime-vars/ aan
• laat de wijzigingen als gewone lokale Git-wijzigingen in je werkmap staan

Daarna review je de diff, maak je bewust een commit met je eigen commitbericht en push je die commit naar de gekozen branch.

Dagelijkse workflow in de web-UI

Na de bootstrap hoort normaal werk meestal niet meer via export te lopen. Gewone web-UI saves schrijven voor ondersteunde resourcefamilies al door naar de Git-werkmap van de gebruiker en maken de repo dus dirty. Gebruikers met Git Admin-permissie gebruiken Admin → Git om die user workspaces binnen de tenant te controleren, diffs te lezen en handmatige Git-acties uit te voeren. Automatische commits en pushes gebeuren alleen wanneer de gebruiker Auto Git aan heeft in Admin → Gebruikers.

• Commit: opent een dialoog waarin je zelf het commitbericht invult.
• Push: stuurt je lokale commits naar de remote branch.
• Pull: haalt de remote branch binnen in je gebruikerswerkmap.
• Apply: schrijft de huidige repo-inhoud terug naar de live tenantresources in Dashview.
• Reset: zet je gebruikerswerkmap hard terug naar de remote branch en gooit ongepushte lokale Git-wijzigingen weg.
• Export naar werkmap: gebruik je vooral voor backfill of wanneer je handmatig de huidige Firestore-status opnieuw naar Git wilt schrijven.

Repo-status lezen

• Clean betekent dat je werkmap geen niet-gecommitte wijzigingen heeft.
• X local changes betekent dat ondersteunde saves al in je werkmap staan maar nog niet gecommit zijn.
• X ahead / X behind vergelijkt je lokale branch met de remote branch.
• No remote branch yet betekent dat je lokale branch nog niet op remote bestaat.

Wat Apply wel en niet doet

• Wel: bestaande repo-bestanden opnieuw inlezen en die resources updaten in Dashview.
• Niet: de hele tenant exact spiegelen of alles verwijderen wat niet in Git staat.
• Niet: een lege repo interpreteren als “verwijder de tenant”.
• Niet: gewijzigde Elements automatisch publiceren; apply werkt alleen de draft bij.

Dat betekent dat Apply veiliger is dan een destructieve full reconcile. Je kunt wel een oudere versie van een page, datasource, Element, tenantconfig of runtime var terugzetten, maar niet per ongeluk de hele tenant weggooien doordat een map ontbreekt.

Lokale IDE workflow

Voor technische gebruikers is de gedeelde waarheid de externe Git remote, bijvoorbeeld GitHub. Je IDE werkt dus niet direct tegen de interne git-server repo, maar tegen dezelfde remote als Dashview.

1. Clone de GitHub repo lokaal.
2. Werk in een branch en push naar GitHub.
3. Ga terug naar Dashview en klik Pull.
4. Klik daarna Apply om de gepullte Git-status live te maken in Dashview.

De andere richting werkt ook: wijzigingen die je in Dashview maakt komen als lokale wijzigingen in de gebruikerswerkmap van git-server, waarna je zelf Commit en daarna Push uitvoert.

Branches en conflicts

• Branchwissels zijn per gebruiker/workspace.
• Een gewone branch switch gooit geen lokale wijzigingen weg.
• Open branch in Admin Git opent geen GitHub. De actie wisselt de Dashview-previewcontext naar de gekozen branch.
• Wisselen naar een bestaande branch preview past Git-bestanden niet automatisch toe op de draaiende preview tenant. Gebruik Apply wanneer je de huidige repo-status op die preview tenant wilt toepassen.
• De eerste switch naar een nieuwe branch preview bootstrapt die preview tenant eenmalig vanuit de branch.
• Als push of auto Git faalt door remote conflicts, gebruik dan Admin Git met Git Admin-permissie om conflictbestanden, relevante diff en aanbevolen stappen te bekijken voordat je wijzigt.
• Los conflicts op door de conflicted files te inspecteren, de final content te bewerken, resolved te markeren of te stagen, en daarna bewust te committen, pullen of pushen.
• Als je gewoon terug wilt naar de remote branch, gebruik dan Reset.

Reset is de expliciete destructieve actie. Dat is bewust: een simpele branchwissel mag niet stilletjes ongepushte lokale commits, merge-state of de draaiende configuratie van een bestaande preview tenant vervangen.

Tenant git-server keys

Tenant Git-server keys zijn niet hetzelfde als je GitHub token. Ze zijn bedoeld voor directe programmatische toegang tot git-server, bijvoorbeeld vanuit een CLI, CI-job of eigen script.

• GitHub token: laat git-server pull/push doen tegen je private GitHub repo.
• Tenant git-server key: laat een tool of script direct praten met git-server.

Gebruik je alleen de gewone Dashview web-UI en GitHub zelf, dan heb je die tenant key meestal niet nodig.

6. Themapresets en preview

7. Theme key reference (light & dark)

Dezelfde themavelden bestaan voor theme.light en theme.dark. In de UI werk je per modus met groepen zoals foundation, topbar/navigatie, tabellen, knoppen, widgets, notificaties, statussen, formulieren, vlakken/effecten en Dashbot.

• Foundation bevat de basistokens voor pagina, tekst, links en algemene accenten.
• Knoppen en Formulieren sturen de tenantbrede styling van primaire/severity-knoppen, dropdowns, multiselect chips en toggles.
• Statussen bevat semantische tokens voor succes, waarschuwing, fout, info, gedempt en geselecteerd. Deze worden gedeeld door meldingen, lege staten, selecties en widgetstatussen.
• Vlakken en effecten bevat gedeelde surfaces voor panels, dialogs, muted contentblokken, code editors, widgetglas, schaduwen en loaders.
• Widgets bevat widgetspecifieke kleurinstellingen zoals het chart palette en KPI comparison kleuren.
• Light en dark mode hebben elk hun eigen set waardes; wijzigingen gelden dus alleen voor de actieve modus.

8. Rapportkleuren

• Deze sectie bepaalt hoe rapportpagina's en geplande PDF's eruitzien buiten de normale appshell.
• De huidige UI heeft aparte velden voor pagina-achtergrond, widget-oppervlak, muted oppervlak, border, lijnkleur, primaire tekst, muted tekst en linkkleur.
• Gebruik dit voor rapportkoppen, achtergronden, tekst en accenten die goed moeten printen of mailen.
• Controleer na wijzigingen altijd een echte report route of geplande PDF.

9. Notificatie-e-mail