As some flows were broken, this set of fixs improve the different routes for all acquirers
See commit messages for more information
Thanks to @jpr-odoo for his first implementation and to @tde and @fgi
If the user has no Zip code, country or city, authorize refuse the payment, but Odoo doens't show any error.
The commit invite the user to log in in this case or to fill his missing information
Previous to this commit, if a user hadn't properly set up his
Authorize.net credentials, when getting a response from Authorize.net's
servers, we would expect some attributes to be in the response's body,
but this is not the case if the credentials are wrong, thus we would
have an unexpected error like "NoneType object has no attribute text"
which is only a sympton of the real error (bad credentials and no
error-checking).
This is fixed by checking if the response body contains an error
message, if it is the case we raise an UserError with the error code and
the error message (which is only shown if debug mode is activated).
OPW 788261
The regional variations are not published on Transifex and hsould be translated
manually.
The translations are mainly from previous versions or contains buggy fuzzy
translations (not matching the real source string).
Clean based on the .pot and delete the empty files
Fixes#21733
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).
This reverts commit fb093726d7.
In my hurry, I forgot part of this debug feature, which made it crash
because I tried to stringify a element instead of a tree
fda-odoo