3.2.0

Docker images

Rename of docker image for YAMBAS

The name for the previous alpine-yambas image was renamed to apiomat / yambas.

3.2.0

Objective-C SDK

When loading data while the device is offline and no data is found in the cache, an error with the status code AOMID_NOT_FOUND_OFFLINE will be returned, instead of AOMNO_NETWORK. When using the caching strategy NETWORK_ONLY, AOMNO_NETWORK will still be returned as the cache is not used.

If you are checking for the status code AOMNO_NETWORK when loading data and the cache is used, you'll have to check for AOMID_NOT_FOUND_OFFLINE instead.

3.1.3,

3.2.0

apiomat.yaml/maxResults

The system-wide maximum of results limitation is now set to 0/unlimited by default (was 1000 before)

When querying large datasets with no limitation, database may take lots of time to collect the data. Thus, on systems where millions of entries can be queried, the yambas.limits.maxResults should be set back to a proper limit.

3.0.1,

3.1.0

Dynamic Roles

When Dynamic Roles where used (only possible in 3.0.0), the custom role check (a.k.a. overwritten isUserInRoles() method in Native Module) was not called when in another Native Module hook method or auth method the AOM.checkRoles() method was called. Since 3.0.1 this method is called.

You're only affected if you implemented your own isUserInRoles() method and assigned the Role Class to a MetaModel, and also used AOM.checkRoles() on that MetaModel / on objects of that MetaModel in your code.

3.0.0

Git Modules

The whole git handling has changed.

• Module status "NATIVEGIT" has been removed

• Behaviour of the git endpoints changed

• Existing Git modules will be migrated on first start. A restart of yambas is necessary after the first full start!

Read more about the change on our page Introducing the new git flow

3.0.0

Deprecations

The deprecations, which were scheduled to be removed for March 2018, have been removed.

• newly downloaded SDKs may break existing Apps, due to missing methods

• see the Deprecations and Migration page for detail information and replacements

3.0.0

Sharepoint module

Files were previously handled as Base64 strings in the attribute downloadableFile of the class SharepointFile. This attribute was changed to the type File and full static data handling was implemented. This means for example that in the response JSON the attribute is called downloadableFileURL and contains a URL where the actual file can be fetched.

You need to change native module and SDK code to handle files correctly, as well as any code that manually sends HTTP requests to the SharepointFile REST endpoint.

3.0.0

EULA Acceptance

Each ApiOmat account (including the SuperAdmin) is forced to accept the EULA to enable the account.

After installation or update, each account has to log into the dashbord one time and accept the EULA. Until then, each request with this account will raise an error, including all SuperAdmin requests.

3.0.0

Native Module Methods

The methods and resourceMethods field on AbstractClientDataModel are now of type IModelMethodsBackend and IResourceMethodsBackend.

If you set your own mock-implementation of these Interfaces, you have to rewrite them to implement the new interfaces

3.0.0

Server Code

The user object in ServerCode does not have the [get/set]LocLatitude and [get/set]LocLongitude methods anymore and instead, the [get/set]Latitude and [get/set]Longitude methods are (furthermore) available.

The [get/post/put/delete]Request methods are now only available on the static AOM object, but not on the objects itself.

• Change [get/set]LocLatitude and [get/set]LocLongitude to [get/set]Latitude and [get/set]Longitude

• Change obj.[get/post/put/delete]Request(...) to AOM.[get/post/put/delete]Request(...)
  in your ServerCode

3.0.0

Paymill module

The Paymill module is not available anymore, as it was only useable in ServerCode.

The module will be removed from your Backends automatically after upgrade.

3.0.0

Tumblr module

The tumblr module is not available anymore.

The module will be removed from your Backends automatically after upgrade.

3.0.0

Swift SDK

Swift SDK now uses Swift 4

You have to update existing Swift 3 apps to Swift 4: Swift 4 Information

2.6.5,

3.0.0

Objective-C SDK

Changed Cache-SDK from NSURLCache to DFCache

• same errorcode for sync and async request if internet is not available (614) and no cacheresult (615)

• async request return errorcode 614 if cachstrategy is Network_Only

2.6.1,

3.0.0

Static data (images and files)

Similar to the change in 2.6.0, where the JavaScript SDK was affected, now the Android, Objective-C, C#, C#-SQLite and Java SDKs are affected

