December 17, 2016

This is the last Release Notes for the year of 2016. We are thrilled that you have been with us all this year, and we are looking forward to seeing you soon - in 2017!
Merry Christmas and Happy New Year!

 

Incremental Load in Automated Data Distribution

In addition to full load mode, Automated Data Distribution (ADD) now supports incremental load mode.

ADD automatically selects the load mode for a dataset depending on whether the output stage table mapped to this dataset has a special column called 'x__timestamp' identifying particular increments.

You can override the pre-selected incremental load mode for particular datasets with full load mode (when you need to completely overwrite data in the datasets) or with loading data from a specific time interval (between two timestamps).

Learn more:
Automated Data Distribution

 

Multi-Language Support for GoodData Portal

In one of the past releases, we introduced multi-language support for embedded dashboards: you can set up a language which will be used in embedded dashboards that a user can view. You do this using the language parameter in the user provisioning API call.

Now, you can choose to apply the set language to the other parts of the GoodData Portal as well:

  • Dashboards
  • Reports
  • Manage
  • User menu

  

For more details on the available languages and an example of the user's settings, see Multi-Language Support for Embedded Dashboards.

How can you turn this feature on?
This feature is available by request.
By default, the language is applied only to the embedded dashboards. If you want to keep it like that, no action is needed.
If you want to change it so that the language is also applied to the above mentioned parts of the GoodData Portal, please contact GoodData Support. Our specialists will enable this feature for you.

 

Order of Applying Filters in Reports with Drilling

We have changed the order of applying filters in reports where drilling across is applied (clicking a metric or attribute value opens another report). The drill filter is now applied first.
This better reflects the analysis flow, and it helps avoid the situations when no data is returned.

Imagine the following situation:

  • You have a dashboard with a date filter for the last month.
  • There is a report listing your company's sales departments and limited to the top 5 departments by the total number of closed deals (original report).
  • A drill-across setting is set up for this report: when you click a department's name, you can see a report listing employees from this department and limited to the top 10 employees by the number of closed deals.

This is how the filters were applied BEFORE:

  1. Dashboard filter (last month)
  2. Filters from the linked report (top 10 employees by the number of closed deals)
  3. Filters from the original report (top 5 departments by the total number of closed deals)
  4. Drill filter (filters out only the employees from the department that you clicked in the original report)

And this is how the filters are applied NOW:

  1. Drill filter (filters out only the employees from the department that you clicked in the original report)
  2. Dashboard filter (last month)
  3. Filters from the linked report (top 10 employees by the number of closed deals)
  4. Filters from the original report (top 5 departments by the total number of closed deals)

Learn more:
Drilling into Reports
Drilling Across

 

Authentication Logic Improvements

We have updated the API authentication process to be more flexible.

We expect that you should not be affected by this change, however, the key differences are:

  1. The verify_level attribute that can be sent in the payload of requests to the /gdc/account/login resource is now used only to control how the server returns the new Super Secured Token (SST).
  2. The /gdc/account/token resource returns the new Temporary Token (TT) based on where the SST was supplied in the request (i.e. an HTTP cookie if the request contained an SST in the cookie or the body or custom HTTP header if the SST came in the custom header). The header always takes precedence if both the cookie and the custom header contain an SST.
  3. REST API calls may contain the TT in the custom HTTP header and in the cookie (regardless of the initial verify_level sent to the login resource). The custom HTTP header always takes precedence if a TT is sent in both the custom header and the cookie.

Learn more:
API: Authentication use case
API: Authentication

 

Action Needed: Upcoming Update of Google Analytics Component

For customers using Google Analytics

We are planning to update the Google Analytics component on the GoodData platform.

How can you get prepared?
Enable the Google Analytics Reporting API in your Google Analytics project:

  1. Open a browser and go to the Google API Manager at https://console.developers.google.com/apis/api/analyticsreporting.googleapis.com/overview.
  2. Select your Google Analytics project.
  3. Click Enable API.
    The page with API details opens.
    The API is enabled.
    Note: It may take a few minutes before the changes get propagated to your project.

 

Reminder: Install CloudConnect Version 113.0.0

For CloudConnect users

Download and install the latest CloudConnect version, 113.0.0, which is available at the GoodData Developer portal. Do so before on February 9, 2017.

Why should you do that?
CloudConnect version 113.0.0 uses Java 8 while older versions still use Java 7. The versions of CloudConnect that use Java 7 have been deprecated and will stop working on February 9, 2017.

A full new installation is required:
Perform a full new installation of CloudConnect version 113.0.0 to a different location, or uninstall your current CloudConnect and install the latest version from scratch.

Important! Do not perform a check for updates from your current version of CloudConnect: this will upgrade your CloudConnect only to version 112.0.0, which still uses Java 7. To move to the latest version (113.0.0) correctly, you must perform a full new installation of the latest version.

 

End-of-life of /etl/pull Rescheduled to March 23, 2017

We have rescheduled the end-of-life of the /etl/pull REST API resource. The new end-of-life date is March 23, 2017.
On March 23, 2017, the /etl/pull resource will stop working.

We strongly recommend that you switch to the /etl/pull2 resource as soon as possible. The /etl/pull2 resource is asynchronous, allows for a faster data upload, and helps avoid time-outs. For the instructions, see Data Upload API Resource.

Have more questions? Submit a request

Comments

Powered by Zendesk