6.0.1

Release Notes

New Features

1. Support for OpenEdge 12.0
2. Support changes to oeping in recent PASOE versions
3. Addition of tableRef and viewTable to ablFilter
4. Simplified version watermarking by removing version labels from source files and utilizing the build process to version each compiled file.

Bug Fixes

• When using Basic Authentication in a node.js environment, passwords and usernames that contain Unicode characters do not get properly encoded.

Known Issues

• 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.
  getSession() will reject its promise with an error code of GENERAL_FAILURE instead of AUTHENTICATION_FAILURE if the user successfully logs into a token provider but the given data provider rejects said token.
• [JSDO's Session] Login fails for the first time with 'Invalid Credentials' after session timeout.

5.0.1

Release Notes

This is a patch release with no new features.

Bug Fixes

• Unable to generate release build with KUIB 3.0/3.0.5.

6.0.0

Release Notes

New Features

1. Support for Angular 6.
2. Support for rxjs 6.

Bug Fixes

1. DATE field with hyphenated name is incorrectly serialized as DATETIME when attempting to perform server side filtering. A type mismatch error is displayed on the client.
2. getSession() fails to return jsdosession when building with Angular production build.getSession() fails to return jsdosession when building with Angular production build.
3. KUIB does incorrect mapping when dataset contains field named "id".

Known Issues

• 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.
  getSession() will reject its promise with an error code of GENERAL_FAILURE instead of AUTHENTICATION_FAILURE if the user successfully logs into a token provider but the given data provider rejects said token.
• [JSDO's Session] Login fails for the first time with 'Invalid Credentials' after session timeout.

5.0.0

Release Notes

New Features

1. Support for NativeScript
2. Introduction of new "Progress Data Source" component
3. Support for Angular web app
4. Support for Kendo UI Builder 3.0
5. Support for ES6 Promises
6. JSDO components available as npm packages:
   a. @progress/jsdo-core
   b. @progress/jsdo-angular
   c. @progress/jsdo-nativescript

Bug Fixes

Issue: The id parameter supported by the JSON Filter Pattern is not being sent to the OpenEdge backend when calling the fill() or read() method.

Behavior Changes

• The signature for APIs returning a promise object now use a single "object" parameter in the callback function.
• Exceptions when calling asynchronous operations now use are returned via the error handler of the promise object.

Note:

Please see the wiki for the JSDO project for additional info:
https://github.com/progress/JSDO/wiki/Asynchronous-execution-using-ES6-Promises

Known Issues

• 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.
  getSession() will reject its promise with an error code of GENERAL_FAILURE instead of AUTHENTICATION_FAILURE if the user successfully logs into a token provider but the given data provider rejects said token.

Release 4.4.1

Release Notes 4.4.1

New Features

• New APIs:

  • progress.data.invalidateAll(): This function logs out and invalidates all the JSDOSessions by calling invalidate() on each session. An error message will be thrown if methods ping(), isAuthorized(), addCatalog() and login() are called.

  • progress.data.JSDOSession.invalidate(): This function logs out and invalidates the JSDOSession. The session will be in an invalid state. An error message will be thrown if methods ping(), isAuthorized(), addCatalog() and login() are called.

  • Please refer to the following article for additional information on the APIs:
    https://community.progress.com/community_groups/openedge_kendo_ui_builder/w/openedgekendouibuilder/2928.jsdosession-authentication-in-kendo-ui-builder-2-0-jsdo-4-4-1

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 }]
• 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.
  getSession() will reject its promise with an error code of GENERAL_FAILURE instead of AUTHENTICATION_FAILURE if the user successfully logs into a token provider but the given data provider rejects said token.
• 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").

Release 4.4

Release Notes 4.4.0

Bug Fixes

• Issue: Login fails when using FORM-based authentication with a username or password that includes special characters (for example '%').

• Issue: When using a nested filter with the JFP (JSON Filter Pattern), the following error message is shown in the JavaScript Console:

  TypeError: Cannot read property 'toLowerCase' of undefined

Behavior Changes

• The base Business Entity class (OpenEdge.BusinessLogic.pl - BusinessEntity.cls) has been
  updated to use Transactional Submit as the default mode for the Submit operation.
  Developers interested in the non-transactional Submit mode can call the SaveRows() method
  instead of Submit() in their BusinessEntity class.
  Also, its CreateData(), UpdateData(), and DeleteData() methods which correspond to the
  Create, Update, and Delete operations, have been updated to use a Transactional model as
  well.
• The following APIs have been deprecated:
  • Session class:
    progress.data.Session class
    addCatalog( ) method (Session class)
    authenticationModel property (Session class)
    login( ) method (Session class)
    logout( ) method (Session class)
    ping( ) method (Session class)
    subscribe( ) method (Session class)
    unsubscribe( ) method (Session class)
  • JSDOSession class:
    login( ) method (JSDOSession class)
    logout( ) method (JSDOSession class)

Notes:

