add ability to get order checkout date

About the date filter, it seems to work fine for me, see there https://skitch.com/haza/fbegy/filter-date.png (I'm overriding the default orders view.)

And about the SKU filter, you need to add a new relationship in views : Order: Line Items
This relationship then let you add an other relationship : Lien item: Product

And then, you can add the SKU filter to the views.

https://skitch.com/haza/fbe8m/orders-commerce-order-commerce-kickstart

just a note to add, if you have Date module enabled, choose the Date: Date (commerce_order) field to take advantage of Date module's power and not the Commerce module's filter.

The way to do this would be to either:

a. add a dedicated column for the checkout time
b. add a Views relationship to the order revision table, joining on 'status' = 'checkout_complete' and get the timestamp from that.

Regarding http://www.bywombats.com/blog/01-24-2012/updating-completed-order-timest..., I don't think that rewriting the order timestamp with a Rule is really a solid enough solution.

Meant to reopen.

everything we need is in the order revision table so setting as dup of #804850: Integrate Order Revisions with Views.

That doesn't actually give us everything we need. Once that's patch is in we'll have to add more here: we need to be able to hop from the order to a single revision *based on that revision's status*.

In other words, a custom relationship handler that implements a custom join like:

JOIN order_revision ON (id = id) AND order_revision.status = 'checkout_complete'.

Yes, I confirm that we need additional views handlers! But now #804850: Integrate Order Revisions with Views is a blocker for this issue!
Just wait for closing revisions issue! After this we can start working on this issue!

I'm looking for solution for this issue and no good result I found...

As in #7 ("b" solution) and #10 I tried to get checkout date via mysql joins.
In my situation i have order with few revisions with status = 'checkout_complete'.
That is problem for me because join gives me multiple rows for each order. And there is no transparent way to limit joined rows without GROUP BY operator.
Another question is: which of of revisions use to get checkout date? first? last? Which?

Simplified mysql query from views with additional join:

SELECT commerce_order_revision_checkout.revision_id AS checkout_rid, commerce_order.order_number AS commerce_order_order_number, commerce_order.order_id AS order_id, commerce_order.status AS commerce_order_status, commerce_order_revision_current.revision_id AS commerce_order_revision_revision_id
FROM commerce_order commerce_order
LEFT JOIN users users_commerce_order ON commerce_order.uid = users_commerce_order.uid
LEFT JOIN commerce_order_revision commerce_order_revision_current ON commerce_order.revision_id = commerce_order_revision_current.revision_id
LEFT JOIN commerce_order_revision commerce_order_revision_checkout ON ( commerce_order.order_id = commerce_order_revision_checkout.order_id )
AND (
commerce_order_revision_checkout.status = 'checkout_complete'
)
LIMIT 50
OFFSET 0

As for me better way is set creation date (or dedicated field) via rules when completing checkout.
rules actions can be replaced with hook implementations in commerce or custom module.

Hi,

Thanks for your assistance. Just followed your steps. Solved most of my problems in creating a filter based on the product attributes.

However, I have a problem with my orders being duplicated. I checked, and found out that the duplication came from the Order: Line Items. Think you could help me out with that? Your assistance is most appreciated.

Thank you sir.

-John Yeong-

some might find this useful: #2044231: Add "paid in full" datestamp to order along with "created" and "updated" -- not sure if my post is totally relevant to this one... but its definitely similar

Closing this back out and linking to #2044231: Add "paid in full" datestamp to order along with "created" and "updated" where I've committed the rule to core that I used in my blog post. Joachim linked to this above, and I gave my two reasons for opting for this solution instead of something more robust in my linked issue there. Feel free to comment on it; the gist is the new rule is unobtrusive and a more comprehensive fix should be devised for Commerce 2.x.