Reviewing files that changed from the base of the PR and between c2a89d1 and 4cc2b12.

• src/Sylius/Bundle/AdminBundle/Resources/views/Grid/deleteCatalogPromotion.html.twig (1 hunks)
• 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)
• src/Sylius/Bundle/UiBundle/Resources/views/Grid/Action/default.html.twig (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)

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

3-3: Clear fallback logic for the path variable.

By checking if options.link.url|default('') is not empty, you ensure that a non-empty options.link.url takes precedence and that the fallback route is used otherwise. This prevents empty strings from overriding the fallback path. Nicely done!

src/Sylius/Bundle/AdminBundle/Resources/views/Grid/deleteCatalogPromotion.html.twig (1)

1-1: Consistent path construction approach.

This approach correctly prioritizes options.link.url when it’s non-empty, falling back to a route-based path otherwise. It aligns well with similar logic in the other templates, keeping path resolution consistent.

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

18-21: Straightforward interface definition.
This interface neatly declares the expected contract for resetting cart changes. It is concise, properly typed, and follows Sylius coding standards.

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

22-24: Constructor with readonly property.
Using a constructor with a readonly property is a clear and succinct approach to ensure immutability of the EntityManagerInterface. This is good practice.

src/Sylius/Bundle/OrderBundle/spec/Resetter/CartChangesResetterSpec.php (1)

49-73: Good test coverage for new and managed item units.
These specifications thoroughly cover the key scenarios: unmanaged carts and carts containing both new and existing item units. Consider adding more cases (e.g., no items in the cart) if needed to strengthen completeness.

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

17-17: New import for CartChangesResetterInterface.
The imported interface ensures that the controller depends on the cart resetter abstraction rather than a concrete implementation. This is a solid design choice.

---

126-126: Cart reset after invalid submission.
Calling $this->getCartResetter()->resetChanges($resource); is correct to clear changes on an invalid cart. This helps maintain consistency when the form fails validation.

---

223-226: Getter method returning the resetter service.
This method is straightforward and aligns with the existing service-access pattern in this controller.

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

90-93: LGTM! Service configuration follows Symfony best practices.

The service definition and interface alias are properly configured. The service follows the bundle's naming conventions and dependency injection practices.

Let's verify the existence of the service class and interface:

✅ Verification successful

Service class and interface are properly implemented

The verification confirms that:

• The CartChangesResetter class exists at the correct location
• The CartChangesResetterInterface interface exists at the correct location
• The class properly implements the interface
• Both files are in the expected Resetter directory

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the existence of CartChangesResetter class and interface

# Check for the class file
fd --type f "CartChangesResetter.php" src/Sylius/Bundle/OrderBundle

# Check for the interface file
fd --type f "CartChangesResetterInterface.php" src/Sylius/Bundle/OrderBundle

# Verify class implements interface
rg "class CartChangesResetter implements CartChangesResetterInterface" src/Sylius/Bundle/OrderBundle

Length of output: 517

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

19-19: Verify data consistency across statistics endpoints

The change to newCustomersCount is consistent with other statistics files, but we should verify that this reflects the expected behavior in the corresponding test scenarios.

Run the following script to check for consistency in test scenarios:

✅ Verification successful

Change to newCustomersCount is consistent with test scenarios

Based on the test files analysis, the change from 1 to 0 in newCustomersCount is correct and consistent with the test scenarios. The StatisticsTest.php shows that the test data is set up using fixture files and fulfillOrder method calls, where orders are created with specific dates but no new customers are explicitly created during the test period, justifying the newCustomersCount: 0 in the response files.

Key evidence:

• The test it_gets_fulfilled_orders_in_specific_year_statistics in StatisticsTest.php focuses on order fulfillment and sales statistics
• The test uses fixtures and fulfillOrder method to set up test data, but doesn't create new customers
• All statistics response files (get_day_statistics_response.json, get_month_statistics_response.json, and get_year_statistics_response.json) consistently show newCustomersCount: 0

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for consistency in customer count assertions across test files
# Look for related test assertions that might need updating

# Search for test files asserting customer counts
rg -l "newCustomersCount" "tests/Api" --type php

# Search for customer creation in test setup
rg -l "createCustomer|addCustomer" "tests/Api" --type php

Length of output: 104

---

Script:

#!/bin/bash
# Let's try a broader search to understand the test structure and related files

# Find all JSON files in tests directory that might contain statistics
fd -e json -p "statistics.*response" tests/

