SmartAuth 2.0.60: ruta de salud, instalación incompleta señalada y conflictos de sincronización más fiables

Una ruta de salud para las aplicaciones móviles

Las aplicaciones SmartMaker verifican regularmente que el servidor responde antes de enviar lo que han registrado sin conexión. Hasta ahora solo disponían de rutas protegidas, que respondían con un rechazo sin token: el servidor podía parecer inalcanzable cuando funcionaba.

GET y HEAD sobre api.php/health responden ahora 204, sin cuerpo y sin token, sin consulta a la base de datos ni línea en el registro de peticiones de SmartAuth: la ruta puede llamarse cada minuto. De forma más general, una petición HEAD es atendida por la ruta GET del mismo camino, con el mismo control de acceso, y un camino llamado con un método que no acepta responde 405 con la lista de métodos aceptados.

Instalación incompleta señalada claramente

Dolibarr activa un módulo antes que sus dependencias y lo deja activado cuando una de ellas falla. Un módulo SmartMaker podía ejecutarse mientras SmartAuth no estaba activado, y su aplicación fallaba al conectarse por una tabla ausente. La API responde ahora con 503 indicando que SmartAuth no está activado, y la causa se registra en el log.

Conflictos de sincronización asociados al tipo correcto

Un módulo puede declarar sus propios tipos de objetos sincronizados, eventualmente sobre una tabla ya usada por un tipo de SmartAuth. Un conflicto solo registraba su tabla: la resolución podía aplicar las reglas de otro tipo, y the aplicación debía adivinar el tipo por sí misma. Cada conflicto registra ahora su tipo, devuelto por GET sync/conflicts (object_type) y usado para la resolución. La reactivación del módulo añade la columna; sin ella, se conserva el comportamiento anterior.