Fix RESOURCE_ASSET compatibility with Airflow 2.x in common-compat

[jedcunningham]

Summary

Fixes a regression introduced by #63335, which hardcoded RESOURCE_ASSET = "Assets"
in providers/common/compat/security/permissions.py. This value is correct for
Airflow 3, but breaks Airflow 2.x in two ways:

1. Wrong resource name in Airflow 2.x. apache-airflow-providers-fab imports
   RESOURCE_ASSET from this module at runtime. FAB's role sync updates stock roles
   to grant the "Assets" resource, but the correct Airflow 2.x name is "Datasets".
   This creates an inconsistency and pollutes the permission model with a resource that
   doesn't belong in Airflow 2.x.

2. Custom roles break. Any role with "Datasets" permissions stops working, since
   auth checks now look for "Assets". While you could re-grant permissions against
   "Assets" after upgrading, existing roles are silently broken.

Fix

Gate on AIRFLOW_V_3_0_PLUS: return "Assets" for Airflow 3, and fall back to
RESOURCE_DATASET from airflow.security.permissions (not deprecated in Airflow 2.x)
for Airflow 2.x.

Related

• Reverts the behavioral change from: Remove usage of deprecated module airflow.security.permissions in common compat provider #63335

---

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

• Yes (please specify the tool below)

Generated-by: Claude Code

[potiuk]

I guess that means rc2 for common.compat and the two providers that depend on it's new version from the current vote. Thanks for finding and fixing!

[potiuk]

BTW. I do think that the if AIRFLOW* pattern with version is way bettter than "Pythonic" try/except - and this is the reason I was pushing for it @ashb (and @xBis7 as you asked) - the main reason for having this pattern is to know exactly when you can remove it - one of the reasons this one happened was that it was not at all clear if we can remove that try/remove.

Also we will have to find out why this was not detected by compatibility tests - it should have been, but possibly this kind of issue was masked by something. To be diagnosed.

[jedcunningham]

I suspect it wasn't found in the compatibility tests because it caused "Assets" resources and permissions to be created alongside the "Dataset" ones that should have been used. And if you didn't have a custom role (or maybe modified the existing roles) without the dataset perms, its hidden because it "just works", even if its fundamentally wrong.

[jedcunningham]

An example after the upgrade (all default roles get this) (this is before this fix of course):

[potiuk]

There is a mypy issue for providers :(

[Copilot]

Pull request overview

Fixes a compatibility regression in the common-compat provider where RESOURCE_ASSET was hardcoded to the Airflow 3 resource name, which breaks permission/role behavior on Airflow 2.x.

Changes:

• Introduces AIRFLOW_V_3_0_PLUS gating to set RESOURCE_ASSET to "Assets" on Airflow 3.
• For Airflow 2.x, maps RESOURCE_ASSET back to airflow.security.permissions.RESOURCE_DATASET to preserve the "Datasets" permission resource name.

[Copilot]

The conditional import of RESOURCE_DATASET happens after module-level assignments (RESOURCE_BACKFILL, etc.), which will trigger Ruff E402 (imports not at top of file) for this module. To avoid CI/lint failures, move the if AIRFLOW_V_3_0_PLUS block (and the import) above the resource constant assignments, or otherwise ensure the import occurs before any non-import statements (alternatively, use a literal string for the AF2 value if you want to avoid conditional importing).

[Copilot]

This change fixes a version-dependent permission constant, but there’s no regression test that asserts the value of RESOURCE_ASSET for the running Airflow major version (the existing import-only test won’t catch the Airflow 2.x vs 3.x mismatch). Add an assertion-based unit test that checks the expected value under Airflow 2.x vs 3.x (e.g., branch on AIRFLOW_V_3_0_PLUS).