SmartAuth 2.0.60 : route de santé, installation incomplète signalée et conflits de synchronisation fiabilisés

Une route de santé pour les applications mobiles

Les applications SmartMaker vérifient régulièrement que le serveur répond avant d'envoyer ce qu'elles ont enregistré hors connexion. Elles n'avaient pour cela que des routes protégées, qui répondaient un refus sans jeton : le serveur pouvait sembler injoignable alors qu'il fonctionnait.

GET et HEAD sur api.php/health répondent maintenant 204, sans corps et sans jeton, sans requête en base ni ligne dans le journal des requêtes de SmartAuth : la route peut être appelée toutes les minutes. Plus largement, une requête HEAD est servie par la route GET du même chemin, avec le même contrôle d'accès, et un chemin appelé avec une méthode qu'il n'accepte pas répond 405 avec la liste des méthodes acceptées.

Une installation incomplète signalée clairement

Dolibarr active un module avant ses dépendances et le laisse activé quand l'une d'elles échoue. Un module SmartMaker pouvait donc tourner alors que SmartAuth n'était pas activé, et son application échouait à la connexion sur une table absente. L'API répond désormais 503 en indiquant que SmartAuth n'est pas activé, et la cause est journalisée.

Des conflits de synchronisation rattachés au bon type

Un module peut déclarer ses propres types d'objets synchronisés, éventuellement sur une table déjà utilisée par un type de SmartAuth. Un conflit n'enregistrait que sa table : la résolution pouvait appliquer les règles d'un autre type, et l'application devait deviner le type elle-même. Chaque conflit enregistre maintenant son type, renvoyé par GET sync/conflicts (object_type) et utilisé pour la résolution. La réactivation du module ajoute la colonne ; sans elle, le comportement précédent est conservé.