SmartAuth 2.0.60: trasa zdrowia, zgłaszanie niekompletnej instalacji i usprawnione rozwiązywanie konfliktów synchronizacji

Trasa zdrowia dla aplikacji mobilnych

Aplikacje SmartMaker regularnie sprawdzają, czy serwer odpowiada, zanim wyślą to, co zapisały w trybie offline. Do tej pory miały do dyspozycji jedynie chronione trasy, które odrzucały żądanie bez tokenu: serwer mógł wydawać się niedostępny, mimo że działał.

GET i HEAD na api.php/health zwracają teraz 204, bez treści i bez tokenu, bez zapytania do bazy ani wpisu w dzienniku zapytań SmartAuth: trasę można wywoływać co minutę. Ogólniej, zapytanie HEAD jest obsługiwane przez trasę GET o tym samym adresie, z tym samym kontrolowaniem dostępu, a ścieżka wywołana metodą, której nie akceptuje, zwraca 405 wraz z listą dozwolonych metod.

Wyraźne zgłaszanie niekompletnej instalacji

Dolibarr aktywuje moduł przed jego zależnościami i pozostawia go aktywnym, gdy jedna z nich nie powiedzie się. Moduł SmartMaker mógł więc działać, gdy SmartAuth nie był aktywowany, a jego aplikacja kończyła się niepowodzeniem przy połączeniu z powodu brakującej tabeli. API zwraca teraz 503, informując, że SmartAuth nie jest aktywowany, a przyczyna jest rejestrowana w dzienniku.

Konflikty synchronizacji przypisane do właściwego typu

Moduł może deklarować własne typy synchronizowanych obiektów, potencjalnie na tabeli już używanej przez typ SmartAuth. Konflikt zapisywał jedynie swoją tabelę: rozwiązanie mogło stosować reguły innego typu, a aplikacja musiała domyślać się typu sama. Każdy konflikt zapisuje teraz swój typ, zwracany przez GET sync/conflicts (object_type) i używany do rozwiązania. Ponowna aktywacja modułu dodaje kolumnę; bez niej zachowywane jest poprzednie działanie.