time_grain always return None in jinja

[jordiisidro]

A clear and concise description of what the bug is.

How to reproduce the bug

The variable time_grain used in SQL templating is always None
Other variables like from_dttm work fine.

Sample query:

select date_trunc(
{%- if time_grain == 'P1D' -%}
'day'
{%- elif time_grain == 'P1W' -%}
'week'
{%- elif time_grain == 'P1M' -%}
'month'
{%- elif time_grain == 'P3M' -%}
'quarter'
{%- elif time_grain == 'P1Y' -%}
'year'
{%- elif time_grain == 'P1Y' -%}
'year'
{% else %}
'month'
{%- endif -%}
, data) as data
, tecnologia, proveidor, count(distinct id_ticket) as incidencies
from inc_pet i
where {% if from_dttm is not none %}
i.data >= '{{ from_dttm }}' AND
{% endif %}
{% if to_dttm is not none %}
i.data < '{{ to_dttm }}' AND
{% endif %}
1=1
group by date_trunc(
{%- if time_grain == 'P1D' -%}
'day'
{%- elif time_grain == 'P1W' -%}
'week'
{%- elif time_grain == 'P1M' -%}
'month'
{%- elif time_grain == 'P3M' -%}
'quarter'
{%- elif time_grain == 'P1Y' -%}
'year'
{%- elif time_grain == 'P1Y' -%}
'year'
{% else %}
'month'
{%- endif -%}
, data)
, tecnologia, proveidor

Expected results

I expect that when Granularity chances the time_grain value changes

Actual results

time_grain always return None

Environment

• superset version: 2.0.1

Checklist

Make sure to follow these steps before submitting your issue - thank you!

• I have checked the superset logs for python stacktraces and included it here as text if there are any.
• I have reproduced the issue with at least the latest released version of superset.
• I have checked the issue tracker for the same issue and I haven't found one similar.

[jordiisidro]

I think is related with GENERIC_CHART_AXES flag.
With charts with GENERIC_CHART_AXES=False it works well, but when I deploy with GENERIC_CHART_AXES=True only works with the chart type Table, with line or bar char doesn't work. In both cases I select for the x axe a date column.

Table chart assigns the time_grain correctly

Line chart, doesn't assign the time_grain

[jordiisidro]

Solved in last version

[jordiisidro]

closed incorrectly.
With the latest version the same problem still happens

[villebro]

@jordiisidro thanks for raising, I'll take a look next week (feel free to nag me if I don't open a PR before next weekend)

[MaksymilianME]

@villebro did you open a PR for this issue? I have the same problem with latest version for time_grains in Jinja. Thanks

[itziarmj]

The same happens to me in version 2.1.0 with from_dttm in the edit chart. It does not happen in the charts contained in the dashboard.

[MaksymilianME]

In my opinion from_dttm works fine both for chart edition and on dasboards. But time grain parameter does not work on any chart. Only on simple Table it looks fine.

[itziarmj]

I think is somehow related, I have managed to get time_grain None together with from_dttm None and to_dttm None.

[mtrentz]

I am currently having the same problem. For me it seems to be related to the type of charts. For example, for Pivot Tables the {{ time_grain }} will always return None. But for Pivot Table (legacy) it will work.

[villebro]

@itziarmj @mtrentz I think I was able to reproduce this issue - out of curiosity, have you enabled the GENERIC_CHART_AXES feature flag?

[itziarmj]

Yes, this happens when GENERIC_CHART_AXES is enabled.

[mtrentz]

@villebro no, i have the following feature flags enabled.

FEATURE_FLAGS = {
        "ALERT_REPORTS": True,
        "ENABLE_TEMPLATE_PROCESSING": True,
        "DASHBOARD_RBAC": True,
        "DRILL_BY": True,
        "DRILL_TO_DETAIL": True,
    }

[villebro]

Ok thank's for confirming @mtrentz @itziarmj - I think I know what's going on, I can probably get this fixed this week to get it into 2.1.1

[MaksymilianME]

Hi @villebro did you manage to fix this issue? This holds me back from moving from 2.0 to 2.1. Cant wait to start using 2.1.
Thanks!

[mapledan]

@villebro no, i have the following feature flags enabled.

FEATURE_FLAGS = {
        "ALERT_REPORTS": True,
        "ENABLE_TEMPLATE_PROCESSING": True,
        "DASHBOARD_RBAC": True,
        "DRILL_BY": True,
        "DRILL_TO_DETAIL": True,
    }

This PR(#23652 ) change the default value of GENERIC_CHART_AXES to true.
You should set GENERIC_CHART_AXES to false.

[unnyns-307]

Hello, also facing the same problem.
We cannot disable GENERIC_AXIS_CHART on Superset cause there are many charts created based one the chart types enabled from this feature flag.
Do we have other alternatives for this case or specific fixing on the code could resolve this too?

[howardcho]

@villebro did the fix for from_dttm make it into version 2.1? I'm using 2.0, and am seeing this issue as well.

I have the following feature flags:

FEATURE_FLAGS = {
        "ALERT_REPORTS": True,
        "ENABLE_TEMPLATE_PROCESSING": True,
        "GENERIC_CHART_AXES": True
}

[duvenagep]

@villebro Any status on this issue. Currently using Superset 3.0.0rc2 and now GENERIC_CHART_AXES=true is the default this issues still seems to persist. Can confirm it works normally on tables but not on line graphs

[rumbin]

The issue still exists in 3.0.1, as it seems. @villebro, you seemed confident to know what needs to be fixed. Any update on this?

[mapledan]

I create the PR #25429 that fix for the from_dttm return None, but I'm not sure about the time_grain issue.

[WojtekWaga]

Hey, it looks like it does not help for time_grain

[rzzldzzl]

Running the latest dev version of superset -
Regardless of "GENERIC_CHART_AXES" being set to True||False, time_grain returns None on the line & bar charts. time_grain does return correctly on the table chart, however.

[Vitor-Avila]

I believe this got fixed with #25842 cc @rusackas

[stepcheunghk]

I believe this got fixed with #25842 cc @rusackas

Thanks for the update @Vitor-Avila, however it seems it only works for v3.0?

[Vitor-Avila]

@stepcheunghk unsure about the version the PR got associated with. @rusackas would you be able to assist determining that? I believe we're also good to close this bug.

[mtrentz]

@Vitor-Avila Hey, coincidentally I've just tested this out. Using docker the 3.0.2 version fixed this issue for me while the 3.0.0 hadn't done so beforehand.

[rusackas]

Thanks for the update @mtrentz - sounds like we ca close this one then :)