Looker 5.10 Release Notes

  • 7 March 2018
  • 2 replies

Userlevel 5

Anticipated Deployment Dates

Release Rollout Begins: March 11, 2018

Release Final & Download Available: March 26, 2018

Release Highlights

In addition to general tweaks and enhancements, this release comes with new and improved features in the following categories. Read on for more detail.

Preparing for Release

Please take notice of items marked with a ⚡ as they indicate changes to existing functionality and may require your attention. For more information see Features by Section below.

Notable Features

Content Validator for Lookless Dashboards

The Content Validator is now able to scan for, identify, and fix broken content in Tiles on Lookless Dashboards. Lookless Tiles will now appear in the Content Validator along with regular Looks, and will be included in the “Replace or Remove” process.

${view_name.SQL_TABLE_NAME} to Reference Any View

LookML Developers will be able to reference any view (including regular views, persistent, and non-persistent derived tables) using the ${view_name.SQL_TABLE_NAME} substitution variable in any LookML parameter where valid SQL is accepted. This substitution parameter is not yet viable in the SQL Runner.

Navigate Schedules by User

Can’t remember where everything you scheduled is? Don’t fret! All users with the schedule permission are now able to view, navigate, and edit their schedules from one place. Please note this feature lists schedules by the user who owns the schedule, not users who receive the schedule.

Features by Section

Content Management and Discoverability

  • Content Validator for Lookless Dashboards. The Content Validator is now able to detect and solve issues in saved tiles on Lookless Dashboards.

  • [labs] Save Merged Results to dashboards. Users can now save Merged Results queries to Dashboards. Please note: these elements do not currently interact with Dashboard-level filters. Learn more about configuring Merged Results.

LookML and Development

  • The partition_keys parameter now requires quotes around list items. Learn more.

  • Added the ability to create a new Project via the API. The new create_project call allows API users to create a new LookML Project for development in the UI.

  • ${view_name.SQL_TABLE_NAME} is now usable in most sql: parameters. Learn more.

  • Added ability to include custom filters in Native Derived Table definition. New expression_custom_filter parameter allows developers to define custom filters on NDTs in LookML. Learn more.

Platform and Administration

  • Introducing schedule list by user. Users are now able to see and navigate their saved schedules all in one place.

  • Added allowed_clock_drift support for SAML configurations. Learn more.

Scheduling and Downloading

  • 🛠 Dashboard PDFs and Scheduled Visualizations is now enabled by default. In order to have access to rendering options, administrators will need to download the PhantomJS version 2.1.1 on the server hosting the Looker application.

  • Added support for number formatting in Excel. Downloads with number fields no longer appear as strings in Excel.


  • Added Dremio support.

  • Updated Snowflake support to include IN statements where appropriate.


- Restricted the ability to use a user-editable user attribute towards parameterized database connections.
- Tightened access to application database.
- Removed an XSS vulnerability on the `admin/connections/.../edit` page.
- Addressed a SAML authentication bypass vulnerability.

General Tweaks and Bug Fixes

  • Dashboards, Visualizations, and Explore

    • ⚡ Added error checking to prevent one field from having two or more filters on a dashboard.

    • Fixed a family of bugs caused by over-row-limit Looks.

    • Fixed a bug where maps were not responding to filter changes.

    • Fixed a bug with scrolling and rendering many dashboards on the move dashboard modal.

    • Fixed a bug where values containing commas could not be set as filter defaults on dashboards.

    • Fixed a bug where dashboard filters do not listen to user attribute default values when Allow Multiple Filter Values is off.

    • Fixed a bug where option + click did not restore all values in an explore when Show Silhouette of Disabled Series was enabled.

    • Fixed a bug where filters of type “1, not 0” would fail.

    • Fixed a bug where deleting a Look that was connected to a dashboard would break the dashboard.

  • LookML and development

    • Added warning checks before generating dashboard LookML.

    • Fixed a bug where the IDE could not handle git branches with periods in the name

    • Fixed a bug where counts in one-to-many joins generated the wrong SQL if the count was filtered but not selected.

    • Fixed a bug with user attributes tied to parameters.

    • Fixed a bug where date-type parameters were blank when referenced in always_filter parameter.

  • Content Management and Discoverability

    • Added a tooltip explaining that absolute URL paths (as opposed to relative paths) are needed for external links on dashboards.

  • Scheduling and Downloading

    • Added sanitization of reserved characters in file names of downloaded dashboard CSVs.

    • Fixed a bug on the scheduler modal where toggling between datagroup and schedule toggled all schedules, instead of the selected schedule.

    • Fixed a bug where table calc formats were still coming through unformatted Excel downloads

    • Fixed a bug with the “Send Attachment” Slack integration for non-ZIP attachments

  • Dialects

    • Fixed a bug where prepended comments for Snowflake queries were not visible.

  • Platform and Administration

    • Added custom filtering on LDAP queries.

    • Fixed a bug where disabling users returned an “undefined” error.

    • Fixed a bug causing persistent persistent sessions for some users.

2 replies

Userlevel 1

Very cool!

Will be able to build derived tables off of the SQL_TABLE_NAME feature off of views?

Use Case:

I have some set of columns in a table that are Unix timestamps. I write the dimensions with the proper sql code to convert that into a date type. Before, if I built a derived table off of that table I would have to repeat my sql code to convert that column. But now can I just refer to the view and not have to repeat my type conversion code?

Hi Tao, you can refer to a regular view with ${my_view.SQL_TABLE_NAME}, but it won’t behave the way that you describe. It will directly substitute in the value in the view’s sql_table_name parameter (which can be more than just a simple table reference, by the way).

What you need is not currently possible but is definitely something that we are actively thinking about!