Dashview Docs - Admin Tenant Config

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.

Deze pagina bundelt tenantbrede instellingen en werkt dus niet op individueel gebruikersniveau.

Secties in de UI

Branding en typografie
Globale weergaveregels
Standaardnotaties
Uplink API-sleutels
Git sync en tenantbrede repo-instellingen
Themapresets en preview
Licht thema en donker thema met subtabs per groep
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

UI veld	Payload key	Beschrijving
Tenant name	`name`	Weergavenaam van de tenant.
Logo	`logoUrl`	Topbar logo als URL of inline SVG.
Font family	`fontFamily`	Basisfont voor de UI.
Heading font family	`headingFontFamily`	Optioneel afwijkend font voor koppen.
Monospace font	`monoFontFamily`	Font voor code en editorinhoud.
Base font scale	`fontScale`	Globale fontschaal voor de hele omgeving.

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

3. Globale weergaveregels

Page color rules

Rule kind value of range.
Gebruik dit om paginakoppen of badges tenantbreed consistent te kleuren.
Handig voor statusvelden zoals kritiek, waarschuwing of percentageranges.

Page value rules

Ondersteunt exact en regex matching.
Kan tekst, HTML, SVG, PNG of icon-uitvoer teruggeven.
Gebruik dit voor consistente vervanging van bekende waarden of statussen.

Default chart colors

Fallback kleurenpalet voor charts wanneer pagina of widget geen eigen kleuren opgeeft.
Datasets pakken kleuren in volgorde uit deze lijst.
In de theme-editor staat dit palet nu onder de subtab Widgets, niet meer onder Foundation.

JSON editors

Een aantal configuraties heeft zowel formuliervelden als raw JSON.
Ongeldige JSON blokkeert opslaan.
Gebruik raw JSON alleen wanneer je veel regels tegelijk wilt plakken of herstructureren.

4. Standaardnotaties

Key	Gebruik
`uiLanguage`	Volledige producttaal van deze tenant, momenteel Nederlands of Engels.
`defaultNumberLocale`	Locale voor getalnotatie, bijvoorbeeld `nl-NL`.
`defaultNumberDigits`	Standaard Angular `digitsInfo` voor getallen en percentages.
`defaultCurrencyCode`	Fallback valuta zoals `EUR`.
`defaultCurrencyDisplay`	Weergave als symbool, code of smal symbool.
`defaultDateFormat`	Standaard datumformat voor widgets en detailweergaven.
`defaultDatetimeFormat`	Standaard datetimeformat.
`defaultTimeFormat`	Standaard tijdnotatie.
`timeZone`	Tenantbrede IANA-timezone, vooral relevant voor achtergrondruns, rapporten en niet-browserflows.

5. 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.

Per sleutel zichtbaar

Sleutel-ID om een sleutel herkenbaar te benoemen, bijvoorbeeld per bron of integratie.
Hash in sha256:...-vorm; dit is wat blijvend wordt opgeslagen.
Aangemaakt op en optioneel Ingetrokken op voor lifecycle-beheer.
Ruwe sleutel alleen meteen na genereren, zodat je die direct kunt kopiëren naar de externe client.

Beschikbare acties

Sleutel toevoegen maakt een extra sleutelblok aan in de lijst.
Genereren vult sleutel-ID, hash, created-at en een eenmalig zichtbare raw key.
Intrekken zet revokedAt zodat bestaande clients de sleutel niet meer moeten gebruiken.
Verwijderen haalt de sleuteldefinitie helemaal uit tenant config.

Gebruik screenshots of voorbeelden zonder echte secrets. Toon hoogstens een gemaskeerde raw key of een fictieve placeholder zoals dv_uplink_********.

Uplink API keys

De lijst toont sleutel-ID, hash en lifecycle-momenten zoals create of revoke.
Een raw key is alleen direct na creatie bruikbaar en moet daarna als geheim behandeld worden.
Gebruik revoke in plaats van overschrijven wanneer een key verdacht of verouderd is.

Documenteer of deel hier nooit echte secrets; alleen gemaskeerde of fictieve voorbeelden zijn veilig.

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.

Git sync is tenantbreed qua repo-instellingen, maar de actieve branch en werkmap zijn per gebruiker. Twee editors kunnen dus tegelijk aan dezelfde tenant werken zonder elkaars checkout direct te overschrijven.

Wat in Admin → Config blijft

Repo koppelen of aanpassen voor de tenant.
GitHub token of publieke remote instellen.
Tenant-sleutels aanmaken of intrekken voor directe git-server API-calls.
Repo-status, diff en recente commits controleren.
Export naar werkmap, Commit en Apply uitvoeren vanuit dezelfde beheerpagina.

Wat editors in de topbar doen

Branch wisselen of een nieuwe branch aanmaken.
Commit, Push, Pull, Apply en Reset uitvoeren zonder terug te gaan naar Admin.
De huidige branch, commit, dirty status en sync-status ten opzichte van remote zien.

Wat Git sync nu beheert

Datasources
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.

Secrets blijven buiten Git. Dat geldt ook voor gevoelige tenantconfig-velden zoals LLM-config en notification sender-credentials. Runtime vars kunnen wel in Git; runtime secrets niet.

Verwachte repo-structuur

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

Eerste setup

Ga naar Administration → Config → Git sync.
Zet Git sync aan voor de tenant.
Vul Remote URL, Remote name en de standaardbranch in.
Kies of de remote publiek is of een GitHub token nodig heeft.
Sla de tenant Git sync instellingen op.
Gebruik daarna Export naar werkmap als je een bestaande tenant voor het eerst in Git wilt zetten.

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, maar ze maken niet automatisch een commit.

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.

Voor Elements publiceert Apply niet automatisch. Als een repo-wijziging de saved draft van een bestaand gepubliceerd Element aanpast, blijft de laatste gepubliceerde version actief en verschijnt het Element in het overzicht als Updated draft. Publiceer het Element daarna handmatig om die draft live te maken.

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.

Clone de GitHub repo lokaal.
Werk in een branch en push naar GitHub.
Ga terug naar Dashview en klik Pull.
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.
Als push faalt door remote conflicts, los je die bij voorkeur op in GitHub of je lokale IDE op.
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 of merge-state weggooien.

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

Preset kiezen

Gebruik een preset als startpunt voor light en dark mode.
Pas daarna handmatig details aan voor topbar, sidebar, widgets en tabellen.

Preview en generator

De knop Preview tonen opent een los previewvenster.
Klik op onderdelen in de preview om direct naar het juiste themaveld te springen.
De zichtbaarheid en positie worden per gebruiker onthouden.
De sectie bevat ook een 4-kleuren generator om in één stap een light, dark of gecombineerd thema op te bouwen.

Theme presets en preview

Presetkeuze versnelt het opzetten van een eerste licht- en donker thema.
De losse preview toont componenten en navigatie buiten de editor zelf.
Controleer na themewijzigingen altijd hoverstates en contrast in beide modi.

Preview eerst, sla daarna pas op als de tenantkleuren in alle kerncomponenten logisch blijven.

7. Theme key reference (light & dark)

Dezelfde themavelden bestaan voor theme.light en theme.dark. In de UI werk je per modus met subtabs zoals foundation, topbar, sidebar, widgets en tabellen.

Foundation bevat de basistokens voor pagina, tekst, links en algemene accenten.
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.

Theme key	Gebruik
`primary`, `secondary`	Hoofdaccenten voor knoppen, links en actieve staten.
`topbarBackground`, `topbarText`, `topbarButton*`, `topbarBadgeBackground`	Topbar basisstijl en knoppen.
`pageBackground`, `pageText`, `pageSecondaryText`	Hoofdachtergrond, standaard tekstkleur en secundaire tekstkleur voor subtitels en muted tekst.
`sidebarBackground`, `sidebarText`, `sidebarHoverBackground`, `sidebarTextActive`	Zijbalkkleuren en hover/actieve staten.
`chartPalette`	Fallback grafiekkleuren voor chartwidgets. In de editor vind je dit onder Widgets.
`kpiComparePositiveBackground`, `kpiComparePositiveText`, `kpiComparePositiveIcon`, `kpiCompareNegativeBackground`, `kpiCompareNegativeText`, `kpiCompareNegativeIcon`	Kleuren voor KPI-vergelijkingschips en pijliconen. Deze gelden ook wanneer een KPI-widget de compare-kleuren omdraait.
`tableHeader`, `tableScrollbar`, `tableCellProgress*`	Tabelheaders, scrollbar en celprogressie.
`buttonBackground`, `buttonText`, `buttonHoverBackground`	Primaire knopstijl.
`buttonSecondary`, `buttonSuccess`, `buttonWarn`, `buttonInfo`, `buttonDanger`, `buttonError`, `buttonHelp`, `buttonContrast`	Severity-specifieke knopkleuren inclusief hoverteksten.
`dashbotAssistantBubble`, `dashbotUserBubble`	Kleuren voor Dashbot-berichten.

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

Wat tenant-admins beheren

Tenantnotificatie-e-mail inschakelen voor de tenantconfiguratie.
Onderwerp-prefix voor uitgaande rapport- en notificatiemails.
Optionele templates voor scheduled report, task en direct notification.
Token-insertie via klik of drag-and-drop naar onderwerp, HTML of platte tekst.

Beheeradvies

Werk vooral aan enable/disable, subject prefix en de inhoudelijke templates.
Gebruik tokens consequent in onderwerp, HTML en plain-text varianten.
Verstuur na wijziging een testnotificatie of geplande rapportmail om HTML en plain-text fallback te controleren.

Tenant Config: tenantbrede instellingen

1. Config onderdelen

Secties in de UI

2. Branding en typografie

3. Globale weergaveregels

Page color rules

Page value rules

Default chart colors

JSON editors

4. Standaardnotaties

5. Uplink API keys

Per sleutel zichtbaar

Beschikbare acties

Git sync

Wat in Admin → Config blijft

Wat editors in de topbar doen

Wat Git sync nu beheert

Verwachte repo-structuur

Eerste setup

Bootstrap van een bestaande tenant

Dagelijkse workflow in de web-UI

Repo-status lezen

Wat Apply wel en niet doet

Lokale IDE workflow

Branches en conflicts

Tenant git-server keys

6. Themapresets en preview

Preset kiezen

Preview en generator

7. Theme key reference (light & dark)

8. Rapportkleuren

9. Notificatie-e-mail

Wat tenant-admins beheren

Beheeradvies