Help needed fixing DirectOne module - writing to database.

[shaztesting]

Hi guys,

I have been fixing the Directone payment module found here: link

My previous fix for return errors is here: link

And now I now need some help regarding populating a field with the correct orders_id of the transaction.

The Problem

Right now the module writes all transactions to a table and uses 'order_id' as opposed to 'orders_id'.

1. The value written into the 'order_id' field is incorrect for that order. It ranges from 1 integer off to many off (eg. order_id has 37 but the actual orders_id from the orders table has it at 54).

After much testing I figured out what it is doing.

If only 1 customer is placing repeat orders then the module is off by 1
(eg. order_id has 6 but the actual orders_id from the orders table has it at 7).

I believe the reason for this is because of an incorrect query of the Orders table:

$orders_query = "select orders_id from " . TABLE_ORDERS . "
                     where customers_id = '" . (int)$_SESSION['customer_id'] 

. "'
                     order by date_purchased desc limit 1";

Linkpoint on the other hand calculates the correct order_id by adding + 1 to the last order of the orders_id field

// Calculate the next expected order id
    $last_order_id = $db->Execute("select * from " . TABLE_ORDERS . " order 

by orders_id desc limit 1");
    $new_order_id = $last_order_id->fields['orders_id'];
    $new_order_id = ($new_order_id + 1);

Is this the cause of the error? If so how do I incorporate this into the DirectOne module?


If many customers are placing orders then the module is off by as much as the number of customers.
(eg. order_id has 37 but the actual orders_id from the orders table has it at 54).

For some reason the module reserves the proceeding order_id for each customer. For example

• If Customer 1 is given order_id of 6
• Then Customer 2 is given an order of 8.
• When customer 1 places a second order, the module gives him the reserved order_id of 7 (even if the orders_id's are up in the 30's).

Now this makes the field useless when you have 100's of customers.

I think it is being caused by the

 where customers_id = '" . (int)$_SESSION['customer_id']

since I don't think linkpoint looks at current sessions, rather the most recent orders_id and adds 1 to it. Do you think this is the problem or is it something deeper?


Why can't payment modules just have orders_id as the primary key like so many other tables in Zen cart? Why make a new field 'order_id' (seems like many other payment modules do it as well)?

Does the solution involve session variables or is there a simpler way of recording the right orders_id for each transaction?


Thanks in advance for any direction you may be able to offer,

Regards,
Shaztesting

[DrByte]

The infrastructure for handling orders and checkout and payment modules was inherited from osCommerce, and has many flaws in its design insomuch has it has many limitations, one of them being the fact that the order isn't actually created until *after* the payment module finishes handling it. That is on the roadmap for rewriting in a future version.

In the meantime, if you even need to store the order number at all, you'll need to change the query you're using and use the same logic as you found in the linkpoint module.