Issue with COMPLETE ORDER STATUS ID

Hi all,

I am trying to get all my orders to show on the dashboard sale graph.

I have set my complete order statuses on the settings>options page (complete and shipped).

However in the database oc_settings table there are two entires, one is the serialised entry for the option above;

config_complete_status = a:2:{i:0;s:1:"5";i:1;s:1:"3";} (5 for complete, 3 for shipped)

but also;

config_order_status_id = 5

When I look in the \admin\model\report\sale.php model file I can see it using this query to get the orders (this is for month as an example);
Two questions, for me the command;

1 - $this->config->get('config_complete_status_id')

always returns 0 no matter what the entry in the database is.

2 - How does that setting in the database get set or is it always 5...?

Because $this->config->get('config_complete_status_id') always returns zero no orders ever show up on the dashboard no matter what order status they are.

Any ideas..?

Thanks
Rolf

The setting in 2.x is config_complete_status and it's an array.

Thanks for the reply.

I've looked into this a little closer and the query is definitely looking for a setting called config_complete_status_id
This does not exist in the oc_settings table. If I manually add a row with the required group and name viola the get command now returns the value Ive put in the database.

I can see that there is a serialised entry called config_complete_status but it looks like either;

1 - the code has not been updated to reflect this (the query would not suit an returned array anyways as its a simple if order_status_id = get('config_complete_status_id')

2 - an update has failed to overwrite this sale.php file (I cant honestly remember if this installation has been updated as I was having serious issues with the ebaypro plugin and havent looked at it for a while)
NOTE - dont think its this as I have just taken a look at the files in the opencart zip and its the same there.

So if config_complete_status_id doesnt exist anymore I guess this query needs to be changed, hang on let me check the latest version...

=) Its been fixed in 2.0.1.0 and 2.0.1.1 and then the query uses an IN clause instead of where
Good to know that a - I wasnt going mad and b - that its been fixed =)

Thanks
Rolf

You should be using 2.0.1.1 since it has a security fix.