v74.1.0¶
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