Salta ai contenuti

Calendario e pianificazione

Control Center si collega a Google Calendar per tenere la tua giornata accanto alla tua flotta. Sincronizza i tuoi eventi, li mostra nelle viste mese, settimana, giorno e agenda, ti avvisa prima dell’inizio di una riunione e trasforma qualsiasi evento in una riunione registrata e riassunta.

Quasi nulla. L’integrazione importa gli eventi e li visualizza. Non li crea, non li modifica, non li elimina e non risponde agli inviti. Ogni connessione con codice dispositivo, integrata o con credenziali proprie, richiede calendar.readonly più openid email.

Gli eventi vengono sincronizzati nel database dello spazio di lavoro sul server (<dataDir>/<workspaceId>/workspace.db) e visualizzati da ogni client tramite RPC. Nessun client conserva credenziali Google.

Gli account del calendario sono legati allo spazio di lavoro, come tutto il resto in Control Center. Ogni spazio di lavoro collega il proprio account Google (o più di uno) e gli eventi e i token di uno spazio non sono mai visibili da un altro. Cambiando spazio di lavoro cambiano i calendari che vedi.

Uno spazio di lavoro può collegare più account Google, ad esempio un account di lavoro e uno personale, e i loro eventi confluiscono nelle stesse viste.

Perché l’accesso avviene con un codice dispositivo

Sezione intitolata “Perché l’accesso avviene con un codice dispositivo”

Il cc_server headless non ha un browser che possa intercettare un redirect OAuth. Quindi non ne usa uno: si autorizza con la concessione del codice dispositivo (RFC 8628). Il server mostra un breve codice utente e un URL di Google, tu approvi da qualsiasi dispositivo dotato di browser e il server esegue il polling finché non lo fai. Un’installazione headless può collegare un account proprio perché non c’è alcun endpoint di redirect da ospitare.

La conseguenza da conoscere prima di usare le tue credenziali: il tipo di client deve essere “TV and Limited Input devices” di Google. Google concede a quel tipo di client solo un insieme di scope esplicitamente consentito e un progetto in cui Calendar non è abilitato per quel tipo di client fallisce con invalid_scope — ti servirebbe invece un client loopback o web.

I token non lasciano mai il server. Vengono scritti nel secrets.json del server, nella sua directory dati, con chiave google_google:<workspaceId>:<email>, accanto ai database e sotto lo stesso confine di fiducia del filesystem dell’host. Il server aggiorna l’accesso automaticamente e, quando Google invalida definitivamente un account (una sessione revocata o scaduta da tempo), pubblica CalendarAuthExpired e mostra un banner Riconnetti invece di fallire in silenzio.

Una build dai sorgenti non include nessuna credenziale Google — client id e secret li fornisci tu. Le build di rilascio ufficiali integrano un client con codice dispositivo non riservato, così il flusso di connessione funziona da subito; il server memorizza solo un marcatore che lo referenzia, mai una copia. GOOGLE_OAUTH_CLIENT_ID (e il suo secret) nell’ambiente ha sempre la precedenza sulla coppia integrata. Non esiste deliberatamente un flag --google-client-id: i flag sconosciuti vengono ignorati, e un secret sulla riga di comando è leggibile tramite ps.

Per usare un tuo progetto Google, vedi Collega un Google Calendar.

Il server preleva una finestra mobile degli eventi di ogni account collegato — tutti i calendari dell’account, non solo quello principale — ogni due minuti, più su richiesta (avvio, connessione, aggiornamento manuale). La cadenza breve è sostenibile perché la scansione è incrementale: ogni calendario ha il proprio token di sincronizzazione, quindi un calendario invariato costa una risposta quasi vuota invece di riscaricare una finestra di cinque mesi.

Gli eventi ricorrenti vengono espansi lato server, quindi nessun client interpreta mai una regola di ricorrenza. Spostandoti su un mese fuori dalla finestra corrente, quell’intervallo viene caricato in modo lazy. Gli eventi eliminati o usciti dall’intervallo vengono riconciliati via alla sincronizzazione successiva.

Vista Cosa mostra
Mese Una griglia mensile completa (basata sul pacchetto kalender)
Settimana Gli eventi con orario di una settimana in una griglia oraria
Giorno Gli eventi con orario di un singolo giorno in una griglia oraria
Agenda Un elenco scorrevole dei prossimi eventi

Apri il calendario su /calendar; selezionando un evento si apre il suo dettaglio su /calendar/:eventId. La vista che scegli è memorizzata nelle preferenze di quel client, quindi non ti segue su un altro dispositivo.

Un pianificatore al minuto cerca gli eventi che iniziano entro una finestra di preavviso configurabile e invia una notifica “Riunione in arrivo” (un evento di dominio MeetingStartingSoon). La notifica contiene l’URL di partecipazione, quando presente, e facendo clic si apre il dettaglio dell’evento. Gli avvisi sono deduplicati rispetto a alertedAt dell’evento, quindi la stessa riunione non avvisa mai due volte, nemmeno tra riavvii, e un evento la cui ora di inizio è passata mentre l’app era chiusa non viene mai riproposto.

Due limiti sono facili da incontrare. Il pianificatore gira lato client sul desktop e solo per lo spazio di lavoro che hai aperto in quel momento — uno spazio in cui non ti trovi non genera alcun avviso. E la build web non ha alcuna pipeline di notifiche di sistema, quindi non ne genera nessuna neppure lei.

Da un evento del calendario puoi avviare una registrazione di riunione inizializzata con il titolo dell’evento. Control Center memorizza un collegamento uno-a-uno tra la registrazione e l’evento, così le note della riunione e la voce di calendario restano collegate senza che l’una dipenda dall’altra.

Registra e collega è disponibile solo su desktop. Nel client web l’azione segnala che la registrazione non è disponibile — anche se il flusso di registrazione della schermata Riunioni funziona nel browser.