Re-think Sales Log UI

[JustinSainton]

I'd like to slate a re-thinking of the Sales Log UI for 4.2.

Some initial thoughts:

• [ ] Update single sales log page to utilize new WPSC_Purchase_Log API.
• [ ] Ensure the $purchlogitem globals are maintained for back-compat
• [x] Allow for editable fields (all billing, shipping, custom fields). Get asked about updating emails all the time :)
• [x] Add order notes capabilities
• [x] Add ability to add (or remove) items from orders
  • [x] with proper refunding capabilities.
• [ ] Should be integrated/aware of the forthcoming recurring billing API. Ability to cancel/renew subscriptions, change subscription duration, add items to/remove items from a subscription.
• [ ] Actually decent integration with Shipment Tracking APIs.

Much of the thoughts above may end up as the responsibility of separate APIs, or even other plugins, but I think, one way or another, all of that should be possible in WPeC.

Not feeling particularly dogmatic one way or the other - but this may be a really great opportunity to leverage a REST API for orders, which would necessitate the REST API going in for 4.1.

[JustinSainton]

Need to consider the relationship between an order and the customer who made it. So much inspiration here to take from https://github.com/easydigitaldownloads/Easy-Digital-Downloads/issues/2548

[jtsternberg]

Order notes already exists, right?

[JustinSainton]

yeah, but they're turrible.

[jtsternberg]

Discussed this internally. Idea is to:

• [ ] Array of notes
• [ ] in wp_wpsc_purchase_logs notes column
• [ ] Convert notes to LONGTEXT with a DB update
• [ ] Flag in readme/plugin updates/etc that DB change is a back-compatibility break.
• [ ] Modify WPSC_Purchase_Log getter to check for notes - anytime someone does something like $log->get( 'notes' ) - they'll be expecting a blob of text (so give them all the notes' text except private ones, and throw a _wpsc_doing_it_wrong).

Array of notes will be something like:

$notes = array(
    array(
        'type' => 'default',
        'status' => 'private',
        'time' => '<timestamp>',
        'content' => '<note content>',
    ),
    array(
        'type' => 'error',
        'status' => 'public',
        'time' => '<timestamp>',
        'content' => '<error content>',
    ),
);

[JeffPyeBrook]

the note column would certainly work... did you think about storing the notes as purchase meta? I am using the meta in my forks/plugins and it is working really well and doesn't require any extra work to get caching, and can store things other than text.

The only concern I would have is that any query that does a select * against the purchase log table would generate a lot of data if there are a lot of long text entries.

I am using the meta to store some images generated by a site customization process, and also historical shipping quotes for some shipper accountability.

[jtsternberg]

Thanks @JeffPyeBrook, we agree, and have switched to using purchase meta for notes storage, with a back-compatibility shim. The notes bit of this issue (as well as some of the other bits) are addressed with #2165.

[JustinSainton]

Part of this should include iterating on the order notes work done in https://github.com/wp-e-commerce/WP-e-Commerce/pull/2165

The low-level API includes the ability to have "types" and "statuses" like error/warning, or public/private. These could generate dynamic hooks that could be utilized dynamically for pretty powerful integrations. Email notices, in-account notices, push notifications, etc. The API exists - we just need the higher-level helper functions and UI in place for them.