Before this commit, the lists of supported currencies by payment
provider were hard-coded in the Python scripts, which made them
unavailable to the users.
With this commit, the implemented initial lists of supported currencies
are displayed on the form view and are editable, because Odoo lists may
not be up-to-date. Empty lists do not trigger any filtering on the
payment providers to access payment methods.
For Authorize.net and Asiapay payment providers, the specific
`(authorize,asiapay)_currency_id` are removed and the generic payment
provider field `available_currency_ids` is restricted to a single-item
list when one of those providers is enabled.
task-2926016
closesodoo/odoo#101018
Related: odoo/enterprise#34158
Related: odoo/documentation#2788
Related: odoo/upgrade#4069
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit adds the possibility to define a maximum payment amount that
a given acquirer can process. If the payment amount exceeds the value,
the acquirer is filtered out of the available acquirers listed on the
payment forms.
While we're at it, the field `country_ids` is renamed to
`available_country_ids` to better depict that it is not a property of
the acquirer, but a configuration option. It will also be coherent with
the field `available_currency_ids` that is expected to be added soon.
Task - 2162165
closesodoo/odoo#82411
Related: odoo/enterprise#24412
Related: odoo/upgrade#3703
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, zombie payment tokens (= tokens linked to disabled
acquirers) could still
1) be used by internal users and
2) reactivated when the acquirer’s state changed to ‘test’ or ‘enabled’.
This is not desirable because zombie tokens should neither be used,
nor reactivated.
After this commit, all tokens related to an acquirer are unassigned
from linked documents and archived as soon as the acquirer’s state is
changed to ‘disabled’. Creating a payment with an archived token is
prohibited. In addition, archived tokens cannot be un-archived anymore.
task-2649806
closesodoo/odoo#93774
Related: odoo/enterprise#28661
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Users can now ask for a refund from Odoo for their transactions done
through Authorize.net. A refund will be triggered from Odoo when
necessary.
Only full refunds are possible.
Note that unsettled transactions will be voided as they cannot be
refunded.
Task - 2678757
closesodoo/odoo#92279
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
An overridable model method was added in a previous commit in order to
neutralize a database.
This commit introduce the implementation of this method for the payment
modules.
Also, a `_neutralize_fields` helper method is added on the
PaymentAcquirer model to simplify the neutralization of the various
payment modules.
Part-of: odoo/odoo#67825
This commit also drops the payment with redirection flow in favor of
the direct payment flow only, while preserving the currently used APIs.
See the merge commit for more details.
task-2333030
Co-authored-by: Adrien Horgnies <aho@odoo.com>
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2296213
The authorize payment API has deprecated their md5 based authentication
in favor of sha512. The `test_10_Authorize_form_render` test was failing
due to no-more-valid tests inputs.
As the `payment.transaction._authorize_form_validate` method verify the
status of the transaction before validating the form thank to 01216345,
calling `_set_transaction_done` is no more valid thus has been removed.
The reference has been changed due to the same commit.
closesodoo/odoo#36139
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Replace website_published and environment by a generic state on
payment.acquirer
Payment acquirers aren't enabled by default. When setting their state to 'enabled' or 'test', it is verified the required fields for the provider are set.
PAYPAL
------
The paypal tests are not working working for two reasons:
- we check that there is no date in pending state on payment
transaction, but since the refactoring in this commit: https://github.com/odoo/odoo/commit/01216345e28374b554bfe95df82d607c591271cf
the date is always set before the validation of transaction.
- Since the changes on dates, the datetime field doesn't return a string
anymore and the comparison fails. So we convert the datetime to string
for the comparison.
BUCKAROO
--------
The buckaroo tests were not working for multiple reasons.
STRIPE
------
The payment stripe tests were not working because:
- The reference set in transactions were not the same as the ones givent
to the payment provider.
- we were checking for a script tag in form that has been removed in
commit https://github.com/odoo/odoo/commit/7c639be4aadce20bf6662ab347470fadf9afd99f
AUTHORIZE
---------
This test cannot be tested on runbot due to its server to server way of
working
closesodoo/odoo#30105
It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log
This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.
To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.
Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043
[FIX] add domain based on journal to payment tokens
Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200
- Create a SO of 56.16
- Send the payment link to the customer
At payment, the transaction is refused by Authorize because of an
invalid amount.
When looking closely, the data sent to Authorize contains the amount
56.160000000001. This is due to the float representation. To avoid this,
we use `float_repr` instead of `str`.
opw-1832468
Purpose: When running tests, all the tests for the installed/updated
files are done. This commit adds a 'tagged' decorator that can be used to
tag tests. Combined with a new 'test-tags' CLI option, it adds the ability
to filter which tests are executed. For example, @tagged('slow') will
add a tag 'slow' to the test. The CLI option 'test-tags="slow"' will
only run tests tagged 'slow'.
One can use prefixes to select cases with tags.
'+' or no prefix means that the tests tagged with this tag are selected
for execution. '-' prefix will exclude the tests tagged with this tag.
Exclusion takes precedence over inclusion.
Also, by default, all Odoo tests cases are tagged 'standard' and with
the technical name of the module.
This means that when selecting tests with the 'test-tags'
parameter, if '-standard' is not specified, all tests tags are
going to be executed.
When tagging tests, one can remove such automatic tag by prefixing the
tag name with '-'. E.g. @tagged('-standard') will remove the standard
tag from the test.
Another example, if one wants to test the 'sale' module alone,
even without adding any 'tagged' decorator thos tests can be selected
like that: --test-tags="sale"
Tests are selected or deselected using a TagsSelector. When instanciated,
a string is passed with comma separated tests selectors like
'+slow,-standard'. When the 'check' method is called with a test as argument,
it returns True or False if the test has to be executed or not.
It seems that Authorize.net returns an 'Error' status when transactions
fail (note that it can also return an Ok status for different types of
failures).
This is incoherent with the way the authorize requests are processed,
since an Error resultCode will raise a ValidationError, rollbacking the
complete cursor transaction. This makes little sense, since there should
be a trace of the payment.transaction in the backend (preferably with an
explanation for the failure).
This fix adds an error processing step to the response handling of
authorize.net - while before, it was assumed that an 'error' result
meant an issue in communication/setup, now it is treated as an error
in payment and the payment.transaction status is set accordingly.
I've added a test for this and it was green (pinky promise), but this
particular test suite is deactivated (or perhaps only on nightly, I need
to check the nightly process with @nim-odoo).
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
* remove references to basestring & unicode (use relevant pycompat
helpers)
* remove some str calls (either entirely or replaced by relevant
helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views
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`
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
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
The installation of a new acquirer was a bit complicated : from settings,
check the acquirer, then apply (install the module) then list view of
acquirer and finally edit it in form view.
This needed to be simplified. The payment acquirers are pre-filled
in payment. From the kanban view an `Install` button installs and
redirects to the form field.
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
Besides, the test was particularly useful:
It tested that when 'Buyer' was sent as firstname
and 'Nobert' as lastname to Authorize,
authorize returned the opposite, 'Norbert' as firstname
and 'Buyer' as last name.
Valentin Vallaeys (vava)