# Check content of these files for newCustomersCount
for f in $(fd -e json -p "statistics.*response" tests/); do
  echo "=== $f ==="
  cat "$f" | grep -A 2 -B 2 "newCustomersCount"
done

# Look for test files that might be setting up this scenario
fd -e php tests/ --exec grep -l "statistics"

Length of output: 2988

---

Script:

#!/bin/bash
# Let's check the test files that might be setting up these scenarios

# Search for test files in the tests directory
fd -e php . tests/ --exec grep -l "statistics"

# Also check for any test setup related to these statistics
fd -e php . tests/ --exec grep -A 5 -B 5 "function.*test.*statistics"

Length of output: 187

---

Script:

#!/bin/bash
# Let's examine the test files we found

# Check the content of StatisticsTest.php
echo "=== StatisticsTest.php ==="
cat tests/Api/Admin/StatisticsTest.php

# Check the content of CustomersTest.php
echo "=== CustomersTest.php ==="
cat tests/Api/Admin/CustomersTest.php

Length of output: 26532

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

151-151: Consistent change with other statistics endpoints

The update to newCustomersCount aligns with the changes in other statistics responses while preserving the existing sales patterns.

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

4391-4391: Verify impact on statistics calculation

The consistent update of newCustomersCount across all statistics endpoints suggests a change in how new customers are counted or tested. This might be related to changes in the underlying statistics calculation logic.

Run the following script to investigate related changes:

✅ Verification successful

Let me gather more specific information about the customer counting logic.

---

Let me check one more aspect to understand how the new customers count is calculated.

---

Let me check one final aspect to see the actual implementation of new customers counting.

---

Let me try one more search with a simpler pattern.

---

Test data update reflects actual customer counting logic

The change in newCustomersCount from 1 to 0 in the test response file is consistent with the actual implementation. The BusinessActivitySummaryProvider calculates new customers using customerRepository->countCustomersInPeriod() for the given date range, and this test data represents a scenario where no new customers were registered during that period.

Key findings:

• The value is determined by actual customer repository counting, not hardcoded
• The test data aligns with a valid business scenario where no new customers were added
• The implementation is consistent across the statistics system

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Look for changes in statistics calculation logic

# Search for statistics-related classes and services
rg -l "Statistics|CustomerStatistics" "src/"

# Search for customer counting logic
ast-grep --pattern 'class $_ {
  $$$
  count($$$) {
    $$$
  }
  $$$
}'

Length of output: 5893

---

Script:

#!/bin/bash
# Search for new customer counting logic in statistics providers
rg -A 10 "newCustomers" src/

# Look for test files related to customer statistics
fd -e php -e feature "customer.*stat" tests/

Length of output: 4603

---

Script:

#!/bin/bash
# Look for the business activity summary provider implementation
rg -A 15 "class BusinessActivitySummaryProvider" src/

Length of output: 3962

---

Script:

#!/bin/bash
# Get the full implementation of BusinessActivitySummaryProvider
rg -A 30 "provide\(\\\DatePeriod \$datePeriod" src/

Length of output: 51

---

Script:

#!/bin/bash
# Get the implementation details of BusinessActivitySummaryProvider
rg -A 30 "public function provide" "src/Sylius/Component/Core/Statistics/Provider/BusinessActivitySummaryProvider.php"

Length of output: 783

Reviewing files that changed from the base of the PR and between c2a89d1 and 4cc2b12.

• src/Sylius/Bundle/AdminBundle/Resources/views/Grid/deleteCatalogPromotion.html.twig (1 hunks)
• 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)
• src/Sylius/Bundle/UiBundle/Resources/views/Grid/Action/default.html.twig (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)

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

3-3: Fallback Logic for Path Looks Good

The new ternary condition ensures that options.link.url is used when provided and falls back gracefully to path(options.link.route, options.link.parameters|default({})) otherwise. This enhanced logic is clear and improves template flexibility for link generation.

src/Sylius/Bundle/AdminBundle/Resources/views/Grid/deleteCatalogPromotion.html.twig (1)

1-1: Similar Fallback Implementation

Just like in the other template, the ternary check for options.link.url promotes consistency and clarity. By ensuring that a non-empty options.link.url takes precedence, the template remains more adaptable to different link generation strategies.

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

19-19: Verify the intentional change in customer count

