Reviewing files that changed from the base of the PR and between d3293b3 and 88dce18.

• src/Sylius/Bundle/AdminBundle/Resources/views/Grid/deleteCatalogPromotion.html.twig (1 hunks)
• src/Sylius/Bundle/UiBundle/Resources/views/Grid/Action/default.html.twig (1 hunks)

Reviewing files that changed from the base of the PR and between 88dce18 and a5fb686.

• src/Sylius/Bundle/OrderBundle/Controller/OrderController.php (3 hunks)
• src/Sylius/Bundle/OrderBundle/Resetter/CartChangesResetter.php (1 hunks)
• src/Sylius/Bundle/OrderBundle/Resetter/CartChangesResetterInterface.php (1 hunks)
• src/Sylius/Bundle/OrderBundle/Resources/config/services.xml (1 hunks)
• src/Sylius/Bundle/OrderBundle/spec/Resetter/CartChangesResetterSpec.php (1 hunks)
• tests/Api/Responses/admin/statistics/get_day_statistics_response.json (1 hunks)
• tests/Api/Responses/admin/statistics/get_month_statistics_response.json (1 hunks)
• tests/Api/Responses/admin/statistics/get_year_statistics_response.json (1 hunks)

tests/Api/Responses/admin/statistics/get_year_statistics_response.json (1)

19-19: LGTM! Verify related test cases.

The update to newCustomersCount is consistent with the changes in other statistics response fixtures. However, since this modifies test data, ensure that:

1. The related test cases have been updated to expect this new value
2. The change reflects the correct business logic in the main codebase

✅ Verification successful

Change is consistent across all statistics response fixtures

The verification shows that newCustomersCount is consistently set to 0 across all related statistics response fixtures:

• get_year_statistics_response.json
• get_month_statistics_response.json
• get_day_statistics_response.json

Since we found no test assertions expecting the old value of 1, and all related response fixtures are aligned with the new value of 0, this change appears to be correctly implemented across the test suite.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for any test cases that might still expect newCustomersCount to be 1

# Search for test assertions related to newCustomersCount
rg -A 5 "newCustomersCount.*1" "tests/"

Length of output: 39

---

Script:

#!/bin/bash
# Let's try a broader search for newCustomersCount in tests
rg "newCustomersCount" "tests/" -B 2 -A 2

# Also search for any test files that might be using this response fixture
fd ".*test.*\.(php|js|ts|py)$" | xargs rg "get_year_statistics_response"

Length of output: 1576

tests/Api/Responses/admin/statistics/get_month_statistics_response.json (1)

151-151: LGTM! Change is consistent with other fixtures.

The update to newCustomersCount maintains consistency with the changes in the yearly statistics response fixture.

tests/Api/Responses/admin/statistics/get_day_statistics_response.json (1)

4391-4391: LGTM! Verify the business logic change.

The update to newCustomersCount completes the consistent pattern of changes across all statistics response fixtures (yearly, monthly, and daily). Since this appears to be a deliberate change across all granularities, we should verify:

1. The business logic change in the main codebase that necessitated these test updates
2. The impact on any statistics-related features that might depend on this value

✅ Verification successful

Test fixtures updated to match actual business logic implementation

The test fixtures were correctly updated to reflect the actual implementation. The newCustomersCount value is derived from CustomerRepositoryInterface::countCustomersInPeriod() which counts customers within a specific time period. The test fixtures (yearly, monthly, and daily statistics responses) were updated for consistency with this implementation.

Looking at the implementation in BusinessActivitySummaryProvider.php, we can see that:

1. The value comes directly from the customer repository's count method
2. The test spec confirms this behavior, showing it's an expected part of the business logic
3. The change in test fixtures from 1 to 0 aligns with this implementation

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Look for the business logic change that modified how newCustomersCount is calculated

# Search for relevant business logic in statistics-related files
rg -l "newCustomersCount" "src/" | while read -r file; do
  echo "=== $file ==="
  git log -p "$file"
done

# Search for any remaining references to the old value
rg "newCustomersCount.*1" "src/"

Length of output: 636

---

Script:

#!/bin/bash
# Let's examine the content of the identified files to understand the business logic

# Check BusinessActivitySummary.php
echo "=== BusinessActivitySummary.php ==="
cat "src/Sylius/Component/Core/Statistics/ValueObject/BusinessActivitySummary.php"

