Restore the Apply To field on product attribute forms (#21025) - #41222

Description (*)

Continues #27625 by @Bartlomiejsz, who has left the organization. His commits and authorship are preserved; the branch is merged with the current 2.4-develop.

Since the product creation flow was streamlined, the Apply To field is gone from the product attribute form, so an attribute cannot be limited to specific product types from the admin any more. The storage and consumption side never went away: apply_to is still a column, Save still handles it for system attributes, and the product form modifier still filters attributes by it. In #21025 the product owner agreed (May 2020) that the field has to come back, and the issue was re-confirmed on 2.4-develop in February 2026.

This PR brings the Apply To multiselect back to Stores > Attributes > Product > Advanced Attribute Properties:

• Advanced block: apply_to multiselect fed by the new Magento\Catalog\Model\Attribute\Source\ApplyTo option source (ProductTypeListInterface), disabled for saved system attributes like is_unique. The source is an optional trailing constructor parameter with an ObjectManager fallback, since the block is @api.
• Save controller: when a user-defined attribute is saved without any type selected, apply_to is explicitly set to an empty array. A cleared multiselect is not posted at all, so without this the stored value would silently survive.

Changes on top of the original PR:

• merged with 2.4-develop; the unit tests were rewritten upstream for PHPUnit 12 in the meantime, so the original test changes were replaced by tests that cover the new behaviour (field rendered with the source options, disabled for system attributes, apply_to reset when not posted, left untouched for system attributes)
• unrelated refactoring from the original diff dropped (constructor change for the property locker, import reordering, strict_types on the controller)
• the product-page "Add Attribute" popup is deliberately left unchanged, see below
• the MFTF test was dropped: it depended on moving the attribute into an attribute set by drag and drop and asserted absence with a selector that could never match; unit coverage replaces it

Why the popup stays without the field: the same product_attribute_add_form is opened by the Create Configurations wizard, and ConfigurableAttributeHandler only accepts attributes whose apply_to is empty or contains simple, virtual and configurable. Exposing Apply To there lets an admin create an attribute that vanishes from the wizard he just opened, which is the confusion reported during the original review. The attribute grid form is the place where the full type list is meaningful.

Related Pull Requests

• Fix #21025 - Missing "Apply To" when editing Product attributes #27625 (original, by @Bartlomiejsz)

Fixed Issues (if relevant)

1. Fixes Missing "Apply To" when editing Product attributes #21025

Manual testing scenarios (*)

1. Stores > Attributes > Product > Add New Attribute, expand Advanced Attribute Properties: an Apply To multiselect lists the installed product types.
2. Select Simple Product only, save, assign the attribute to the default attribute set: it appears on a simple product's form and not on a virtual product's form.
3. Edit the attribute, deselect all types, save: the attribute now applies to all types again.
4. Edit a system attribute (for example color): the field is shown read-only.
5. Catalog > Products > Add Product > Add Attribute > Create New Attribute: the popup is unchanged.

Questions or comments

Gates run locally: unit (attribute block and controller suites, 56 tests), integration (attribute controller and block suites, 82 tests), PHPCS, PHPStan and the Static Tests LiveCodeTest on the changed files are clean. Both new unit tests fail without the change and pass with it.

The Semantic Version Checker will report the new optional constructor parameter on the @api block Advanced and the new ApplyTo class.

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)