Um atalho é uma referência, não um direito

O painel inicial de um painel de alojamento é o ecrã que toda a gente vê primeiro e sobre o qual quase ninguém tem opinião até estar mal para si. O pedido era modesto: deixar as pessoas juntar cartões, e deixá-las pôr atalhos para um servidor ou uma integração a que voltam sempre.

Os pedidos modestos são o sítio onde se escondem as decisões interessantes, porque um atalho é uma preferência guardada que aponta para um objeto real com permissões reais. Torcer essa relação é a maneira de um painel acabar a mostrar a alguém uma máquina de que foi afastado há três meses.

Seis cartões, nenhuma migração, e nada chega sem se pedir

Há seis cartões que se podem juntar: uma lista de agentes, uma lista de servidores, uma lista de integrações, uma lista de pedidos de apoio, o saldo e um atalho. Os seis são de meia largura, porque são panorâmicas lado a lado e não algo que precise da linha inteira.

A disposição é guardada como JSON, e esta ronda não acrescentou nenhuma migração. É uma decisão e não um esquecimento. Uma entrada era um identificador e um indicador de oculto; agora traz também um identificador de instância e uma configuração por cartão. Uma linha antiga lê-se limpa na forma nova, com o identificador de instância preenchido a partir do do cartão e a configuração vazia, e um teste verifica exatamente isso: uma disposição antiga lê-se como os mesmos cartões pela mesma ordem. Aqui uma migração só poria uma marca de tempo no diário, e uma marca de tempo que depois se revela demasiado alta é um problema a sério para a ronda seguinte.

A segunda regra é que um cartão opcional nunca aparece sozinho. Existe um ciclo que junta os cartões que uma disposição não nomeia, para que um novo cartão fixo apareça em toda a gente, e esse ciclo cobre de propósito apenas os fixos. Se um opcional entrasse nele, «juntar» deixaria de ser uma ação e todos os painéis do produto cresceriam em cada publicação com um cartão que ninguém pediu.

Que cartões faltam é tanto uma decisão como quais estão. A supervisão e as cópias de segurança existem no código atrás de bandeiras de implantação desligadas, portanto um cartão para elas seria um cartão sem utilizadores. A atividade recente ficou de fora porque já existe como cartão fixo.

Duas metades de uma só regra

Na disposição guardada de uma pessoa, um atalho não é mais do que um tipo e um identificador. Tudo o que chega ao ecrã, o nome, o estado, a ligação, é obtido de novo em cada carregamento de página com as permissões de quem olha nesse momento. Essa regra tem duas metades e ambas são precisas.

A primeira é o módulo. Um membro que perde o módulo de agentes deixa de ver o seu atalho para um agente, mesmo que continue na sua disposição. Esta porta conhece também as superfícies: no domínio de marca próprio de um cliente, onde a faturação nem sequer existe, o atalho para o saldo desaparece por construção e não por uma segunda regra escrita de propósito.

A segunda é a consulta ao objeto. O identificador de organização está em cada WHERE, o filtro de eliminação suave ao lado, e num servidor o âmbito de servidores desse membro ao lado disso. Um servidor nunca atribuído a um membro não existe para esse membro, e isso tem de valer também para um atalho que criou quando ainda o podia ver.

O cartão de atalho é também o único cartão sem módulo e o único que pode existir mais do que uma vez. É correto e não descuidado: um atalho não é um ecrã próprio, é uma referência a um ecrã que já carrega o seu próprio direito. Se o tipo de cartão carregasse um módulo, quem tivesse esse módulo poderia ver um atalho para algo que não pode abrir.

Módulo retirado e objeto desaparecido são eventos diferentes

Duas coisas que no ecrã parecem iguais recebem tratamentos opostos.

O primeiro é silencioso porque o atalho não é a história. Se o papel de alguém mudou, o atalho em falta é um sintoma, e anunciá-lo no painel seria ruído por cima de uma mudança que já conhece. Além disso volta intacto assim que o módulo volta, o que só é possível porque nada foi eliminado.

O segundo é ruidoso porque a pessoa não fez nada de errado e algo lhe foi retirado. De propósito não é um 404 nem uma mensagem de erro: apenas um cartão que nomeia a situação e se oferece para se arrumar sozinho.

Mostrar com tolerância, e não limpar ao eliminar

A alternativa óbvia é retirar os atalhos quando o seu destino é eliminado. Não o fizemos, e o raciocínio merece ser anotado porque a decisão contrária foi tomada noutro ponto da mesma base de código: quando um membro deixa uma conta, a sua disposição guardada é mesmo esquecida, porque essa linha não toca nenhuma cascata e ficaria de outro modo para sempre numa conta onde nunca volta.

