Since this endpoint isn't a publicly documented endpoint, we'll keep it
out of the wc/v3 namespace. Instead we're introducing a new wc-telemetry
namespace. The name of the endpoint then is updating to tracker.
The wc-telemetry endpoint is unversioned for consistency with
wc-analytics and because it's not publicly documented.
We're only writing data now, so it's more natural for this to be a POST
endpoint. We'll send the data in the request body instead of as query
parameters.
Instead of overloading the application startup endpoint with recording
telemetry data, we'll start with a dedicated telemetry endpoint. This
should be easier to reason about and the additional overhead of a
separate endpoint is minimal.
Adds an endpoint to consolidate the data that is needed every time the
app is opened instead of relying on multiple endpoints.
This is also a good place to include some basic mobile data usage in
WCTracker. We track each platform independently, so we can see which
versions of the apps are used on a given site.
Allows passing `null` for the billing email to clear it. This means the
email must either be a string that is a valid email address or a null
value.
Since it is possible to clear the email address for an order in a
similar way via the admin-ajax endpoints, this is meant to provide
consistency with the wp-admin experience.
Two new optional keys have been added to the tool definition array:
- 'disabled': when true the tool button will appear disabled.
- 'needs_refresh': when running a tool, by default the tool definitions
are retrieved first, then the selected tool is executed,
then the definitions previously retrieved are rendered.
When this key is true the tool definitions are retrieved again
after execution, useful for cases where the tool description
or button enable/disable state changes after the tool execution.
Also now if a tool execution throws an exception a notice will be
shown with the execption message, previously the exception
was unhandled.
- Check input (no 'id', has 'code') and throw an error if needed
before removing the existing coupons, so an invalid input
won't cause the loss of these existing coupons.
- Also, check that the coupon is actually valid as part of the
input check.
- Cache the coupon objects that are created during the input check,
and apply them directly.
- Don't check if 'coupon_lines' is an array and contains arrays,
that's already done by the REST API engine by looking at the schema.
- Adjust unit tests.
Josh Betz
Nestor Soriano
Claudio Sanches
Fitim Vata
Mike Jolley
Vedanshu Jain
Jonathan Sadowski
Néstor Soriano
Tim Howe
barryhughes
roykho
Mahmoud Saeed
Peter Fabian
Warren Wang