SmartAuth 2.0.60: health check route, incomplete installation reported, and synchronisation conflicts made more reliable

A health check route for mobile applications

SmartMaker applications regularly check that the server is responding before sending what they have recorded offline. Until now, they only had protected routes, which returned a refusal without a token: the server could appear unreachable while it was actually functioning.

GET and HEAD on api.php/health now return 204, with no body and no token, without querying the database or adding a line to the SmartAuth request log: the route can be called every minute. More broadly, a HEAD request is served by the GET route of the same path, with the same access control, and a path called with a method it does not accept returns 405 with the list of accepted methods.

Incomplete installation clearly reported

Dolibarr activates a module before its dependencies and leaves it activated when one of them fails. A SmartMaker module could therefore run while SmartAuth was not activated, and its application would fail at connection due to a missing table. The API now returns 503, indicating that SmartAuth is not activated, and the cause is logged.

Synchronisation conflicts linked to the correct type

A module can declare its own types of synchronised objects, possibly on a table already used by a SmartAuth type. A conflict only recorded its table: the resolution could apply the rules of another type, and the application had to guess the type itself. Each conflict now records its type, returned by GET sync/conflicts (object_type) and used for resolution. Reactivating the module adds the column; without it, the previous behaviour is preserved.