Easy-digital-downloads: 3.0 - Orders - Add Order Validation Notice Stays Triggered on Submit

[spencerfinnell]

Bug Report

Expected behavior

When I see a notice that the order cannot be added because it is missing information I should be able to create the Order once the missing information is provided.

Actual behavior

The "Create Order" or "Save Order" button must be clicked twice. First to dismiss the notice, then again to submit.

Steps to reproduce the behavior

1) Attempt to create an order with no order items.
2) Add an order item.
3) Attempt to create the order.

Information (if a specific version is affected):

EDD Version (or branch): release/3.0

Any other relevant information:

Currently the checks are for order items and a customer. There are other ways to create "invalid" orders such as not entering "new customer" information, setting an invalid date, not setting a key, choosing the wrong gateway, etc.

At that point I'm wondering if there is a need for validating these items. If a record ends up being incorrect it can be deleted. cc @cklosowski

[cklosowski]

@spencerfinnell I’d say we should see if we can handle some of those validations pre-submission, instead of requiring the double submission after the error occurs.

Deleting the record should be fine, but some form of validation should be done, either pre-submit or post-submit.

[cklosowski]

@spencerfinnell I'm going to confirm if this is an existing issue from Manual Payments. if it is, we'll punt this to a minor bug fix release, in order to finalize the beta scope.

[spencerfinnell]

@cklosowski Manual Purchases goes to a wp_die() screen, something this new UI was trying to avoid I think. This is an easy fix, but just something I was waiting to do until after some of the open Order-related items are merged in.

The validation currently checks for an assigned Customer and added Order Items. Since you can switch the Customer once the Order is created, we really just want to prevent creating an Order with no Items.

[spencerfinnell]

PR #7781 keeps "Create Order" disabled if there are no Order Items.

[spencerfinnell]

From https://github.com/easydigitaldownloads/easy-digital-downloads/pull/7781#discussion_r414775310 via @robincornett

@cklosowski @LisaCee Do you have thoughts about requiring a Customer to create an Order? My reasoning for not requiring it for validation is because it can be changed once the Order has been created.

[cklosowski]

I would prefer we still require the customer be attached for a couple reasons:

1. Without a customer an order is missing key data points to contact the customer about their order.
2. It would require a store owner to go do a 2nd action that they may not realize they’ve missed

If we can find a way to make it a requirement, please, let’s do that.

[LisaCee]

I think I agree with @cklosowski here.

I understand that a customer can be changed after an order is created, but what sort of scenario would you envision the need to create an order without a customer?

[LisaCee]

I just hopped into release/3.0 to check something and I prefer that handling of not having a customer. Should the create order button be disabled without a customer? Maybe, but at least this catches it before it gets sent to the database.

[spencerfinnell]

@LisaCee The problem with disabling the Create Order button against multiple validations is that it is hard to know _why_ the button is still disabled -- this argument could really be made for the current PR as well.

If the customer is required then I think the Create Order button needs to always be active and we use notices (similar to what is in release/3.0 currently) to alert the user of the required validation fixes. To resolve the error originally reported in this issue the errors should be hidden immediately when an Order Item is added or a Customer is selected.

[spencerfinnell]

PR #7781 updated to keep the "Create" and "Save" buttons enabled always, but prevent the form submission if there are validation errors.

The validation errors are dismissed immediately when action is taken.