• When deleting an image/file from an object that still contains the image/file HREF locally, but the image/file doesn't exist on the server anymore, an "ID_NOT_FOUND" error occurs instead of a "MODEL_NOT_FOUND" error

• When trying to load an image/file, but the local object doesn't contain the according image/file HREF, an "ATTACHED_HREF_MISSING" error occurs instead of a "MODEL_NOT_FOUND" error

• With the exception of the PushMessage class, when calling the post<dataAttrName>() method without having saved the object that you're calling the method on, an "HREF_NOT_FOUND" error occurs

• The below (for the JavaScript SDK) mentioned implications apply as well

2.6.0

JavaScript SDK

When posting a file or an image to an object, the object needs to be saved before.

When posting an image or a file, make sure the object was saved already. Otherwise the onError-callback will be triggered, giving a HREF_NOT_FOUND (601) error.

2.6.0

JavaScript SDK

When loading a referenced image or file, whose Href is missing, no exception will be thrown anymore.

When loading a referenced file or image fails because the accoding Href is missing, you can check for this error within the onError callback instead of using a try-catch block.

2.6.0

Static data (images and files)

There are new ways for handling static data. The JavaScript SDK was changed so that it uses the new REST endpoints internally. So when using the JavaScript SDK to post images or files to objects, the static data URLs are different now.

• If you work with the static data URLs directly (instead of with SDK methods) you need to keep in mind that the new URLs lead to the newly introduced hook methods being executed when sending a GET or DELETE request to them.

• If you send a DELETE request directly (instead of with the SDK method):

  • To the old static data URL, a following GET to the object that contained the image/file leads to the static data URL still being in the object. So loading the data with the SDK's "load<dataAttributeName>" method lead to a MODEL_NOT_FOUND (804) error.

  • To the new static data URL, a following GET to the object that contained the image/file lead to the static data URL being empty. So loading the data with the SDK's "load<dataAttributeName>" method leads to a ATTACHED_HREF_MISSING (616) error.

• If you implemented any doPost, beforePost or afterPost hook method in a Native Module, and relied on the static data URL being present in the object, this won't work anymore if you're using the JavaScript SDK's "post<dataAttributeName>" method

2.6.0

Twitter Module

The twitter module have been moved from a static module to native module. Take a look at the module page to see what has changed.

If you did not use the module in any of your modules or backends, it will simply be deleted. If the installation have modules or backends that use the module, please contact us to get the new native module version of the twitter module.

For more information about the possible implications when switching to the native module version, please visit the Twitter module page

2.5.6, 2.6.0

Any ("wrong") AppName Parameter in NativeModule Methods and Non-Transient References in NativeModules

Any method in NativeModules that takes an appName parameter will now check whether the owner of the backend for which the request was originally made has permissions on the backend that is given by the appName parameter. Additionally, any non-transient reference that is loaded gets checked for correct permissions.

This also means, that you have to call your custom REST-endpoints with the backend name included (as suggested since ApiOmat 2.1), e.g.:

{BASEURL}/yambas/rest/modules/{MODULNAME}/{APPNAME}/spec/ping

If empty or random Strings are passed as appName or if the request-originating backendowner does not have the permissions on the given backend, an unauthorized exception will be thrown.

The additional permission check on references should not lead to problems, as it only prevents against a complex attack scenario with multiple implications related to knowledge against another backend

The additional checks can be suppressed by setting strictChecks=false (on yambas.conf) or yambas.strictChecks:false (on apiomat.yaml)

2.5.5, 2.6.0

Object-based DeltaSync

When a client makes a request to a collection with a query like "a < 10" and receives 2 objects (a=8, a=9), he can send these objects' IDs and lastModifiedAt in the next collection query with "a < 10".

Until now, the server responded with a delta-deleted header that included the IDs of those objects that were either deleted or changed in a way that they're not part of the result anymore (e.g. changed to a=11).
But without differentiation between these two cases, clients didn't know whether to delete the objects from the local storage or not.

From now on, the server will respond with a delta-deleted header for deleted object IDs and a delta-removed header for objects that are just not part of the result anymore.

This change only applies to object-based DeltaSync. When using collection-based DeltaSync, there's no delta-removed header in the response at all and there are also no object IDs of objects that aren't part of the result anymore in the delta-deleted header.

