From cb9d7982c1ffb346fd83cbac9a1bf9c58942c2f5 Mon Sep 17 00:00:00 2001 From: Denis Ledoux Date: Tue, 15 Dec 2015 18:09:03 +0100 Subject: [PATCH] [FIX] payment, website_sale: condition to recreate a payment transaction Before this revision, in the ecommerce, a new payment transaction was created only when the transaction reference was different than the order number, meaning that the transaction id in the user session no longer refers to the current order, that the user created a new order which has nothing to do with the transaction he has in his session variable `sale_transaction_id` This made sense when the transaction reference strictly matched the order number, but, since f89e8f9df2c4ffaafc846082ac2b252c787e1e65, this is possible that a payment transaction reference number no longer strictly matches its order number, as the transaction reference can contain `-1`, `-2` at the end of its reference, meaning there was already another transaction existing with the sale order number as reference. But the transaction is still about this order. Therefore, from this revision, the condition on which a new transaction has to be created should no longer be based on the transaction reference, but to which `sale_order_id` the transaction belongs. In addition, we add two more conditions for which a new transaction should be created: - The transaction has been cancelled or in error - The acquirer has changed. For the second case, this is to handle a corner case: - The user selects one payment acquirer (Ogone), then click on "Pay now", and is therefore redirected to the payment provider website (Ogone) - Then, the user opens a new browser tab on the ecommerce, on his cart, choose another payment provider (Paypal), then click "Pay now" and is redirected to this second payment provider website (Paypal), - Then, the user comes back on the first tab, on which he is on the first provider website (ogone), and pays/validate the payment - Then, we receive the payment feedback (either from the user/DPN, either from the server to server call/IPN) Before this revision, this use case would have lead to the feedback from the first provider (`/payment/ogone/accept`) while the transaction is set with the second payment provider (`Paypal`), therefore breaking the payment validation. Creating a new transaction when the user changes of payment provider solves this issue. He will nevertheless be able to pay twice, on each provider, but it was already the case before. opw-659294 --- addons/payment/models/payment_acquirer.py | 2 +- addons/website_sale/controllers/main.py | 3 +-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/addons/payment/models/payment_acquirer.py b/addons/payment/models/payment_acquirer.py index 5d65f7fbaff..17139195f2d 100644 --- a/addons/payment/models/payment_acquirer.py +++ b/addons/payment/models/payment_acquirer.py @@ -454,7 +454,7 @@ class PaymentTransaction(osv.Model): def get_next_reference(self, cr, uid, reference, context=None): ref_suffix = 1 init_ref = reference - while self.pool['payment.transaction'].search_count(cr, uid, [('reference', '=', reference)], context=context): + while self.pool['payment.transaction'].search_count(cr, openerp.SUPERUSER_ID, [('reference', '=', reference)], context=context): reference = init_ref + '-' + str(ref_suffix) ref_suffix += 1 return reference diff --git a/addons/website_sale/controllers/main.py b/addons/website_sale/controllers/main.py index 1e82a153509..12498409a92 100644 --- a/addons/website_sale/controllers/main.py +++ b/addons/website_sale/controllers/main.py @@ -804,12 +804,11 @@ class website_sale(http.Controller): tx = request.website.sale_get_transaction() if tx: tx_id = tx.id - if tx.reference != order.name: + if tx.sale_order_id.id != order.id or tx.state in ['error', 'cancel'] or tx.acquirer_id.id != acquirer_id: tx = False tx_id = False elif tx.state == 'draft': # button cliked but no more info -> rewrite on tx or create a new one ? tx.write({ - 'acquirer_id': acquirer_id, 'amount': order.amount_total, }) if not tx: