Pubblica e condividi

Pubblicare è il passaggio di consegne dal tuo harness alla piattaforma gestita: la dashboard smette di essere l'output di un agente e diventa qualcosa su cui il tuo team può contare — un URL stabile, governato dai tuoi diritti di accesso, che continua a rispondere anche dopo la fine della sessione.

Draft e main sono veri branch git

Non è una metafora. Ogni dashboard è un repository git, conservato come bare repo nello storage a oggetti. Le tue modifiche — dal tuo agente, dall'assistente integrato nell'app, dall'editor di codice — sono commit su un branch draft. Pubblicare fa il merge di quel draft in main.

Tre conseguenze da tenere in conto:

• Non puoi scrivere direttamente su main. Le scritture verso di esso vengono rifiutate; l'unico modo in cui il contenuto raggiunge la versione live è una pubblicazione.
• Ogni pubblicazione crea un tag di versione. Il tag registra lo stato in cui si trovava main prima del merge — quindi v1 è ciò che la tua prima pubblicazione ha sostituito, v2 è ciò che la tua seconda pubblicazione ha sostituito, e la versione attualmente live è main, senza tag fino alla prossima pubblicazione.
• Le pubblicazioni concorrenti fanno merge invece di sovrascriversi. Se main si è spostato mentre il tuo draft era aperto e i due hanno toccato file diversi, entrambi gli insiemi di modifiche vengono applicati. Se hanno toccato lo stesso file in modo incompatibile, la pubblicazione fallisce con 409 PUBLISH_MERGE_CONFLICT e indica i percorsi in conflitto. Non sceglie un vincitore silenziosamente.

Puoi leggere questa cronologia:

print(client.viz.list_tags(viz_id))
print(client.viz.get_commit_log(viz_id, "main", max_count=20))
print(client.viz.preview_publish(viz_id))   # diff between draft and main

console.log(await client.viz.listTags(vizId));
console.log(await client.viz.getCommitLog(vizId, 'main', { maxCount: 20 }));
console.log(await client.viz.previewPublish(vizId));

Pubblica una dashboard

Il tuo agente può farlo direttamente via MCP; nell'app è il pulsante Pubblica; da codice è una singola chiamata:

client.viz.publish(viz_id)

await client.viz.publish(vizId);

La pubblicazione esegue prima un controllo di integrità sull'ultima build della dashboard. Se il bundle è FAILED o obsoleto, la pubblicazione viene rifiutata con un 409 invece di promuovere qualcosa che non si visualizza — passa force=true per bypassare questo controllo deliberatamente.

La pubblicazione poi fa merge, tagga e avvia una build. Lo stato diventa PUBLISHED solo quando quella build ha successo; se fallisce, la dashboard finisce in ERROR e main viene ripristinato. Quindi il ritorno di publish() non è lo stesso fatto di "la dashboard è live" — rileggi publishStatus prima di dire a chiunque che il link funziona. (Stessa regola di refresh che restituisce 202: il completamento della chiamata e il completamento del lavoro sono due cose diverse.)

Chi può aprirla — tre modalità, non due

Pubblicare decide che la dashboard è live. Un campo separato, viewMode, decide chi può aprirla. Confondere questi due aspetti è l'errore più comune qui.

viewMode	Chi può aprirla
public	Chiunque abbia il link. Nessun account richiesto.
protected	Solo un visualizzatore per cui il tuo backend ha generato un token di embed — con filtri per riga per singolo visualizzatore. Vedi Incorporare.
private	Nessuno al di fuori del tuo account. Pubblicata, ma non raggiungibile dalla superficie pubblica.

Il link di una dashboard pubblicata ha questo aspetto:

https://cloud.vibedasher.com/v/<slug>

Quell'URL serve contenuti solo quando la dashboard è sia pubblicata sia public. Una dashboard protected sullo stesso URL richiede un token aggiunto.

Rendere pubblica una dashboard è vincolato separatamente, e un agente non può farlo da solo

Rendere i dati aziendali leggibili da chiunque al mondo è l'unica cosa irreversibile in tutto questo flusso, quindi ha un proprio blocco invece di viaggiare insieme a publish. Due interruttori, entrambi sull'account, entrambi verificati lato server su ogni route che può scrivere viewMode:

• allowForPublicViz — un interruttore di emergenza a livello di account. Disattivalo e nulla nell'account può essere reso pubblico, da nessuno, tramite nessuna route.
• apiKeysMayPublish — il valore predefinito è false. Anche quando la condivisione pubblica è consentita, un chiamante che si autentica con una chiave API potrebbe non essere colui che rende pubblica una dashboard. Un admin deve attivarlo, e può farlo solo da una sessione browser — PUT /v1/account rifiuta di impostarlo da una chiave API, quindi l'interruttore non può abilitarsi da solo.

Il secondo è il punto cruciale. Altrove su questa piattaforma, una chiave API agisce come l'utente che l'ha creata, con il ruolo completo di quell'utente (vedi Chi può vedere cosa). Pubblicare sull'internet aperto è l'eccezione deliberata: il tuo agente può costruire la dashboard, pubblicarla e condividerla dentro il tuo account, ma per impostazione predefinita non può essere ciò che la rende pubblica. Un essere umano in un browser deve aver detto sì una volta, a livello di account.

Il codice è congelato; i dati no

Questa è la proprietà che rende una dashboard pubblicata degna di essere ospitata piuttosto che esportata.

Il codice della dashboard viene fotografato al momento della pubblicazione. Il bundle viene costruito una volta e servito dallo storage. Il tuo draft continua a evolversi indipendentemente e non trapela nella versione live finché non pubblichi di nuovo.

I dati vengono letti live al momento della visualizzazione. Ogni grafico su una dashboard pubblicata interroga il contenuto attuale dei suoi dataset quando qualcuno la apre. Un aggiornamento che arriva alle 3 del mattino appare sulla dashboard pubblicata alle 9 senza nulla da ricostruire e senza che nessuno sia coinvolto. Questa è l'intera ragione per cui la metà dati vive nella piattaforma — vedi Mantieni i tuoi dati aggiornati.

Annulla la pubblicazione e ripubblica

DELETE /v1/viz/{id}/publish rimuove la dashboard: lo stato torna a NOT_PUBLISHED e il bundle live viene rimosso. Il tuo draft resta intatto.

• Lo slug viene mantenuto e resta riservato, quindi ripubblicare riutilizza lo stesso URL.
• I vecchi link falliscono in modo incoerente. La pagina del visualizzatore risponde 404, l'API pubblica risponde 403, e gli endpoint di dati in cache rispondono 404. Se gestisci questo caso programmaticamente, non ramificare solo in base al codice di stato.
• Rinominare lo slug rompe permanentemente ogni link esistente. Non c'è alcun redirect da un vecchio slug a uno nuovo. Scegli lo slug prima di far circolare l'URL.

Incorporala

Le dashboard pubblicate si visualizzano tramite un iframe incorporabile che puoi inserire in qualsiasi app, pagina di documentazione o sito web — pubblico, o vincolato per singolo visualizzatore con filtri per riga. Vedi Incorporare una dashboard.