| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Authorize.Net is phasing out the MD5 based hash use for transaction response
verification in favor of the SHA-512 based hash utilizing a Signature Key.
Instead of hashing with md5 the transaction key, it is now required to hash
the signature key (binary format) with SHA-512.
Support for MD5 will be dropped the 7th March 2019 for sandbox environment and
the 28th March 2019 for production environment, initially planned for the 14th.
Note that as of February 11, 2019 authorize removed the ability to configure or
update MD5 Hash setting in the Merchant Interface.
Merchants who had this setting configured have been emailed/contacted.
opw-1943030
Usefull links:
https://developer.authorize.net/support/hash_upgrade/
https://support.authorize.net/s/article/What-is-a-Signature-Key
https://support.authorize.net/s/article/MD5-Hash-End-of-Life-Signature-Key-Replacement
https://support.authorize.net/s/article/Do-I-need-to-upgrade-my-transaction-fingerprint-from-HMAC-MD5-to-HMAC-SHA512-and-how
closes odoo/odoo#31642
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
|
|
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
closes odoo/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
|
|
|
|
Introduced by 669c23d58dce65804ccb46b27e401e758d0f904c
opw:1817597
|
|
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
|
|
As this module is already in new API only small linting is performed.
|
|
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.
|
|
Authorize.net requires both billing and shipping data.
opw-660771
|
|
compatibility for payment providers
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
|
|
adding specific fields for every.payment.provider
|
|
3375ff2827d10df8059bac0e599061086769e8f4
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.
|
|
|
