Column Visibility Problem

[anwesha-smsrc]

The problem is there are three columns on the dashboard- for bimonthly, four monthly and MAT, MAT= annual basis, they want it in a certain way that for alternate bimonthly periods, the bimonthly data needs to be shown otherwise it should not appear on the Superset dashboard, now these columns are calculated field, in this scenario how can they alternatively appear? Is it possible in Superset without manual intervention? the column will be there anyways on the dashboard so if the sql query filters that specific column for that phase, it might show error on the dashboard. So is there any solution in this case?

@dosubot

[dosubot[bot]]

Hi @anwesha-smsrc! I'm Dosu and I’m helping the superset team.

Superset doesn't have a built-in feature to automatically show/hide columns based on the current time period at the rendering layer. However, the best approach for your scenario is Jinja templating in your SQL query, which can dynamically control what columns appear without manual intervention.

Using Jinja to conditionally include columns:

You can use Jinja logic in a virtual dataset (SQL Lab query) or calculated column to check the current date and decide whether to include the bimonthly column. For example:

SELECT
  id,
  four_monthly_value,
  mat_value,
  {% set current_month = modules.datetime.datetime.now().month %}
  {% if current_month in [2, 4, 6, 8, 10, 12] %}
    bimonthly_value
  {% else %}
    NULL AS bimonthly_value
  {% endif %}
FROM your_table

This way, during non-bimonthly periods the column returns NULL instead of being removed entirely — avoiding dashboard errors from a missing column [1].

If you use dashboard filters to drive the period, you can leverage the filter_values() Jinja macro to read the selected filter and conditionally control the column content:

SELECT
  id,
  four_monthly_value,
  mat_value,
  {% if filter_values('period_type')|first == 'bimonthly' %}
    bimonthly_value
  {% else %}
    NULL AS bimonthly_value
  {% endif %}
FROM your_table

The key insight is: keep the column in the query but return NULL when it shouldn't display data — this prevents the dashboard from breaking due to a missing column reference.

Additional options to consider:

• Conditional formatting can visually de-emphasize the bimonthly column (e.g., gray it out) when it's not the active period, though this only changes styling, not visibility [2].
• If you're using the AG Grid Table (Table V2), end users can manually hide/unhide columns via column header menus, but this requires manual interaction [3].
• Fully automatic column removal based on filters is a commonly requested feature but isn't natively supported yet.

Would you like me to look into specific Jinja templating examples or how to set up the date-based logic for your particular bimonthly schedule?

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[dosubot[bot]]

I wasn't able to read the Excel file contents directly, but based on your description I understand the challenge:

• Your data is in a pivot structure — meaning the period names (e.g., "Jan-Feb", "Mar-Apr", etc.) are column headers, not values in a row.
• Columns B and C are calculated metrics that should only show values for alternate bimonthly periods.
• There's no separate "period" column in the data source to filter on.

This is a tricky scenario. Here's how you can approach it:

Step 1: Unpivot the data

Since the periods are column names (pivot format), create a virtual dataset in SQL Lab that unpivots them into rows. For example (syntax varies by database):

-- PostgreSQL example using UNION ALL
SELECT 'Jan-Feb' AS period, jan_feb_col_b AS metric_b, jan_feb_col_c AS metric_c FROM your_table
UNION ALL
SELECT 'Mar-Apr' AS period, mar_apr_col_b AS metric_b, mar_apr_col_c AS metric_c FROM your_table
UNION ALL
-- ... repeat for each period

This gives you a proper period column to work with.

Step 2: Apply Jinja conditional logic

Once you have a period column (even if synthetically created), you can use Jinja to conditionally show the bimonthly calculated values:

SELECT
  period,
  {% set bimonthly = ['Jan-Feb', 'Mar-Apr', 'May-Jun', 'Jul-Aug', 'Sep-Oct', 'Nov-Dec'] %}
  {% set p = filter_values("period") %}
  {% if p and p[0] in bimonthly %}
    metric_b AS bimonthly_calc_value
  {% else %}
    NULL AS bimonthly_calc_value
  {% endif %},
  four_monthly_value,
  mat_value
FROM (
  -- your unpivoted query here
) AS unpivoted_data

If you want to keep the pivot structure and can't unpivot, an alternative is to use Jinja with datetime (requires JINJA_CONTEXT_ADDONS config) to check the current month and conditionally select the right pivot column:

{% set m = datetime.now().month %}
SELECT
  {% if m in [2, 4, 6, 8, 10, 12] %}
    bimonthly_pivot_column AS bimonthly_value,
  {% else %}
    NULL AS bimonthly_value,
  {% endif %}
  four_monthly_column,
  mat_column
FROM your_table

The core challenge is that without a filterable period column in the data, you need either:

1. Unpivot the data to create one, or
2. Use the current date via Jinja to automatically determine which period you're in

Could you share a screenshot of the Excel? That would help me give you a more precise query for your exact column structure.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[anwesha-smsrc]

Company	Rx JAN-FEB 2026	Rank JAN-FEB 2026
A	35	3
B	67	2
C	77	1

this is the excel content @dosu

[dosubot[bot]]

Thanks, now I see the structure clearly. So your data looks like:

Company	Rx JAN-FEB 2026	Rank JAN-FEB 2026	(Rx MAR-APR 2026)	(Rank MAR-APR 2026)	...

