REST API: Implement /reports/customers endpoint

[timmyc]

p2: p7bje6-16h-p2
swagger: https://app.swaggerhub.com/apis/peterfabian/wc-v3-api/1.0.0#/default/get_reports_customers

Currently the /reports/customers endpoint has yet to be fully implemented. It appears the new endpoint will require another reporting table to be built, so for this issue we will need the required table to be built, along with the endpoint logic.

[timmyc]

Noting that during our planning session today we discussed that support for customers registration filter does not exist in the swagger hub implementation.

[jeffstieler]

@timmyc - question regarding the initial lookup table backfill..

It seems obvious that we want to backfill the customer lookup table with existing (registered) customers.. but what about "existing" guest customers? Should we pull all the unique email addresses from guest orders and backfill them?

[timmyc]

Wonder if we can hook some logic into the existing back-fill operation of the orders lookup table to also preform the requisite tasks regarding customers. @peterfabian any thoughts on that approach?

[jeffstieler]

More questions:

• The API spec doesn't have parameters for "last order" (we agreed to add on p2) - any objections to adding that?
• The API spec uses "before" and "after" for customer registration date.. how about we rename to "registered_before" and "registered_after" ?
• How should the "name" parameter work? We currently have separate columns for first and last name.
• The API spec has a "username" parameter, but we don't have that in the lookup table. Should we remove the parameter, or add username to the lookup table?
• The item schema for /reports/customers should match the lookup table right? (It currently doesn't)

[timmyc]

The API spec doesn't have parameters for "last order" (we agreed to add on p2) - any objections to adding that?

Nope sounds reasonable to me.

The API spec uses "before" and "after" for customer registration date.. how about we rename to "registered_before" and "registered_after" ?

I believe we have standardized on before and after in the context of all other stat endpoints for date range queries - but given we have multiple timestamp attributes on the object, I think being explicit with the registered_ prefix makes sense.

How should the "name" parameter work? We currently have separate columns for first and last name.

I would imagine we would want to search against both fields when this argument is sent along

The API spec has a "username" parameter, but we don't have that in the lookup table. Should we remove the parameter, or add username to the lookup table?

I think adding username to the lookup table makes sense, or not supporting it since we have the name option.

The item schema for /reports/customers should match the lookup table right? (It currently doesn't)

The schema returned by the endpoint should describe the shape/attributes of the return values from the API - so likely won't fully match the lookup table.

[jeffstieler]

How should the "name" parameter work? We currently have separate columns for first and last name.

I would imagine we would want to search against both fields when this argument is sent along

Ok so are we matching on either the first or last name, or a concatenation of the two?

I think adding username to the lookup table makes sense, or not supporting it since we have the name option.

I'll add it.

The schema returned by the endpoint should describe the shape/attributes of the return values from the API - so likely won't fully match the lookup table.

It should at least contain the values displayed in the report table, right?

[timmyc]

Ok so are we matching on either the first or last name, or a concatenation of the two?

To me it seems like just basing this off the last name might simplify things, and be much more likely to happen then searching for first name. @LevinMedia ?

It should at least contain the values displayed in the report table, right?

It should really be a representation of the shape/types of values returned by the API. Here are some docs around what it should represent.

[LevinMedia]

A concatenation of the two seems like it would be ideal. @timmyc I could see most people starting to search by last name, but I think we want the first as well, as there will inevitably be folks with the same last name.