New order status setting for Zero Subtotal Checkout in back-end orders is not working

[leoquijano]

This might be related to #5860, but in a different area.

Preconditions

Using a brand new Magento 2.2.2 setup in PHP v7.1, MySQL 5.7.21 and Apache 2.24, I set up the following:

• 2 websites (Main and US).
• 2 stores, one for each website (Main and US).
• 2 store views, one for each store (Main and US).
• 1 product with $0 price and infinite stock (i.e., not managed by Magento).
• 1 customer with default billing and shipping address.
• Enabled free shipping

Steps to reproduce

After setting that configuration up, I configure the Zero Subtotal Checkout payment method (Stores -> Configuration -> Sales -> Payment Methods), to set the order status to "Processing" instead of "Pending" . I do this under the "Default Config" configuration.

Expected result

When I create a new order in the back-end for a customer in the US Store View (i.e., not the default view), the order should be set to "Processing" status.

Even though I didn't set a website specific configuration for that option, the fallback mechanism should guarantee that my default order status is the one used.

Actual result

The order stays in "Pending" status.

Comments

I tried the workaround mentioned in #5860. It works on the front-end, but it doesn't work when placing orders from the admin area. For some reason, in vendor/magento/module-payment/Model/Method/AbstractMethod.php, method getConfigData, the retrieval for the configuration of payment/free/order_status doesn't fallback properly.

This method returns NULL for the US Store View, which in turn means that the following code sets the wrong status:

In vendor/magento/module-sales/Model/Order/Payment.php:

public function place()
{
     $this->_eventManager->dispatch('sales_order_payment_place_start', ['payment' => $this]);
     $order = $this->getOrder();
     ...
    $orderState = Order::STATE_NEW;
    $orderStatus = $methodInstance->getConfigData('order_status');
    // ...
    if ($action) {
       // ...
    } else {
        $order->setState($orderState)
            ->setStatus($orderStatus);
    }
    ...
}

(Note that $action is empty in the admin area, which is also strange, but then again, I'm using the zero subtotal checkout payment method)

[leoquijano]

Here is some additional info.

The fallback behavior is now working properly in my test site. But I tracked the issue down to the following.

In vendor/magento/module-sales/Model/Order/Payment.php, method place:

$action = $methodInstance->getConfigPaymentAction();

if ($action) {
    if ($methodInstance->isInitializeNeeded()) {
        $stateObject = new \Magento\Framework\DataObject();
        // For method initialization we have to use original config value for payment action
        $methodInstance->initialize($methodInstance->getConfigData('payment_action'), $stateObject);
        $orderState = $stateObject->getData('state') ?: $orderState;
        $orderStatus = $stateObject->getData('status') ?: $orderStatus;
        $isCustomerNotified = $stateObject->hasData('is_notified')
            ? $stateObject->getData('is_notified')
            : $isCustomerNotified;
    } else {
        $orderState = Order::STATE_PROCESSING;
        $this->processAction($action, $order);
        $orderState = $order->getState() ? $order->getState() : $orderState;
        $orderStatus = $order->getStatus() ? $order->getStatus() : $orderStatus;
    }
} else {
    $order->setState($orderState)
        ->setStatus($orderStatus);
}

For the front-end, the "Zero Subtotal Checkout" payment method will still run a payment action (authorize/capture). In particular, the following code is run (first part of the outer IF, second part of the inner IF):

$orderState = Order::STATE_PROCESSING;
$this->processAction($action, $order);
$orderState = $order->getState() ? $order->getState() : $orderState;
$orderStatus = $order->getStatus() ? $order->getStatus() : $orderStatus;

So basically, the order state will be set to processing before running the processAction method. A default status of processing will then be assigned by the workaround mentioned in #5860, so for front-end orders, the change will work.

However, in back-end orders for a store view, the $action variable is empty (the getConfigPaymentAction returns null). This means that the following is run instead (the second part of the outer IF):

$order->setState($orderState)
    ->setStatus($orderStatus);

Since $orderState is Order::STATE_NEW, this will set the order in an invalid state=new, status=processing status. The following code will set the order back to pending:

if (!array_key_exists($orderStatus, $order->getConfig()->getStateStatuses($orderState))) {
  $orderStatus = $order->getConfig()->getStateDefaultStatus($orderState);
}

And that causes the problem for us. Now, as for solving the issue, our use case actually requires us to move the state and the status both to processing, so I'll probably have to override the place method.

However, the following questions remain:

1. Shouldn't the behavior be consistent between front-end and back-end orders? If a payment action (authorize/capture) is run for the Zero Subtotal Checkout in the front-end, shouldn't it run also for the back-end?
2. Irrespective of that, if the order state is set to processing for the first use case (when a payment action is present), shouldn't it be set to processing too for the second use case as well?
3. What happens when the admin selects a payment order_status setting that is not compatible with the NEW or the PROCESSING state?

[magento-engcom-team]

@leoquijano, thank you for your report.
We've acknowledged the issue and added to our backlog.

[GovindaSharma]

#MM19IN

[magento-engcom-team]

Hi @brideo. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• 2. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

• 3. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• 4. If the issue is not relevant or is not reproducible any more, feel free to close it.

[brideo]

Cool, I will start today.

[m2-assistant]

Hi @engcom-Charlie. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• 2. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

• 3. If the issue is not relevant or is not reproducible any more, feel free to close it.

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[engcom-Charlie]

Hello @leoquijano

Thank you for contribution and collaboration!

We are not able to reproduce this issue on the lates 2.3-develop branch by provided steps.

We are closing this issue due to branch 2.2-develop was closed and Magento no longer accepts pull requests and issues to the v2.2 release lines to focus all development efforts on v2.3.
See Accepted pull requests and ported code for more details

If you still faced this issue on 2.3 please create a new Issue with all required details according to Issue reporting guidelines

[amenk]

I am still able to reproduce this with "automatically invoice all items" turned off ...