The period is embedded in the column name itself — there's no separate period column. The columns Rx JAN-FEB 2026 and Rank JAN-FEB 2026 are the calculated fields, and you want them to only appear during that bimonthly period.

Here's the approach I'd recommend:

Use Jinja with the current date to conditionally select the right columns. Since the period info is baked into column names, you can map the current month to the correct bimonthly column:

{% set m = datetime.now().month %}
{% set y = datetime.now().year %}

{% if m in [1, 2] %}
  {% set period = 'JAN-FEB ' ~ y %}
{% elif m in [3, 4] %}
  {% set period = 'MAR-APR ' ~ y %}
{% elif m in [5, 6] %}
  {% set period = 'MAY-JUN ' ~ y %}
{% elif m in [7, 8] %}
  {% set period = 'JUL-AUG ' ~ y %}
{% elif m in [9, 10] %}
  {% set period = 'SEP-OCT ' ~ y %}
{% else %}
  {% set period = 'NOV-DEC ' ~ y %}
{% endif %}

SELECT
  "Company",
  "Rx {{ period }}" AS "Rx Bimonthly",
  "Rank {{ period }}" AS "Rank Bimonthly"
FROM your_table

This will automatically pick the right bimonthly columns based on the current date — no manual intervention needed. For example, right now (April 2026) it would resolve to:

SELECT
  "Company",
  "Rx MAR-APR 2026" AS "Rx Bimonthly",
  "Rank MAR-APR 2026" AS "Rank Bimonthly"
FROM your_table

To set this up:

1. Make sure your Superset admin has enabled Jinja templating [1]:

   FEATURE_FLAGS = {"ENABLE_TEMPLATE_PROCESSING": True}

2. Expose datetime in the Jinja context [2]:

   # superset_config.py
   from datetime import datetime
   JINJA_CONTEXT_ADDONS = {"datetime": datetime}

3. Create this query as a virtual dataset in SQL Lab and save it. Then build your chart on top of it.

For the four-monthly and MAT columns, you'd apply the same pattern — just adjust the month mappings and column name patterns accordingly. You can include all three (bimonthly, four-monthly, MAT) in the same query, each with their own Jinja conditional to pick the right period column.

The key advantage: the column aliases (Rx Bimonthly, Rank Bimonthly) stay consistent, so your dashboard chart never breaks — only the underlying source column changes automatically with each period.

Would you like me to write the full query including the four-monthly and MAT columns as well?

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[anwesha-smsrc]

As I have mentioned earlier, it is not datetime column also the metric name is written manually @dosu

[dosubot[bot]]

I understand — to clarify what I meant: the Jinja solution I proposed does not require a datetime column in your data. It uses datetime.now() purely as a Python function at query render time to figure out which string-named column to pick. Your data stays exactly as-is — string column names like "Rx JAN-FEB 2026".

However, I see the deeper issue now: the metric/column names are manually written in your Superset chart configuration (in the Metrics section), not dynamically selected. So even if the SQL can be made dynamic, you're defining the metric by hand in the chart builder as something like:

Custom SQL: "Rx JAN-FEB 2026"

And you'd have to manually change that every period.

Here's how to solve that — create a virtual dataset that does the work for you:

1. Go to SQL Lab and write this query:

SELECT
  "Company",
  COALESCE(
    "Rx JAN-FEB 2026",
    "Rx MAR-APR 2026",
    "Rx MAY-JUN 2026",
    "Rx JUL-AUG 2026",
    "Rx SEP-OCT 2026",
    "Rx NOV-DEC 2026"
  ) AS "Rx Bimonthly",
  COALESCE(
    "Rank JAN-FEB 2026",
    "Rank MAR-APR 2026",
    "Rank MAY-JUN 2026",
    "Rank MAY-JUN 2026",
    "Rank SEP-OCT 2026",
    "Rank NOV-DEC 2026"
  ) AS "Rank Bimonthly"
FROM your_table

This assumes only the current period's columns have values and the rest are NULL. If that's the case, COALESCE simply picks whichever period has data.

2. If all period columns have data simultaneously (not just the current one), then you do need some way to pick the right one. In that case, the Jinja approach is the only automated option — and it works entirely on string column names, not datetime data:

-- This is pure string logic, no datetime column in your data needed
{% set periods = ['JAN-FEB 2026', 'MAR-APR 2026', 'MAY-JUN 2026', 'JUL-AUG 2026', 'SEP-OCT 2026', 'NOV-DEC 2026'] %}
{% set current_period = periods[((datetime.now().month - 1) // 2)] %}

SELECT
  "Company",
  "Rx {{ current_period }}" AS "Rx Bimonthly",
  "Rank {{ current_period }}" AS "Rank Bimonthly"
FROM your_table

3. Save this as a virtual dataset, then build your chart on it. Your metric just references the stable alias "Rx Bimonthly" — you write it once and never change it again.

The key point: you write the metric name once as Rx Bimonthly in your chart config, and the virtual dataset handles mapping it to the correct period column automatically. No manual metric name changes needed each period.

If Jinja is not an option in your environment (e.g., ENABLE_TEMPLATE_PROCESSING can't be enabled), then unfortunately there's no fully automatic way to do this in Superset — you'd need to either restructure the data upstream (unpivot so periods become rows) or manually update the metric each period.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.