# Check StatisticsDocumentationModifier.php
echo -e "\n=== StatisticsDocumentationModifier.php ==="
cat "src/Sylius/Bundle/ApiBundle/OpenApi/Documentation/StatisticsDocumentationModifier.php"

# Check DashboardContext.php
echo -e "\n=== DashboardContext.php ==="
cat "src/Sylius/Behat/Context/Api/Admin/DashboardContext.php"

# Let's also check for any test files that might provide context
echo -e "\n=== Test files containing newCustomersCount ==="
rg -l "newCustomersCount" "tests/"

Length of output: 12353

---

Script:

#!/bin/bash
# Let's check for any recent changes in the business logic implementation

# Look for the statistics provider/calculator implementation
echo "=== Looking for statistics provider implementation ==="
rg -l "BusinessActivitySummary" "src/"

# Check for any test implementations that might provide context
echo -e "\n=== Looking for related test implementations ==="
rg -l "newCustomersCount.*assert" "tests/"

# Check for any recent commits related to statistics
echo -e "\n=== Recent commits related to statistics ==="
git log --grep="statistic" --grep="customer" -n 5 --oneline

Length of output: 1037

---

Script:

#!/bin/bash
# Let's check the implementation of the business logic

# Check the statistics provider implementation
echo "=== BusinessActivitySummaryProvider.php ==="
cat "src/Sylius/Component/Core/Statistics/Provider/BusinessActivitySummaryProvider.php"

# Check the spec file for insights into the expected behavior
echo -e "\n=== BusinessActivitySummaryProviderSpec.php ==="
cat "src/Sylius/Component/Core/spec/Statistics/Provider/BusinessActivitySummaryProviderSpec.php"

# Check the statistics provider
echo -e "\n=== StatisticsProvider.php ==="
cat "src/Sylius/Component/Core/Statistics/Provider/StatisticsProvider.php"

Length of output: 5497

src/Sylius/Bundle/OrderBundle/Resetter/CartChangesResetter.php (1)

20-24: Good use of final and constructor injection.
This approach adheres to best practices in modern PHP, preventing class extension and ensuring dependencies are clearly declared.

src/Sylius/Bundle/OrderBundle/Controller/OrderController.php (2)

17-17: Importing the interface is appropriate.
Bringing in CartChangesResetterInterface aligns with the newly introduced service, ensuring the controller stays decoupled from implementation details.

---

126-126: Verify cart reset behavior upon invalid form submission.
Resetting carts after form validation fails may be correct, but carefully review whether this is expected from a user perspective, e.g., should unsaved new items always be discarded?

src/Sylius/Bundle/OrderBundle/Resources/config/services.xml (1)

90-93: Verify the integration of the new cart changes resetter service.

Let's ensure all the related changes are properly implemented:

✅ Verification successful

The cart changes resetter service is properly integrated and implemented

The verification shows that:

• Both the interface and implementation classes exist and are properly implemented
• The OrderController has been updated to use the new service through getCartResetter() method
• The old resetChangesOnCart method has been completely removed
• The implementation correctly handles cart changes using Doctrine's EntityManager

The service implementation looks solid with proper:

• Type declarations and null safety
• Error handling for non-managed entities
• Proper cleanup of new units and refresh of affected entities

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the complete implementation of the cart changes resetter

# Check if the new classes exist
echo "Checking for new class files..."
fd CartChangesResetter.php
fd CartChangesResetterInterface.php

# Check if OrderController has been updated to use the new service
echo -e "\nChecking OrderController updates..."
rg -A 5 "getCartResetter|resetChanges.*resource" --type php

# Check for any remaining usages of the old method
echo -e "\nChecking for any remaining usages of the old method..."
rg "resetChangesOnCart" --type php

Length of output: 1835

---

Script:

#!/bin/bash
# Let's verify the implementation details of the new classes

# Check the interface definition
echo "Checking CartChangesResetterInterface implementation..."
cat src/Sylius/Bundle/OrderBundle/Resetter/CartChangesResetterInterface.php

echo -e "\nChecking CartChangesResetter implementation..."
cat src/Sylius/Bundle/OrderBundle/Resetter/CartChangesResetter.php

# Check for any tests
echo -e "\nChecking for related tests..."
fd -e php -g "*CartChangesResetter*Test.php"

Length of output: 2072