- When registering a payment token, validating it using a payment of a small amount (~1.50€) followed by a refund allows ensuring
that the payment method is valid (i.e. checksumming the card number simple ensure the number is valid but not that the card exists).
This commit introduces a generic approach that must be implemented for each acquirer that has tokenization support.
This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
- Introducing a new payment form that handles payment, deletion and adding payment method (only for server2server for the moment).
- On /my/payment_method, changed strings 'Payment Acquirers' to 'Payment Methods' which is more clear.
- Stripe can now be used to pay subscriptions.
The field `acquirer_reference` is not a mandatory field. If not
retrieved from the provider, it will have a NULL value in the DB, and
therefore will be `False` in Python.
The `capture` and `void` method will crash in this case, because of:
`etree.SubElement(tx, "refTransId").text = transaction_id`
opw-751231
The callback_eval field has a groups parameter of
base.group_system. Without this patch everyone not part of that group
ends up with an access right error when the system attempts to read
that field.
Previously this was not a problem because all code reading
callback_eval was executed with the superuser already. New code has
been introduced however that does not do this (eg. paying with a
payment.token from the backend).
opw-741181
PURPOSE
=======
The field auto_confirm is complicated to understand for common users. Furthermore, on of its options is only useful for authorize module.
SPECIFICATION
=============
Remove the auto_confirm field. The destinies of its options are the following:
- none: Simply disappear.
- authorize: Become capture_manually. It has nothing to do with the auto_confirm field has it's related to the autorize module (And could be extended to other payment acquirers too).
- confirm_so: Remove it. Will be automatic, and we will always validate the sales order and generate the accounting entries on acquirer validation.
- generate_and_pay_invoice: Is linked to the journal_id. The field journal_id is always set and we will use it to validate the sales order and generate the accounting entries on acquirer validation.
Bonus: website_sale: Allow to create/validate invoice automatically on `Mark as Paid`
``import odoo.addons.foo as bar`` doesn't seem to properly trigger the
import hook in Python 3 (it blows up on decimal_precision and
base). Thus convert *all* examples of that pattern to the more
sensible ``from odoo.addons import foo as bar``.
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
The callback_eval field has a groups parameter of
base.group_system. Without this patch everyone not part of that group
ends up with an access right error when the system attempts to read
that field.
Previously this was not a problem because all code reading
callback_eval was executed with the superuser already. New code has
been introduced however that does not do this (eg. paying with a
payment.token from the backend).
opw-741181
When no email is defiend on the partner, a traceback is raised when
paying with Authorize.net.
The `text` attribute requires a string, not a boolean (`False` in this
case).
opw-728301
callback_eval is currently a code string that is evaluated directly
at payment confirmation. This commit changes it to have parameters
on the record and method to call on it. Moreover a hash done once at
transaction creation ensure that a modified transaction does not allow
to execute code on other records.
The `reference` field is used as `invoiceNumber` in the Authorize.net
API. However, this field is limited to 20 characters. Larger references
will produce an error when the API is called.
Source: https://api.authorize.net/xml/v1/schema/AnetApiSchema.xsd
opw-704615
- Create a SO, link it to a Quotation Template (e.g. "Odoo Monthly" from
the demo data). Note that the Quotation Template must require a
payment.
- Click on "Preview", then "Accept & Pay" in the website quote
- Pay with Authorize.net
- In the Subscription linked to the SO, change the invoice date to a
date in the past (so it will generate an invoice)
- Execute manually the Scheduled Action "Generate Recurring Invoices and
Payments for Subscription Contracts"
The payment is correctly registered on Authorize (you should receive a
confirmation email), but:
- No invoice is generated
- The next invoice date has not been changed
The issue comes from the fact that:
- `payment_authorize` executes the callback method
`reconcile_pending_transaction` before changing the status of the
transaction.
- The method `reconcile_pending_transaction` cancels and unlinks the
invoice if the transaction is not 'done' or 'authorized'.
In order to solve the issue, two fixes are necessary:
- Switch the status update with the callback (this commit), as it is
already the case for Ogone and Stripe.
- Do not manually call `reconcile_pending_transaction`, since it is
already executed as callback. This avoids two increments of the period
(commit in Enterprise).
opw-694730
This commit improves the tokenization process, allowing users
to set the acquirer to save payment data never, always or letting
the customer decide (only implemented in ecommerce for now).
Support for tokenization is improved for Ogone and Authorize.net
This commits also factorizes advanced payment features support
(authorization, tokenization, fees computation) in a generic method
overriden by every provider to specifiy which features are supported.
This process can be used in views to hide/show fields depending on
feature support or in constraint checks.
This commit add s2s communication to the Authorize.net payment
provider, allowing the user to:
- Create a payment token
- Charge a payment token
- Authorize/capture transactions
-*- coding: utf-'8' "-*-"
is not a valid encoding. Introduced by
666387a274 I think. It was probably a
typo/replace gone bad and it got copy-pasted everywhere. Emacs complains
every time you try to save changes to files with this invalid encoding.
This changes all of them to
coding: utf-8
adhering to eae045949d.
Done with:
find . -name '*.py' -print0 |\
xargs -0 sed -ie 's/-\*- coding: utf-'"'"'8'"'"' "-\*-"/coding: utf-8/'
merge *ALL* the dicts
The form rendering used to receive a dict for partner information and a dict for tx information and to transmit another dict to the qweb template; now everything is done in a single dict
Denis Ledoux