The newCustomersCount has been changed from 1 to 0. This change appears in all statistics response files, suggesting a deliberate modification. Please confirm if this is an intentional change as part of the upmerge from v1.14 to v2.0.

Run the following script to check for related changes in the test implementation:

✅ Verification successful

Let me gather more information about the changes in these files.

---

Let me check the content of other statistics response files to see if this is a consistent pattern.

---

Let me try a different approach to check the other statistics files and related test files.

---

Let me check the test implementation to understand if this is a deliberate change.

---

Let me check the feature files and context files to understand the expected behavior.

---

Based on the analysis of the feature files and test implementations, I can now provide a final response.

The change in customer count is consistent with test expectations

The change from 1 to 0 in newCustomersCount in the statistics response fixtures is correct and matches the test scenarios. The feature files show that customer counts are explicitly verified in scenarios and the statistics are calculated based on fulfilled orders, not just placed orders. The test fixtures serve as expected responses for API tests, and the zero count appears to be the default state for new statistics responses.

Key observations:

• The feature files contain explicit scenarios verifying customer counts
• The DashboardContext implements verification of newCustomersCount through the API
• The statistics response files are used as fixtures for API testing
• The zero count represents the initial/default state for test cases

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for related changes in test implementations that might explain the customer count change

# Search for test files that might set up this fixture data
rg -l "newCustomersCount" --type php

# Search for any changes in how customer count is calculated
ast-grep --pattern 'function $_(CustomerCount|getNewCustomers)'

Length of output: 425

---

Script:

#!/bin/bash
# Check the content of the files that reference newCustomersCount
cat src/Sylius/Bundle/ApiBundle/OpenApi/Documentation/StatisticsDocumentationModifier.php
cat src/Sylius/Behat/Context/Api/Admin/DashboardContext.php
cat src/Sylius/Component/Core/Statistics/ValueObject/BusinessActivitySummary.php

# Check for other test fixtures with similar statistics
fd -e json statistics_response

Length of output: 12058

---

Script:

#!/bin/bash
# Check the content of all statistics response files
cat tests/Api/Responses/admin/statistics/get_day_statistics_response.json
cat tests/Api/Responses/admin/statistics/get_month_statistics_response.json
cat tests/Api/Responses/admin/statistics/get_year_statistics_response.json

# Check git history for these files to see when and why the change was made
git log -p tests/Api/Responses/admin/statistics/get_year_statistics_response.json

Length of output: 65826

---

Script:

#!/bin/bash
# Check the content of the business activity summary in all statistics response files
rg -l "businessActivitySummary" tests/Api/Responses/admin/statistics/
cat tests/Api/Responses/admin/statistics/get_month_statistics_response.json
cat tests/Api/Responses/admin/statistics/get_year_statistics_response.json

# Check for any test files that might be setting up this data
rg -l "newCustomersCount.*[01]" tests/

Length of output: 4090

---

Script:

#!/bin/bash
# Check for test files that set up or verify the statistics data
rg -A 5 "newCustomersCount" tests/Behat/Context/Api/Admin/DashboardContext.php

# Check for any feature files that might describe the expected behavior
fd -e feature . tests/ | xargs rg -l "new customers"

Length of output: 463

---

Script:

#!/bin/bash
# Check the feature files for expected behavior
cat features/admin/statistics.feature
cat features/admin/statistics_per_channel.feature

# Check the context files for implementation
cat src/Sylius/Behat/Context/Api/Admin/DashboardContext.php
cat src/Sylius/Behat/Context/Setup/OrderContext.php

Length of output: 55825

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

151-151: Consistent change in customer count

The change from 1 to 0 in newCustomersCount is consistent with the modification in get_year_statistics_response.json.

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

1-21: Interface looks good

No issues found. The interface definition is concise and follows standard practices for extending functionality without introducing implementation details.

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

28-30: Consider handling unmanaged carts more explicitly

Currently, the method returns immediately if $cart is not contained in the EntityManager. You might want to confirm that ignoring carts outside persistence context is the intended behavior (e.g., by logging a debug message or throwing an exception). Otherwise, debugging issues with untracked carts might be harder.

---

34-39: Good approach to remove new units

Removing units in the STATE_NEW state is a straightforward solution to revert cart changes. This implementation is clear and explicit.

src/Sylius/Bundle/OrderBundle/spec/Resetter/CartChangesResetterSpec.php (1)

1-74: Spec tests are comprehensive