Clients with old SDKs will still work, because the server will combine deleted and removed object IDs in the delta-deleted header when the x-apiomat-sdkversion header is < 2.5.5, leading to the old behavior.

New versions of most SDKs already take care of the separate response headers and the correct handling regarding the offline storage. The handling for the C# / Xamarin and Swift SDKs will be fixed in an upcoming version.

When using requests without SDK version header, you need to change the DeltaSync handling.

When using DeltaSync in Native Modules, no automatic SDK version check is done and you need to change the handling as well (e.g. start using r.setDeltaSyncRemovedList(...) etc.).

2.5.0

Modules who use external libraries not included in default module code

Loading of external libraries in native modules has been changed. Please read more at Native Module specific notes and limitations.

• If you use libraries that are also used by yambas (like Apache HttpClient), you can now use any version you want

• You have to update the SMTP module (we can provide you a new version, or you can add javax.mail-1.4.5.jar by yourself)

• Also be aware, that if your module previously relied on libraries with only interfaces, where the implementation was contained in ApiOmat itself (like slf4j, jdbc,..), you now have to include the implementation libraries in your own modules as well

Update your module using the update guide.

To switch back to the previous behaviour, set useOldClassloader=true in yambas conf oryambas.useOldClassloader:true in apiomat.yaml (supported since ApiOmat 2.5.2)

2.4.7, 2.5.1, 2.6.0

Usage of save() in Native Module code

Exceptions which are thrown in save() method in native modules are now populated to the calling code. This makes it possible to react on exceptions happened during the save operation. Before 2.4.7, these exceptions were catched internally and null was returned.

Check module code and add a try { } catch block around thesave() calls if you want to handle the exception in native module code.

2.4.7

C# / Xamarin SDK

Portable Class Libraries containing the C# / Xamarin SDK can't target the Windows Phone 8.0 platform anymore, due to the use of the System.Linq.Parallel namespace.

Instead of using PCL profile 259 we recommend using profile 111.

2.4.3

OAuth2 error code handling

OAuth2 Token verification can now be done by external Authentication classes. Due to workflow changes, return codes on authentication failure of OAuth2 tokens will change from 401 to 840.

If Oauth2 error codes are checked in your application, add a handling for error 840 (token invalid).

2.4.1

Modules with implemented auth() methods in Hooks

Legacy call to auth hook method on Native Module class basis without any configured auth classes was removed (AOM-3567). To increase security and strictly follow the concept of Authentication classes, the auth() method in Hook classes is now only called when the specific class is also set up as an auth class.

Before this change, auth hook methods were called in 2 additional cases:

• A CRUD request is received that targets class instances of a class of a Native Module, where the class contains an implementation of the auth hook method. This auth hook method gets called in this case.

• The requesting user (also for example a synced LDAP user) is found in the database. The class of the user gets determined (e.g. LDAPUser) and then that class' auth hook method gets called.

To stay with the legacy behaviour, set the classBasedAuth=true in yambas.conf / yambas.classBasedAuth: true in apiomat.yaml before upgrade.

2.4.0

Modules with own implementation of a REST class

New swagger library in native modules. Existing modules custom REST interface will not be shown in Apidocs and Dashboard anymore.

Update your modules and apply changes from the new library as described at the bottom of the help page.

2.3.1

Installations using same username for Users and Customers

Since using the same email/username for Users and Customers in one installation lead to various strange errors, it will not be possible anymore to create users and customers with the same name/email address. (AOM-3238)

Users and Customers having the same login may not be usable anymore.

2.2.1

Modules using the AOM.findByNames()method

Behaviour of <YourModule>.AOM.findByNames(...) changed; Old behaviour:

• If an exception occurs, return null. Independent of the transience.

• If the class of the objects you want to find is transient, the return value equals the return value of the doGetAll implementation of that class.

• If the class of the objects you want to find is non-transient:

  • If no elements were found, return an empty array.

  • If elements were found, return the filled array.

New behaviour:

• If an exception occurs, return null. Independent of the transience.

• Otherwise, independent of the transience:

  • If no elements were found, return an empty array.

  • If elements were found, return the filled array.

Change handling of the return value of the findBy() method in your native module code