[dheerajturaga]

Plugin external views and React apps that target the Dag, Dag run, task, or task instance pages appear on every Dag, with no way to limit a tab to the Dags and tasks it is relevant to. A deployment running several Dag-specific plugins ends up with tabs that are dead weight on unrelated Dags, and a plugin cannot hide its own tab from inside itself.

This adds a single optional applies_to block:

"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"],  # operator class name
    "operator_names": ["@task.bash"],         # UI/display name
}

All keys are optional; omitting applies_to shows the item everywhere, which is the existing behaviour. operators matches operator class names only. operator_names matches UI/display names (custom_operator_name), including decorator names such as @task.bash.

Criteria combine like Kubernetes label selectors — OR within a key, AND across keys — but the AND applies only across the keys the current page can evaluate. A task_ids criterion cannot be judged on a Dag-level page, so it is skipped there rather than failing the match. That lets one applies_to block be shared by a plugin's Dag- and task-level destinations instead of needing one per destination.

Scoping is also applied to the dag_overview and task_overview React app destinations, which filter locally rather than going through usePluginTabs — without that, a scoped plugin still rendered its panel on every Dag.

Plugin showing on all Dags:

Plugins showing only for the tutorial Dag:

Plugins showing for example_* Dags:

On the feedback in this thread:

• API sprawl — the schema gains exactly one field, ever. Future criteria (e.g. asset_groups for asset pages) become keys inside PluginAppliesToResponse rather than new top-level parameters. I've deliberately kept this PR to the Dag/task axis so the model can be reviewed on its own; assets are a natural follow-up.
• Dependency direction — dag_tags puts the opt-in on the Dag side: the Dag author tags their Dag to receive the tab. operators is the case where a plugin legitimately knows what it applies to. dag_ids and task_ids cover deployments where the Airflow operator, not the plugin author, knows the mapping.
• Since UI: Pass Dag, DagRun, TaskInstance, and Asset objects to React app plugins #70149 landed, a plugin can self-gate its content. applies_to gates the tab affordance, which a plugin cannot do from inside itself — that is the remaining gap.

dag_id_pattern from the earlier revision is dropped: glob matching was the most bespoke part and is not needed.

This is display gating, not an authorization boundary — a user who knows the url_route can still reach the view directly. Noted in the docs.

---

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

• Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

[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

[bbovenzi]

We should add some validation to the _get_ui_plugins() of plugins_manager.py. So we can log error messages if the applies_to are incorrect. Or log a warning that a task filter is applied to the dag level and therefore won't do anything.

[dheerajturaga]

The review-level validation request is addressed in _get_ui_plugins(). Malformed applies_to blocks—wrong container type, non-string or unknown criterion keys, and non-string criterion values—now emit a warning and are removed so the plugin item still loads unscoped. Valid criteria that the destination cannot evaluate also emit a warning, but remain configured because runtime matching intentionally skips unevaluable criteria. Tests cover malformed, unevaluable, and valid configurations.

---

Drafted-by: Codex (GPT-5) (no human review before posting)

[github-actions]

Backport failed to create: airflow-ctl/v0-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	airflow-ctl/v0-1-test

You can attempt to backport this manually by running:

cherry_picker c855392 airflow-ctl/v0-1-test

This should apply the commit to the airflow-ctl/v0-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[dheerajturaga]

@bbovenzi really appreciate your review on this! This implementation will facilitate operator scoped plugins allowing for features such as AIP-115 https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/440305022/AIP-115+On-Demand+Task+Sections

[bbovenzi]

@dheerajturaga Of course. And I'll add the plugin actions soon too so if you want to surface that task run action without a full tab you can do that too.