Your spec covers both scenarios—when the cart is not managed and when it has new item units. This thorough test coverage is excellent, ensuring stable behavior of the resetter logic.

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

17-17: Interface dependency properly introduced

Importing CartChangesResetterInterface provides a clear contract for cart reset logic. No issues here.

---

126-126: Verify the cart object type before resetting

When $form is invalid, calling $this->getCartResetter()->resetChanges($resource); might fail if $resource is not an expected OrderInterface. Ensure $resource is indeed a cart to avoid unexpected type issues.

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

90-93: Verify integration with OrderController.

The service looks properly configured. Let's verify its integration with the OrderController mentioned in the summary.

✅ Verification successful

Integration with OrderController is properly implemented

The verification confirms that the CartChangesResetter service is correctly integrated with the OrderController:

1. The controller properly retrieves the service through getCartResetter() method which returns CartChangesResetterInterface
2. The service is used in the saveAction() method to reset cart changes when form validation fails:

if ($form->isSubmitted() && !$form->isValid()) {
    $this->getCartResetter()->resetChanges($resource);
    $this->addFlash('error', 'sylius.cart.not_recalculated');
}

3. The service is correctly retrieved using the service ID sylius.resetter.cart_changes that matches the configuration in services.xml

The integration is complete and working as expected.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the integration of CartChangesResetter with OrderController

# Check if OrderController uses the new service
ast-grep --pattern 'class OrderController {
  $$$
  private function getCartResetter(): CartChangesResetterInterface {
    $$$
  }
  $$$
}'

# Verify service usage in saveAction
ast-grep --pattern 'public function saveAction(Request $request, $resource) {
  $$$
  getCartResetter()->resetChanges($resource)
  $$$
}'

Length of output: 489

---

Script:

#!/bin/bash
# Let's try a different approach using ripgrep to find the OrderController and its usage of CartChangesResetter

# Find OrderController files
echo "=== Finding OrderController files ==="
rg -l "class OrderController"

# Search for CartChangesResetter usage
echo -e "\n=== Searching for CartChangesResetter usage ==="
rg -l "CartChangesResetter"

# Search for getCartResetter method
echo -e "\n=== Searching for getCartResetter method ==="
rg "getCartResetter"

# Search for resetChanges method calls
echo -e "\n=== Searching for resetChanges method calls ==="
rg "resetChanges\("

Length of output: 1817

---

Script:

#!/bin/bash
# Let's check the implementation details of OrderController to understand the integration better

echo "=== OrderController Implementation ==="
cat src/Sylius/Bundle/OrderBundle/Controller/OrderController.php

Length of output: 9490

Reviewing files that changed from the base of the PR and between 4cc2b12 and 22e39f7.

• UPGRADE-1.14.md (1 hunks)
• src/Sylius/Bundle/CoreBundle/Resources/config/services/order_processing.xml (1 hunks)

UPGRADE-1.14.md (1)

1-5: LGTM! Clear documentation of the parameter extraction.

The change improves configurability by extracting hardcoded adjustment types into a configurable parameter. This is a good practice for maintainability and flexibility.

src/Sylius/Bundle/CoreBundle/Resources/config/services/order_processing.xml (3)

28-35: Well-structured parameter definition!

The new parameter definition follows best practices by:

• Using constants instead of string literals
• Centralizing adjustment types in a single, reusable collection
• Including all necessary adjustment types (promotions, shipping, tax)

---

41-41: Clean service argument refactoring!

The modification properly references the new parameter collection, improving maintainability by removing hardcoded values while preserving the service's functionality.

---

28-35: Verify completeness of adjustment types.

Let's ensure no adjustment types are missing from the collection.

✅ Verification successful

Collection includes all adjustment types defined in the interface.

The adjustment clearing types collection in order_processing.xml perfectly matches all the constants defined in Sylius\Component\Core\Model\AdjustmentInterface. No adjustment types are missing.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any other adjustment type constants in AdjustmentInterface
# that might have been missed in the collection

ast-grep --pattern 'interface AdjustmentInterface {
  $$$
  const $ADJUSTMENT_TYPE = $_;
  $$$
}'

# Also search for any direct string usage of adjustment types
rg -i "adjustment.*type.*=.*['\"]" --type php

Length of output: 1664

---

Script:

#!/bin/bash
# Find the AdjustmentInterface file
fd -e php AdjustmentInterface

# Once found, let's look at its contents
fd -e php AdjustmentInterface -x cat {}

Length of output: 2917