• Please use the JSDOSession class instead of the Session class.
• Please use the getSession() (JSDOSession class) and/or the corresponding AuthenticationProvider APIs instead.

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 }]
• 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.
• 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.
• getSession() will reject its promise with an error code of GENERAL_FAILURE instead of
  AUTHENTICATION_FAILURE if the user successfully logs into a token provider but the given data
  provider rejects said token.
• The session.connected property is not updated to false after a session.logout() operation
  completes. The session.connected property is set to true after a successful login but is not
  being updated to false after a logout.
• 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").

Release 4.3.1

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 : restuser@progress.com 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.

Release 4.3

Release Notes 4.3.0

New Features

• Handling of multi-table dataset with hierarchical Kendo UI Grid.
• Custom mapping type plugin in the JSDO. Support for RequestMapping and ResponseMapping.
• JSDO custom properties.
• Arrays as individual fields.
• Support for Date and DateTime conversions.

Improvements

• getErrors() API has been enhanced to handle addtional error formats used to return errors for CRUD+Submit operations. Errors using the JSON error object and plain text are handled, in addition to errors returned using prods:errors.
• Calls to the count operation has been optimized for the case when the number of records returned from the server is less than the page size.

Behavior Changes

• Array fields are now flattened when working with the JSDO dialect of the Kendo UI DataSource. For example, the 12th element of the MonthQuota array in the Salerep table can be accessed using MonthQuota_12 instead of MonthQuota[11]. The useArrays: true setting in the JSDO transport can be used to re-enable the previous behavior.
• When an app calls JSDO.saveChanges() with the useSubmit argument set to false, the various types of pending changes are sent to the server separately (deletes, then creates, then updates). If one of the required operations is not defined by the resource involved, saveChanges() throws an error. Previously, saveChanges() did not validate the existence of an operation until it was about to send the request to the server. This meant that some operations might be sent even though the saveChanges() call would ultimately fail. Now, the existence of all operations is checked before any are executed -- if some operations cannot be sent to the server, none are sentIn addition, if a required operation is missing, the JSDO will not fire before events for any operations, since the saveChanges will not actually happen.

Bug Fixes

• When sending requests to an OpenEdge Web application that expects a JSESSIONID path parameter in the request URI, the JSDO library incorrectly sends the JSESSIONID as a query parameter instead, and does so in such a way that it invalidates any query parameters that follow it in the URI.
• If your Business Entity has DATE or DATETIME fields, and the client and server are on different time-zones, and updates are performed, you may see unexpected results in your Date and DateTime fields due to incorrect conversions to/from the AppServer.
  You may also encounter the following error on an update:
  "SAVE-ROW-CHANGES found record with conflicting change by another user. (11913)․"

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 :
  restuser@progress.com
  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 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 would 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.
• 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").

Release 4.2

Changes/Additions for the 4.2 JSDO release

1. getErrors() API is at the JSDO and tableRef level. It can be called at any time to return the errors from the most recent CRUD operation when using Before-Imaging and the errors will be reset on the next CRUD operation. The API can also be called from the error handler for the Kendo UI DataSource.
2. The Submit operation now allows the use of a temp-table instead of only a ProDataSet. This was requested by a customer who had written their application prior to the JSDO handling before-image data. The signature of the ABL routine that implements a Data Object Submit operation previously supported only an OpenEdge ProDataSet parameter. With this release, you can also use a single temp-table parameter instead. However, a single temp-table parameter does not support before-imaging. So, you must provide your own custom implementation to manage the record changes that you handle with Submit. The recommended approach continues to be to use a ProDataSet.

In conjunction with this JSDO release:

1. The Progress Data Service Template in the Telerik platform was updated based on changes suggested by Telerik. These changes included using the MVVM model (Model-View-View Model) for organization of code to make modifying the template easier. The MVVM model follows the Progress methodology of separating business logic from the UI components
2. A new CRUD Sample is being developed to make available through GitHub. This sample is to help our customers learn how to create an application with Master/Details views with CRUD operations. It uses the Progress Data Service Template and shows how a developer can extend the template to develop an application.

Release 4.1

Release 4.1 contains Rollbase specific functionality (sqlQuery) and common alias names for the CRU operations.

The following is a list of changes in the 4.1.0 Mobile Release:
• Aliases were added for the following methods
o read() for fill()
o update() for assign()
o create() for add()

• Aliases were also created for the following callbacks
o beforeRead for beforeFill
o afterRead for afterFill

• Support for iOSBasicAuthTimeout
To work around a bug in Apache Cordova, the progress.data.Session login() code will set a timeout when it makes an asynchronous request using HTTP Basic authentication from an iOS device (the timeout will be set only under those conditions). The timeout defaults to 4 seconds but can be overridden by the programmer.

• Added the ability for the JSDO to create a SQL query for Rollbase to retrieve a subset of records. This is similar to the ABL filter introduced in 4.0

The following is a list of issues that were fixed in the release:

• Update error messages for clearer understanding of messages

• Fix a problem in Rollbase when updating a new record that has not been saved.

• Changed the return code of logging out from true to false when web server is not running

• Login using Form based authentication now works even if the preliminary response from the server is a status code 403 instead of the expected 401