Magento 2.4.7-p10 Braintree Bug: Unlocking the Sales Order Grid Date Filter

Magento 2.4.7-p10 Braintree Bug: Unlocking the Sales Order Grid Date Filter

The intricate world of e-commerce platforms like Magento often presents unique challenges, especially when integrating third-party payment gateways. A recent GitHub issue (Issue #40841) highlights a persistent problem affecting Magento Open Source and Adobe Commerce installations running version 2.4.7-p10 with Braintree modules enabled. This bug prevents merchants and administrators from filtering orders by purchase date in the Sales Order Grid, leading to a critical SQL error that can severely impact daily operations and reporting.

The Core Problem: Ambiguous 'created_at' Column

The issue manifests as a SQLSTATE[23000]: Integrity constraint violation: 1052 Column 'created_at' in WHERE is ambiguous error. This occurs specifically when a user attempts to apply a date filter (e.g., purchase date or order creation date) within the Magento Admin Sales > Orders grid. The root cause lies within the PayPal\Braintree\Plugin\SalesOrderGridPlugin.php class, a crucial component of the Braintree integration.

This Braintree plugin is designed to enrich the Sales Order Grid collection by joining additional tables, specifically braintree_transaction_details and, crucially, sales_order. Both the main grid table (sales_order_grid, aliased as main_table) and the joined sales_order table contain a created_at column. When the date filter is applied, the generated SQL query's WHERE clause references created_at without specifying which table it belongs to, causing ambiguity for the database (MariaDB in this case).

Impact on Merchants and Administrators

For any e-commerce business, efficient order management is paramount. The inability to filter orders by purchase date directly within the Magento Admin panel can lead to significant operational bottlenecks:

• Delayed Reporting: Merchants cannot quickly pull up orders from specific date ranges for sales analysis, reconciliation, or customer service inquiries.
• Inefficient Order Management: Locating specific orders or batches of orders becomes a manual, time-consuming process, increasing the risk of errors.
• Frustration and Downtime: Administrators are forced to find workarounds, potentially involving direct database queries or exporting entire datasets, which is inefficient and prone to errors for non-technical staff.

This bug, while seemingly technical, has direct business implications, hindering productivity and potentially impacting customer satisfaction due to slower response times.

Environment and Reproducibility

The bug has been confirmed on Magento 2.4.7-p10, running PHP 8.3, MariaDB 10.11, OpenSearch 2.19, Valkey 8.1, and Varnish 8. The steps to reproduce are straightforward:

1. Install Magento 2.4.7-p10.
2. Enable the Braintree modules (e.g., PayPal_Braintree).
3. Log in to Magento Admin.
4. Go to Sales > Orders.
5. Apply a filter using the purchase date / order creation date.
6. The grid request fails, and a SQL exception is logged.

The expected behavior is for the grid to load correctly, with the created_at filter qualified as main_table.created_at. However, the actual result is the SQL error, with a generated query similar to this:

SELECT `main_table`.*,
       `braintree_transaction_details`.`transaction_source`,
       `sales_order`.`dispute_status`
FROM `sales_order_grid` AS `main_table`
LEFT JOIN `braintree_transaction_details`
    ON braintree_transaction_details.order_id = main_table.entity_id
LEFT JOIN `sales_order`
    ON sales_order.entity_id = main_table.entity_id
WHERE (((`created_at` >= '2026-05-28 07:00:00')))
  AND (((`created_at` <= '2026-05-29 06:59:59')))
ORDER BY main_table.created_at DESC
LIMIT 20

Notice the unqualified created_at in the WHERE clause, which is the culprit.

A Recurring Challenge: Historical Context

What makes this issue particularly noteworthy is its recurrence. The GitHub issue itself references several related, previously closed issues (#38818, #39144, #40351). This indicates that the problem of ambiguous column names in the Sales Order Grid, especially when third-party modules introduce new joins, is a persistent challenge within the Magento ecosystem. It underscores the complexity of maintaining backward compatibility and ensuring robust integration across a vast codebase.

Potential Solutions and Best Practices

While an official patch from Adobe Commerce is the most stable and recommended long-term solution, developers and merchants facing this issue immediately might consider temporary workarounds:

• Custom Module Override: A developer can create a custom module to override or extend the problematic PayPal\Braintree\Plugin\SalesOrderGridPlugin. The goal would be to ensure that any `created_at` references in the collection's WHERE clause are explicitly qualified with main_table.created_at. This requires careful implementation and thorough testing to avoid introducing new issues.
• Database Reporting Tools: For urgent reporting needs, using direct database queries or external reporting tools might be a temporary measure, though this bypasses the Magento Admin interface and should only be done by experienced personnel.

From a preventative standpoint, this bug highlights several best practices for Magento development and integration:

• Always Qualify Column Names: When performing SQL joins, especially in Magento's collection factories or UI components, explicitly qualify column names (e.g., main_table.column_name) to prevent ambiguity, even if it seems unnecessary at first.
• Thorough Testing: Implement comprehensive testing protocols, including integration tests, after any Magento update, patch, or third-party module installation. Pay special attention to critical admin functionalities like order grids.
• Stay Updated: Keep your Magento installation and all modules updated to the latest stable versions. Monitor official Magento GitHub repositories and release notes for bug fixes.

Navigating Magento's Complexities with Shopping Mover

Issues like the Braintree Sales Order Grid bug underscore the inherent complexities of managing and maintaining a high-performance Magento store. At Shopping Mover, we specialize in navigating these challenges, offering expert Magento migration services, development, and troubleshooting for both Magento Open Source and Adobe Commerce. Whether you're upgrading to the latest version, integrating new payment gateways, or facing critical operational bugs, our team of Magento experts can provide the authoritative guidance and technical solutions you need to keep your e-commerce platform running smoothly.

Don't let technical glitches hinder your business growth. Understanding and addressing these issues promptly is key to maintaining a robust and efficient online store. Stay informed, test diligently, and when in doubt, consult with Magento experts.