Skip to content

UI: Allow scoping plugin tabs to specific Dags by tag or id#69148

Open
dheerajturaga wants to merge 1 commit into
apache:mainfrom
dheerajturaga:gate-plugin-tabs-by-dag-tags-and-id
Open

UI: Allow scoping plugin tabs to specific Dags by tag or id#69148
dheerajturaga wants to merge 1 commit into
apache:mainfrom
dheerajturaga:gate-plugin-tabs-by-dag-tags-and-id

Conversation

@dheerajturaga

Copy link
Copy Markdown
Member

Plugin external views and React apps that target the Dag, Dag run, task, or task instance pages previously appeared on every Dag, with no way to limit a tab to the Dags it is relevant to. This adds optional dag_tags, dag_ids, and dag_id_pattern filters so a tab is shown only on Dags that match (combined with OR), while omitting them preserves the show-everywhere default. The current Dag is also passed to React app plugins so they can tailor their own content.

Plugin showing on all dags:
all_dags_plugin

Plugins showing only for tutorial dag:
tutorial_only_plugin

plugins showing for example_* dags:
example_only_plugin

Was generative AI tooling used to co-author this PR?
  • Yes (please specify the tool below)
    ClaudeCode Opus 4.8

Plugin external views and React apps that target the Dag, Dag run, task, or
task instance pages previously appeared on every Dag, with no way to limit a
tab to the Dags it is relevant to. This adds optional dag_tags, dag_ids, and
dag_id_pattern filters so a tab is shown only on Dags that match (combined with
OR), while omitting them preserves the show-everywhere default. The current Dag
is also passed to React app plugins so they can tailor their own content.

@pierrejeambrun pierrejeambrun left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is possible to pass all those attributes to the plugin already. (dagId, taskInstanceId, runId).

Always displaying the tab, and let the Plugin display 'nothing' or a specific message depending on the relevant parameters, so everything is still self contained in the plugin, and the plugin remains responsible for displaying whatever it feels like depending on the params.

This adds complexity just for the sake of 'hiding the tab', I don't think it's worth it.

@bbovenzi

bbovenzi commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

Actually I think this can make sense. If you want a plugin to only work for one dag or task. Then adding an empty tab to hundreds of other tasks or dags is not a great UX. I can definitely see that a plugin would be only relevant to a certain operator.

@pierrejeambrun

pierrejeambrun commented Jul 10, 2026

Copy link
Copy Markdown
Member

That's possible and make sense, the thing I don't like is that it reverses the dependency from core to plugin, to decide what to do instead of having plugin self contained, deciding for themselves what they should display. And that's added complexity and code for something that isn't really harmfull. (showing a plugin tab that will render, "Plugin not available for this operator...." is fine to me. (instead of having people wonder where the plugin tab is, why it's not displaying there, I find it actually more confusing)

But if we want this in I'm fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants