SmartAuth 2.0.60: rota de saúde, instalação incompleta sinalizada e conflitos de sincronização mais fiáveis

Uma rota de saúde para as aplicações móveis

As aplicações SmartMaker verificam regularmente se o servidor responde antes de enviar o que registaram offline. Até agora, só dispunham de rotas protegidas, que respondiam com uma recusa sem token: o servidor podia parecer inacessível quando estava em funcionamento.

GET e HEAD em api.php/health respondem agora 204, sem corpo e sem token, sem consulta à base de dados nem linha no registo de pedidos do SmartAuth: a rota pode ser chamada a cada minuto. De forma mais abrangente, um pedido HEAD é servido pela rota GET do mesmo caminho, com o mesmo controlo de acesso, e um caminho chamado com um método que não aceita responde 405 com a lista dos métodos aceites.

Instalação incompleta sinalizada claramente

O Dolibarr ativa um módulo antes das suas dependências e mantém-no ativado quando uma delas falha. Um módulo SmartMaker podia, assim, estar em execução enquanto o SmartAuth não estava ativado, e a sua aplicação falhava na ligação devido a uma tabela ausente. A API responde agora com 503, indicando que o SmartAuth não está ativado, e a causa é registada.

Conflitos de sincronização associados ao tipo correto

Um módulo pode declarar os seus próprios tipos de objetos sincronizados, eventualmente numa tabela já utilizada por um tipo do SmartAuth. Um conflito registava apenas a sua tabela: a resolução podia aplicar as regras de outro tipo, e a aplicação tinha de adivinhar o tipo por si mesma. Cada conflito regista agora o seu tipo, devolvido por GET sync/conflicts (object_type) e utilizado para a resolução. A reativação do módulo adiciona a coluna; sem ela, o comportamento anterior é mantido.