Aug 25, 2023

This week we added release notes for Cloud Platform.

Cloud Platform

Release type

Environment

Feature

Summary

1

Fixed

Owlet-Field

Ayla Message Service

Fixed an issue wherein alert history wrongly displayed status as “Delivered” when push notifications failed. This issue occurred in the following scenarios:

  • *Apple Push Notification service (APNs)** 
  • Unrelated APNs certificate

  • Corrupt APNs certificate

  • Invalid mobile device token


Firebase Cloud Messaging (FCM)

  • Invalid FCM Key

  • Invalid mobile device token

This fix helps the customers (OEMs) by rightly reporting the errors occurring while sending push notifications.

  • *NOTE**: This has no impact on endusers.

2

Fixed

US-Field
EU-Field

Mobile Application

Fixed an issue wherein newly introduced date format caused applications to crash. This fix corrected the date format.

3

Enhanced

US-Field
EU-Field

User Service

Fixed the default logo display error in the authorization (Oauth) flow.

4

Fixed

US-Field
EU-Field

Factory Service

Device Service

Fixed an issue wherein third-party device onboarding failed due to unsuccessful signature verification by the Provision Device API. This fix enabled smooth onboarding of the third-party devices into Ayla Platform.

5

Fixed

US-Field
EU-Field

Device Service

We optimized device onboarding for the re-registration flow.

6

Fixed

Shark-Field

Message Service

There was no alert of the actions that are rate limited (not executed) due to the set Repeat Frequency. To address this, an alert history is generated with "Action has been rate limited" error message.

7

Fixed

Shark-Field

Rule Service

  • Fixed an issue wherein Get actions API was producing error when “is_internal= true” and “paginated=true”. Also, now by default the API result is displayed in descending order.

  • For Get actions and Get rules APIs, the response parameter “totalPages” is changed to “total_pages”.

8

Fixed

Shark-Field

ICC Service

We streamlined the from_version for OTA jobs:

  • When both job and filter have version data, we consider the job's version as the from_version.

  • If neither job nor filter has version data, we consider the from_version as ALL versions.

  • If either job or filter has version data, we consider that as the from_version.