Skip to content

Release 4.3.1

Compare
Choose a tag to compare
@joshualan joshualan released this 01 Jun 14:56
· 573 commits to master since this release

Release Notes 4.3.1

Bug Fixes

  • JSON Filter Pattern (JFP) now supports filtering and sorting with fields using the SERIALIZE-NAME option.
  • JSON Filter Pattern now handles single quotes in filter values.

Important Note

  • If you see the following error while performing an update, you would need to update the base Business Entity class:

    Unable to call SAVE-ROW-CHANGES(). Failed to create query for BEFORE-TABLE. (7211)
    

Please contact Technical Support to access OpenEdge hot fix 11.6.3.004 which contains the OpenEdge.BusinessLogic.pl procedure library file.

Known Issues

  • When using the JSDO dialect of the Kendo UI DataSource, if you set serverFiltering= true, and then specify the filter property where a field value is set to null, the filter will fail on the READ operation. The following error will occur: "ERROR condition: *** Unable to understand after -- " and <>". Example of offending filter: filters:[ { field: "myDate", operator: "neq", value: null }]
  • An app built in Telerik Platform and deployed to a device running Android 4.2.2 will be unable to log in if the user name contains an @ sign. For example, the following will cause a login error if it is used as the user name : [email protected] This bug appears to be specific to Android version 4.2.2.
  • If an app uses a JSDOSession object to log in to a Web application that uses Form authentication and then uses another JSDOSession object to log in to the same Web application (the serviceURI's resolve to the same location), the second JSDOsession does not validate credentials passed to its login() method if the session established by the first login is still valid. Developers should avoid using 2 JSDOSessions that point to the same Web application and are active at the same time.
  • If you have an app that logs in to a Data Provider protected by Form based authentication, you need to be sure to log out of that site before logging in again from the same browser instance. If you don't, the session ID from the previous run will remain valid and subsequent logins will use the old credentials. This could happen, for example, if you are running the KUIB and repeatedly testing the app with the Preview button. If logout is not available, you will need to either close the browser before the next run of the app, or use the browser's settings to clear the browser's cache of cookies from the site to which you logged in. (For example, in Google Chrome, go to the menu and select Settings | Show Advanced settings | Content Settings | Cookies | All cookies and site data... and then look for the Data Provider's URL.)
  • In Windows 7 Internet Explorer 11, the Privacy Settings in Internet Options can prevent generated apps from authenticating and getting data correctly. The reason for this is that by default, some first party cookies are disabled. This can cause the backend to not identify your session correctly. In order to get around this, you can either make sure the Privacy Settings is set to lower than medium. Alternatively, you can simply make sure in the Advanced Settings that Internet Explorer 11 accepts first and third party cookies.
  • If a KUIB app uses Form authentication and the server session expires, attempts to make JSDO requests to the server will result in "401 Unauthorized" responses. The app will only show the error message and keep the same display on the screen, without directly giving the user a way to log in again. The user can get around this by pressing the browser's refresh button --- this will cause the Login screen to be displayed. Unfortunately there is no indication on screen that the user should press the browser refresh.
  • Release 4.3 of the JSDO library adds support for accessing array fields as individual fields in the table reference. For example array field MonthQuota EXTENT 12 in the Salesrep table can now be accessed using field names from MonthQuota_1 to MonthQuota_12, in addition to the existing JavaScript access as MonthQuota[0] ... MonthQuota[11] for the corresponding elements. However, if a table already has a scalar field with the same name as the name that is used for the individual fields for the array, only the existing field is available as an individual field. For example if a field called MonthQuota_12 was already present in the Salesrep table, the reference MonthQuota_12 would refer to this existing field and not to the 12th element in the MonthQuota array. To access this element you can need to use JavaScript MonthQuota[11] from the JSDO directly. The useArrays: true setting in the JSDO transport can be used enable the access to the field as an array from the Kendo UI DataSource. The SERIALIZE-NAME option can be used change the name of the scalar field to avoid a conflict with the name generated for a flattened array.
  • It is not possible to load a JSDO catalog that contains a service or a resource with the same name as one that has already been loaded. The result will be an error like: "Error: Error processing catalog" A resource named '' was already loaded. This can happen either with two addCatalog() calls made by the same JSDOSession, or with calls made by different JSDOSessions. Developers should include all of the resources for a given service in the same catalog, and should avoid duplicating resource or service names across Web applications that are used in the same app.
  • Using option operation="count" to define a default Count operation in a Business Entity, results in an invalid definition in the catalog. Use operation="invoke" and specify the transport.countFnName property to specify the Count operation. A possible workaround, to define a default Count operation, is to add the @openapi.openedge.method.property annotation in the Business Entity to override the type property in the catalog. Example: @openapi.openedge.method.property (name="type", value="count").
  • Retrying a Submit request with an OpenEdge 11.7.1 backend, results in error 117760.
    Workaround: Remove the "prods:rejected" property in _deletePropdsProperties(). JSDO version 4.4.0 addresses this scenario.