Aqui a balança pende para o outro lado, por três razões.

Desaparecer tem mais causas do que eliminar. Um membro perde um módulo, o seu âmbito de servidores muda, olha num domínio de marca. Nenhuma rotina de limpeza apanha esses três casos, portanto a via tolerante tem de existir de qualquer forma, e um segundo mecanismo passa a ser apenas mais um sítio que pode desalinhar-se.

A disposição é guardada por pessoa. Um servidor eliminado obrigaria a reescrever o JSON de cada membro da organização, dentro de uma transação na via de eliminação. Isso é amplificação de escrita numa via quente em troca de uma preferência de ecrã.

E não há nada a proteger. A linha guardada é um UUID de um objeto da própria organização e nada mais. Não deixa escapar nada, não cresce, e a pessoa vê logo que pode desaparecer.

O ensaio de ponta a ponta é rude de propósito. Depois de uma eliminação suave o servidor não volta, e o seu nome não surge em nenhum ponto da saída. Um membro sem o módulo de agentes não obtém nem agente nem integração, e o seletor não lhos oferece. Um âmbito de servidores vazio dá zero linhas e não tudo.

Dois achados que só um ensaio real produziu

Os dois defeitos verdadeiros desta ronda eram ambos invisíveis para os testes unitários, e ambos custaram uns dez segundos assim que algo real esteve a correr.

O seletor tem um campo de pesquisa, e procurar integrações partia o seletor inteiro com um erro de base de dados. A razão é que a coluna do tipo de integração é um tipo enumerado do Postgres, e para um enumerado não existe operador de padrão insensível a maiúsculas: a consulta devolveu 42883 operator does not exist, e como essa consulta alimentava todo o seletor não aparecia absolutamente nada. Converter a coluna para texto resolve. Nenhum teste unitário com um executor simulado o teria visto, porque uma simulação não tem tipos.

O segundo saiu da varredura de acessibilidade. Um mosaico de atalho é um nome, um estado e um tipo, e o conjunto é clicável. A primeira versão metia tudo isso numa só ligação, e a auditoria assinalou uma diferença entre o nome acessível e a etiqueta visível, porque o texto oculto conta para o nome acessível. O mosaico é agora um contentor comum com uma ligação que traz apenas o nome e uma área de clique absoluta e vazia que recolhe o clique. Isso trouxe um segundo problema, mais pequeno: a classe de corte na ligação cortava essa área à largura do texto, pelo que a maior parte do mosaico deixou de ser clicável. O corte mudou-se para um elemento interior e a cobertura foi medida em vez de suposta.

O que anotaríamos

1. 01Guarde uma referência, resolva um direito. Na preferência vai um identificador. O que chega ao ecrã obtém-se de cada vez com as permissões de quem olha.
2. 02Uma coluna sem esquema é uma migração que não precisa de escrever. Mas só se conseguir provar que a forma antiga se relê igual, e isso é um teste.
3. 03Opcional significa a pedido, para sempre. Um cartão que aparece sozinho faz de «juntar» uma palavra sem conteúdo.
4. 04Distinga eliminado de inalcançável. No ecrã parecem iguais e merecem o tratamento contrário: silêncio para um, uma explicação para o outro.
5. 05Não limpar pode ser a escolha mais forte. Se o mesmo sintoma tem causas que a sua limpeza não vê, a via tolerante tem de existir de qualquer forma, e a limpeza passa a ser apenas uma segunda coisa a manter alinhada.
6. 06Ponha a coisa a correr. Um enumerado sem operador de padrão e uma ligação que corta a sua própria área de clique veem-se num instante num navegador, e não se veem de todo numa bateria de testes sem base de dados.

Para ser claro sobre o que isto é: os cartões aqui descritos estão em produção para todas as contas. Várias coisas não estão provadas. A reordenação com o rato não foi conduzida, os cartões de supervisão e de cópias atrás de bandeira não existem e a sua via de código nunca foi percorrida, o domínio de marca foi verificado numa consulta e não num navegador, e um cartão acabado de juntar só aparece depois da ronda seguinte do servidor.

Do trabalho de plataforma da Provibr. O que um cliente do nosso cliente vê e não vê num painel de marca está em painéis de marca branca: o que o cliente vê, e porque é que um ecrã de resumo nunca reescreve nas tabelas que lê está em projetar, nunca substituir.