Saltar para o conteúdo

Calendário e agendamento

O Control Center liga-se ao Google Calendar para que o seu dia fique ao lado da sua frota. Sincroniza os seus eventos, mostra-os nas vistas de mês, semana, dia e agenda, avisa-o antes de uma reunião começar e transforma qualquer evento numa reunião gravada e resumida.

Quase nada. A integração importa os eventos e apresenta-os. Não cria, edita, elimina nem responde a convites. Todas as ligações device-code, incorporadas ou com as suas próprias credenciais, pedem calendar.readonly e openid email.

Os eventos são sincronizados para a base de dados do próprio espaço de trabalho no servidor (<dataDir>/<workspaceId>/workspace.db) e apresentados por todos os clientes através de RPC. Nenhum cliente detém credenciais da Google.

As contas de calendário têm o âmbito do espaço de trabalho, como tudo o resto no Control Center. Cada espaço de trabalho liga a sua própria conta Google (ou várias) e os eventos e tokens de um espaço de trabalho nunca são visíveis a partir de outro. Mudar de espaço de trabalho muda os calendários que vê.

Um espaço de trabalho pode ligar várias contas Google, como uma conta de trabalho e uma pessoal, e os seus eventos são combinados nas mesmas vistas.

Porque é que o início de sessão usa um código de dispositivo

Secção intitulada “Porque é que o início de sessão usa um código de dispositivo”

O cc_server headless não tem navegador para capturar um redirecionamento OAuth. Por isso não usa nenhum: autoriza com a concessão device-code (RFC 8628). O servidor mostra um código de utilizador curto e um URL da Google, aprova num dispositivo qualquer que tenha navegador e o servidor vai perguntando até que o faça. Uma instalação headless consegue ligar uma conta precisamente porque não há nenhum endpoint de redirecionamento para alojar.

A consequência a saber antes de usar as suas próprias credenciais: o tipo de cliente tem de ser “TV and Limited Input devices” da Google. A Google só concede a esse tipo de cliente um conjunto de âmbitos pré-aprovado, e um projeto em que o Calendar não está autorizado para esse tipo falha com invalid_scope — nesse caso precisaria de um cliente loopback ou web.

Os tokens nunca saem do servidor. São escritos no secrets.json do servidor, no respetivo diretório de dados, com a chave google_google:<workspaceId>:<email>, juntamente com as bases de dados e sob a mesma fronteira de confiança do sistema de ficheiros do anfitrião. O servidor renova o acesso automaticamente e, quando a Google invalida uma conta em definitivo (uma sessão revogada ou expirada há muito tempo), publica CalendarAuthExpired e mostra um banner Voltar a ligar em vez de falhar em silêncio.

Uma compilação a partir do código-fonte não inclui nenhumas credenciais da Google — fornece o seu próprio ID de cliente e segredo. As compilações oficiais incluem um cliente device-code não confidencial, para que o fluxo de ligação funcione de imediato; o servidor guarda apenas um marcador que o referencia, nunca uma cópia. GOOGLE_OAUTH_CLIENT_ID (e o respetivo segredo) no ambiente tem sempre precedência sobre o par incorporado. Deliberadamente, não existe nenhuma flag --google-client-id: as flags desconhecidas são ignoradas e um segredo numa linha de comandos pode ser lido através de ps.

Para executar o seu próprio projeto Google, consulte Ligar um Google Calendar.

O servidor recolhe uma janela móvel dos eventos de cada conta ligada — todos os calendários da conta, não apenas o principal — a cada dois minutos, e ainda a pedido (arranque, ligação, atualização manual). A cadência curta é suportável porque a recolha é incremental: cada calendário tem o seu próprio token de sincronização, pelo que um calendário sem alterações custa uma resposta quase vazia em vez de voltar a obter uma janela de cinco meses.

Os eventos recorrentes são expandidos do lado do servidor, pelo que nenhum cliente chega a analisar uma regra de recorrência. Navegar para um mês fora da janela atual carrega esse intervalo de forma diferida. Os eventos eliminados ou movidos para fora do intervalo são removidos por reconciliação na sincronização seguinte.

Vista O que mostra
Mês Uma grelha do mês completo (suportada pelo pacote kalender)
Semana Os eventos com hora de uma semana numa grelha temporal
Dia Os eventos com hora de um único dia numa grelha temporal
Agenda Uma lista deslizável dos próximos eventos

Abra o calendário em /calendar; selecionar um evento abre o respetivo detalhe em /calendar/:eventId. A vista que escolher fica guardada nas preferências do próprio cliente, pelo que não o acompanha para outro dispositivo.

Um agendador a cada minuto procura eventos que comecem dentro de uma janela de antecedência configurável e emite uma notificação “Reunião prestes a começar” (um MeetingStartingSoon evento de domínio). A notificação inclui o URL de entrada na reunião quando existe e clicar nele abre o detalhe do evento. Os alertas são desduplicados com base no alertedAt do evento, pelo que a mesma reunião nunca gera dois alertas, mesmo entre reinícios, e um evento cujo início passou com a aplicação fechada nunca é repetido.

Há dois limites em que é fácil tropeçar. O agendador é executado no cliente, no computador e apenas para o espaço de trabalho que tem aberto no momento — um espaço de trabalho em que não esteja não gera nenhum alerta. E a versão web não tem de todo um pipeline de notificações do sistema operativo, pelo que também não gera nenhum.

A partir de um evento de calendário pode iniciar uma gravação de reunião pré-preenchida com o título do evento. O Control Center guarda uma associação um para um entre a gravação e o evento, para que as notas da reunião e a entrada do calendário se mantenham ligadas sem que nenhuma das funcionalidades dependa da outra.

Gravar e vincular só existe no computador. No cliente web, a ação indica que a gravação não está disponível — mesmo que o próprio fluxo de gravação do ecrã de reuniões funcione no navegador.