Convert log system to an add-on module for eCommerce

[GoogleCodeExporter]

For my particular site, an order gets 5 order update log entries.
The culprit is probably Order->onAfterWrite()

I think the log system needs some serious thought also.

Original issue reported on code.google.com by Jez...@gmail.com on 2 Dec 2010 at 4:16

[GoogleCodeExporter]

I've changed this ticket to be about converting the log system to a module. I 
don't think it needs to be part of core. This will also help keep the log code 
separate.

Original comment by Jez...@gmail.com on 7 Dec 2010 at 9:35

• Changed title: Convert log system to an add-on module for eCommerce
• Added labels: Type-Task
• Removed labels: Type-Defect

[GoogleCodeExporter]

we may combine this thinking with the ideas on having separate tables for 
sales, delivery, etc...

Original comment by nfranc...@gmail.com on 20 Dec 2010 at 8:31

[GoogleCodeExporter]

also see: http://code.google.com/p/silverstripe-ecommerce/issues/detail?id=65

Original comment by nfranc...@gmail.com on 20 Dec 2010 at 8:34

• Added labels: log, modules

[GoogleCodeExporter]

dont fix now, fix later when we have a proper plan

Original comment by nfranc...@gmail.com on 3 Jan 2011 at 7:26

[GoogleCodeExporter]

Original comment by nfranc...@gmail.com on 13 Jan 2011 at 9:11

• Added labels: Type-Enhancement
• Removed labels: Type-Task

[GoogleCodeExporter]

we should record for each order step, who did what, when, why, etc...

Original comment by nfranc...@gmail.com on 7 Mar 2011 at 5:07

[GoogleCodeExporter]

Original comment by nfranc...@gmail.com on 11 Apr 2011 at 7:41

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by nfranc...@gmail.com on 26 Apr 2011 at 3:31

• Added labels: Milestone-Release1.0
• Removed labels: Milestone-Release0.9

[GoogleCodeExporter]

the log system is now very much part of the core.

Original comment by nfranc...@gmail.com on 1 Nov 2011 at 9:49

• Changed state: Invalid

[GoogleCodeExporter]

Core of what?
Can you please reference some documentation / commits for this?

Original comment by jeremybu...@gmail.com on 1 Nov 2011 at 10:32

• Changed state: NeedsTesting

[GoogleCodeExporter]

the logs have been improved over many commits, but I will make some 
documentation + screenshots.

Original comment by nfranc...@gmail.com on 1 Nov 2011 at 10:45

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by jeremybu...@gmail.com on 2 Nov 2011 at 12:18

• Removed labels: Test

[GoogleCodeExporter]

committed better documentation here: 

Committed revision 1680.

---------------------
ORDER STATUS LOG:
---------------------

@description:
Data class that records events for an order like "Payment Checked", "Cheque 
Cleared", "Goods dispatched", etc...
Order Status Logs describe the history of each Order.
They are different from the OrderSteps which guide the Order through the 
ordering process.

Basically, an Order Status Log has a title and a piece of text.
In addition, we record if the customer was informed or that it is for internal 
use only.
We also record who made the log entry.

For your own e-commerce application you can add as many logs types as you need.
For this, you can extend the basic class: OrderStatusLog.

No logs are created "automatically", you will need to use the OrderSteps to 
create them.
In the code you can see a bunch of examples on how these Logs are written.

There is one special type of Order Status Log: OrderStatusLog_Submitted.
This one is basically hard-wired into the system.
That is, for every order and all e-commerce applications you need to have a 
moment where the customer commits / submits an order.
This order log basically stores the exact details of the order at the moment of 
submission.
This is really useful, because, based on the relational database aspect, it is 
very easy to loose parts of an exact order.
For example, you can change the title of a product, the amount of a tax, etc... 
and having a log of the exact details
at the moment the order was submitted can for that reason be very important.  
Over time the e-commerce system will become
more transactional so that submitted details can not be overriden, but the log 
of the submitted details will be a good backup
for the time being.

Other logs that you may include:
- OrderStatusLog_Cancel: record about cancellation
- OrderStatusLog_Dispatch: record about dispatch
- OrderStatusLog_PaymentCheck: payment was made (manual check)
- your own log thingy!

HACK NOTE: we have included OrderStatusLog_Archived here as well.
The reason we do this is that the Order CMS fields will try to look for the 
next Log Class in the
Complex Table Field. This might be different in 3.0 and can be removed then.

---------------------
ORDER STEP:
---------------------

/**
@description:
Defines the Order Status Options.   Basically OrderSteps guide the Order from 
inception to archiving.
Each project can have its own unique order steps - to match the requirements of 
the shop at hand.
The Order Step typically has (some) of the following functions:
a. a method move the order along
        - email the customer?
        - create a log entry?
b. describe what can be done to the order (edit, view, delete, etc...) and by 
whom
c. describe the status of the order
d. describe what needs to happen for the order to move along (via CMS fields)
        e.g. for the Order to move to the next step it needs to be paid in full

To make your own order steps, take an OrderStep from the classes listed below 
(one that is similar in purpose)
and customise it to your needs.

Next, to include the orderstep, you use one of the following methods:

OrderStep::set_order_steps_to_include (RESET ORDERSTEPS)
OR
OrderStep::add_order_steps_to_include (ADD ONE)

There are a lot of comments in the code below so there is no point in repeating 
that, but four KEY methods are:
- initStep: are we ready?
- doStep: do the step ...
- nextStep: what is next?
- addOrderStepFields: add CMS fields to the Order (e.g. a message stating what 
is next)

Original comment by nfranc...@gmail.com on 2 Nov 2011 at 3:06

[GoogleCodeExporter]

Can this documentation go in the ecommerce/docs folder?
The code could provide a reference to the right document, eg:

see: ecommerce/docs/OrderSteps.md

Original comment by jeremybu...@gmail.com on 2 Nov 2011 at 3:09

[GoogleCodeExporter]

I tend to think it is easier to keep it with the file, but I will follow your 
lead in this.  

Original comment by nfranc...@gmail.com on 2 Nov 2011 at 3:28

[GoogleCodeExporter]

Well, in this case it's not far from it. Maybe it goes in the code also.
I'm just thinking about the developers who may be trying out the software, and 
want to avoid reading through code.

The in-code documentation could also be extracted out with PHPDocumenter

Original comment by jeremybu...@gmail.com on 2 Nov 2011 at 3:39

[GoogleCodeExporter]

This can not be fixed, because the logs are a core part of e-commerce. 

Original comment by nfranc...@gmail.com on 3 Apr 2012 at 9:26

• Changed state: WontFix