Category product count does not include products assigned to the category itself

[mimou78]

Summary

This pull request fixes an issue where the product count displayed in the Admin Category Grid
incorrectly shows 0 products for categories that do not have any descendants.
The current logic only counts products assigned to descendant categories and does not
include products directly assigned to the category itself.

Problem

When building the temporary table of category → descendant relationships, the SQL
logic only inserts rows for descendants, not for the category itself.
As a result:

• Leaf categories always show 0 products
• Parent categories show incomplete counts
• The Admin UI becomes misleading for merchants

Related Issue
Fixes #40263

What This Fix Does

This change ensures that each category always includes a self-reference entry in
the temporary category/descendant table.
As a result:

• Products directly assigned to the category are counted correctly
• Categories without children no longer show a zero count
• Product assignment visibility in Admin becomes accurate

Technical Changes

• Added a self-reference row (category_id = X, descendant_id = X) for every
  processed category ID.
• Ensured that the final SQL aggregation counts products from both descendants
  and the category itself.
• Updated unit tests to validate multiple insert calls for self-references.

Testing Instructions

1. Create a category with no children.
2. Assign one or more products to it.
3. Clear cache and refresh the Category Grid.
4. Product count should now display the correct value instead of zero.
5. Repeat with nested categories to confirm descendant counts still work.

Backward Compatibility

• No schema changes.
• No API changes.
• Fully backward compatible.

Risks

Low. This affects only the temporary table generation used for counting, not
the category model or product relations.

[m2-assistant]

Hi @mimou78. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[ct-prd-pr-scan]

The security team has been informed about this pull request due to the presence of risky security keywords. For security vulnerability reports, please visit Adobe's vulnerability disclosure program on HackerOne or email [email protected].

[ct-prd-pr-scan]

The security team has been informed about this pull request due to the presence of risky security keywords. For security vulnerability reports, please visit Adobe's vulnerability disclosure program on HackerOne or email [email protected].

[mimou78]

@magento run all tests

[mimou78]

@magento run all tests

[mimou78]

@magento run all tests

[mimou78]

@magento run Static Tests

[swnsma]

Should we keep it as it is?
The implementation relies on the DataObject magic method and we explicitly add this method via

addMethods(['getIsAnchor'])

I don't like the idea of introducing \Magento\Catalog\Test\Unit\Helper\CategoryTestHelper because we:

1. Creating new layer with a class that will be used only in tests
2. Futher dependency on DataObject's magic method would require us extending this class for Categories and introducing even more classes for other entities.

Le't keep it as simple as possible and leave how it was before.

[mimou78]

Thanks for the feedback!
I fully understand your concern about introducing an extra layer that would only be used in tests.

The reason I went with this approach is that addMethods() is deprecated, and relying on DataObject magic methods is something Magento is gradually moving away from.

I followed the structure already used in the core—for example, Magento/Catalog/Test/Unit/Helper/ProductTestHelper. I tried to stay aligned with the same pattern for categories so the test suite remains consistent and future-proof.
My intention wasn’t to add unnecessary classes, but simply to avoid deprecated behavior and ensure our tests remain stable over time.

I’m of course open to discussion if you think we should take a different direction.

[swnsma]

Thank you for your changes!
Could you have a look at my small note about unit tests?