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

[dheerajturaga]

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:

Plugins showing only for tutorial dag:

plugins showing for example_* dags:

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)
  ClaudeCode Opus 4.8

[pierrejeambrun]

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]

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]

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.

[bbovenzi]

The dependency order is a fair point.

I also want to think more if the filter patterns in this PR are the way we want to go. I fear that it could quickly becoming unruly with too many specific ways to filter a dag or task, each one being its own optional parameter.

[dheerajturaga]

Hi @pierrejeambrun, @bbovenzi
Thanks for the feedback. The challenge I am facing is that we have several plugins that we have created that we need displayed as a new tab within the dag run page. Today, I cannot "hide" the tabs which are irrelevant to the dags. I rather need to display "nothing" or some useful message to indicate this tab isnt supported for this dag.

In my case I have 6-7 plugins (and growing) which are dag specific or tag specific and I dont want to display these tabs for unrelated dags. Hence my approach.

Im happy to take suggestions in alternate ways of implementation. Please let me know

[dheerajturaga]

Thanks for the feedback, both points landed. Proposal to address them:

Instead of three flat parameters (which would keep growing — I also want task-level scoping), collapse everything into a single optional applies_to object:

"applies_to": {
    "dag_tags": ["ml"],                      # Dag carries any of these tags
    "dag_ids": ["train_pipeline"],           # exact dag_id
    "task_ids": ["train_model"],             # exact task_id
    "operators": ["KubernetesPodOperator"],  # task's operator class
}

Semantics like Kubernetes label selectors: OR within a key, AND across keys, omit applies_to entirely → tab shows everywhere (current behavior). I'm dropping dag_id_pattern — glob matching was the most bespoke part and I don't need it.

On the concerns raised:

• API sprawl: the schema gains exactly one field, ever. Future criteria become keys inside one model rather than new top-level parameters.
• Dependency direction: dag_tags puts the opt-in on the Dag side (the Dag author tags their Dag to receive the tab), and operators is the case where the plugin legitimately knows what it applies to — a plugin built for a specific operator. dag_ids and task_ids round it out as exact-match criteria for plugins tied to a specific Dag or task.

I'd also split the "pass dag (and task/TI) context to React app plugins" change into a separate PR, since it's independent and useful for self-contained plugins regardless.

If this shape looks reasonable I'll rework the branch.

---

Drafted-by: Claude Code (Fable 5); reviewed by @dheerajturaga before posting