Weekly release issued on September 11th, 2020

Highlights & breaking changes

Variables typing

Have you struggled about numeric values when using them in your queries?

For example, let’s say you have a date requester containing different years, like 2019, 2020 or 2021. If you cant to filter data based on the choice of the user, you wanted to do something like:

  $match: {
    domain: "my_data_by_year",
    year: "<%= appRequesters.date %>"

The problem is that year: "<%= appRequesters.date %>" get translated as year: "2020", which will filter data for the string "2020" and not the number 2020. Bummer! To get the value as a number, you had to do year: "{{ <%= appRequesters.date %> | number }}", which is - let’s face it - not very intuitive.

This has finally come to an end! From now on, when writing year: "<%= appRequesters.date %>", it will get translated into year: 2020, as you can expect it. It’ll walso work with boolean values, and actually any other type. It won’t apply if the variable is surrounded by other characters: for example "The horrible year <%= appRequesters.date %>" will translate to "The horrible year 2020".

If you ever find yourself in the very rare case where you have a numerical variable but you’d like to always translate it to a string, it’ll still possible by using the regular JavaScript String constructor: "String(<%= appRequesters.date %>)" will transform to "2020". Again, this is quite unlikely.

This change also affect existing apps, but no worries: the {{ xxx | number }} will continue to work, so it won’t break anything. This syntax is just becoming obsolete, and you can remove it from now on.

In some very rare cases where data contained strings and variables contained numbers, the fact that they were translated to strings automatically could cause a query or filter to not function correctly following this change. If you observe that case, be in touch with our support team, which has ways to revert very quickly this change in your apps, and we will take time to adapt your queries and variables so they work as expected.

We hope this change will ease your mind, as won’t have to think about data types :)

New features

Data Storytellers

  • Templating :: Keep templating format (string, integer)
  • Embed :: Force compact mode with extra params
  • Embed :: Can use extra variables in story
  • Data :: VQB :: Allow to use javascript in vqb codeEditor
  • User Management :: Keep deleted users in database
  • Boilerplate App :: Add DF_MAX_CELLS default value in the etl config
  • User Management :: Validate privileges in UserModel, so bulk creating users cannot introduce typos in database
  • PDF Report & Datawall :: Identify stories with filters for easy filter selection

Bug fixes

Data Storytellers

  • Charts :: Radarchart :: Switch to SFC and fix d3 imports
  • Charts :: Radarchart :: Allow custom order from another column
  • Requesters :: Remove requester from config after delete

New documentation available

  • Demo App :: Remove treemap examples
  • Trial App :: New version of trial app