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

[swnsma]

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

[mimou78]

@magento run Static Tests Unit Tests

[magento-automated-testing]

Failed to run the builds. Please try to re-run them later.

[mimou78]

@magento run Static Tests

[mimou78]

@magento run Unit Tests

[swnsma]

Hi @mimou78,
Thank you very much for your great effort!

Could you please have a look at my comment regarding the newly created fixture?
I'm afraid my position is that it might be a bit excessive, and if we can achieve the same testing goals while introducing less code, that would be a more appropriate approach.

[mimou78]

Hi @mimou78, Thank you very much for your great effort!

Could you please have a look at my comment regarding the newly created fixture? I'm afraid my position is that it might be a bit excessive, and if we can achieve the same testing goals while introducing less code, that would be a more appropriate approach.

Hello, thanks for the feedback!

No worries at all — I’m completely open to alternatives.
Please take a look at my response when you have a moment; I’d really appreciate hearing your thoughts on it.
The complexity of this scenario is actually the main reason why I didn’t initially consider writing an integration test.
I’m happy to discuss any approach that could help simplify things.

[mimou78]

@magento run Integration Tests

[mimou78]

@magento run all tests

[mimou78]

@magento run Functional Tests CE

[swnsma]

Hi @mimou78,
Could you check my reply?
I beleive we can replace the constant \Magento\Catalog\Model\ResourceModel\Category\Collection::BULK_PROCESSING_LIMIT with new constructor param in order to make the implementation more convinient for testing.

[mimou78]

Hi @mimou78,
Could you check my reply?
I beleive we can replace the constant \Magento\Catalog\Model\ResourceModel\Category\Collection::BULK_PROCESSING_LIMIT with new constructor param in order to make the implementation more convinient for testing.

Hi,

Sounds good, I’ll take care of it.
I don’t want to introduce too many changes to avoid breaking backward compatibility. However, if you want my opinion, it might actually be better to remove that condition entirely — even with a small number of categories the behavior would still be beneficial. I’m not really sure what the original logic behind that constraint was.

If we go in that direction, the change should probably be reflected in the changelog, since it wouldn’t be only a bugfix anymore but also an improvement. It may also require a short piece of documentation to explain the purpose of the new parameter and how to configure it.

[swnsma]

Hi @mimou78,
I love your idea. Let's remove the condition entirely - it would significantly reduce compliexity and, as you said, it would be benefitial even for a small number of categories.

[mimou78]

Hi @swnsma,
I noticed an inconsistency in the class: the getProductsCountQuery method accepts the $addVisibilityFilter parameter, which is supposed to determine whether we include only visible products. However, I don't see why this filter is needed here, especially since in the loadProductCount method we already pass the $websiteId, which seems to be the logical parameter to rely on.

From my understanding, this looks like a bug in the current implementation. If we decide to fix it in this issue, we would also need to remove the dependency on catalogProductVisibility, though I'm not entirely sure about the correct approach to remove that dependency.

I’ve addressed your last request, so feel free to review and give me your thoughts on how we should proceed regarding this visibility logic.
Thanks!