Custom Event Handling in Embedded Analytical Designer and KPI Dashboards
You can now drill on measures and attributes from within embedded Analytical Designer and KPI dashboard into your parent application. This gives your business users a seamless workflow bridging both insights and the parent application.
Learn more:
Setting up Events for Drilling in Embedded Analytical Designer and KPI Dashboards
New API: Project-Specific Metadata Storage
In addition to the API for storing user-specific metadata, you can now use the API for storing project-specific metadata.
Learn more:
API: Project-specific data storage
Analytical Designer Links to a Specific Insight
When using Analytical Designer the URL now displays projectId or clientId and visualisation ID or identifier after "Load/Save/Save as" actions are performed. These can be used when embedding Analytical Designer to link to a specific insight.
Learn more:
Embed Analytical Designer
SSL Certificate Validation for Embedded Content
To increase GoodData platform security, we have tightened SSL certificate validation for dashboard export to PDF.
The validation takes place every time a dashboard is exported to PDF (such as, printing a dashboard, scheduling an email with attached dashboards), and may affect the embedded content on the dashboard.
If your dashboard contains embedded content and the SSL certificate of the servers hosting the content is invalid, the embedded content will be displayed as a gray rectangle in the resulted PDF document.
Action needed:
For the dashboards that contain embedded content, verify that the SSL certificates of the servers hosting that content are always valid.
COPY FROM S3
Data Warehouse now supports new COPY FROM S3 command syntax. S3 credentials are stored through public REST API and can be later referenced in SQL statements. Exception and error info is stored in DB tables instead of local files as is in COPY FROM LOCAL.
Learn more:
API
COPY FROM S3 to Load Data
API Updates
The following API updates are implemented:
- The REST API resource /gdc/md/$project_id/objects/query?category=projectDashboard&limit=$limit
will serialize values of
projectDashboard/content/filters[]/filterItemContent/{universum,default}/{from,to}
always as JSON strings if present; now, those two values are serialized either as JSON integers or as JSON strings based on the value of type.
Same resource as this is /gdc/md/$project_id/obj/$obj_id.
And WebApp has an advanced version of this resource in /gdc/md/$project_id/obj/$obj_id/view which is affected too.
In case of /gdc/md/$project_id/obj/$obj_id will be affected executionContext/content/filters[]/filterItemContent/{universum,default} too. - Each object returned by REST API resources:
/gdc/md/$project_id/objects/query?category=etlFile&limit=$limit
/gdc/md/$project_id/obj/$etlFile_id
will not have parseParam key in etlFile/content section anymore.
No changes are needed on your side.
No impact on your API configuration is expected.
Upcoming Changes: Naming Date Filters
We are going to change the way how the date filters are named when added to a dashboard.
What exactly is going to change?
Now, when you are adding a date filter to a dashboard, the filter is automatically named after the date dimension that it is based on.
When the planned change is made, the newly added date filter will be named after the date dataset that is it based on.
Nothing changes for existing date filters!
This change will not affect the date filters that already exist on your dashboards. It will only be applied to the date filters that you will add after the change is made.
How can you get prepared for this change?
From the GoodData Portal, go to Manage -> Data -> Data Sets, and check the names of the date datasets in your project. Keeping in mind that the dataset names will be used as names for all new date filters, decide whether you want to rename any dataset to make sense once their names are used as filter names.
NOTE: You can and will still be able to rename a date filter on your dashboard at any time.
Learn more:
Filter for Dates
Reminder: Add Mandatory User-Agent Header to API Request
Starting from March 31, 2018, the GoodData REST API will require every API request to contain the User-Agent header. Any API request without the User-Agent header made after March 31, 2018, will be rejected.
The User-Agent header must be in the following format:product/version (your_email@example.com)
where:
-- product is your product name; can include your company name; must not contain spaces or slashes ( / )
-- version is your product version; must not contain spaces or slashes ( / )
-- your_email@example.com is the email of the contact person responsible for the product in your company. The email is optional if you have specified your company name in product.
Examples:Insights-Provisioner/1.0 (gd_integration_person@acme.com)
Acme-Company-GDIntegration/0.9
Action needed:
If you use a tool for handling API calls or a custom library for integrating with the GoodData REST API, update them to include the User-Agent header in every API request.
Although the API change is planned for the next year, we strongly recommend that you do so as soon as possible.
If you have any question, please contact GoodData Support.