- payment.acquirer have many fields with 'required_if_provider'
attribute and while saving form it gave an error like "Required
fields not filled", so it was confusing to know which required fields were empty.
- after this commit, it is displayed like "Required fields not filled (field name)"
opw:1881054
- We extract some code logic to methods to allow to override them.
This is needed for the subscription module where a payment token need
to be copied from a transaction to a subscription.
The subscriptions is created from a sale order and before the
payment.transaction holding the payment.token id is validated.
Since the payment.transaction is not validated, the subscription
module doesn't find the correct transaction.
By extracting this code logic, we can override exactly when it should
be.
- The method to compute the reference of a payment.transaction and avoid
duplicate was missing some edge cases (for example if there was a '-'
in the reference).
- The creation of transactions in the route /website_payment/pay was not
checking for duplicate payment.transaction.
- When clicking on the invoices stat button on payment transactions via
the form view a traceback is displayed.
This is due to the fact that the code is trying to access to a
member/field named "id" on an integer.
"invoice" is an integer, not a record/object.
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
The field `transactionReference` of Sips must contain only
alphanumerical characters. Previous commit 31dc6b888e solved
the special case of several attempts to pay, but a much simpler case may
appear in v11. Paying an invoice is likely to fail since the reference
contains by default `/`.
In the previous commit, we could simply modify the common `payment`
module code. In this specific case, however, we only change the
reference if the acquirer is Sips.
opw-1841483
This commit adds the auto-creation journal for installed acquirers.
This is not easy because:
- The acquirers are created on the 'payment' module but are enabled only when the specific module
is installed. E.g. Paypal is enabled with 'payment_paypal'.
- To create a journal, a chart of accounts is required. However, the post_init_hook on the
'account' module makes the installation order harder. E.g install payment_paypal directly:
The module are installed in the order: account -> payment -> payment_paypal -> l10n_generic_coa.
To fix the problem, the journals are created at two moments:
- During the installation of the chart of accounts.
- At the installation of an acquirer module. E.g. payment_paypal.
Was PR #23904
Was task: 1831620
Until now invoice_id is filled on the transaction only when we make
payments through invoice. However if we make payments through sale order
then invoice_id is not filled.
This commit fixes that issue. As there is no common point between
sale_payment and account_payment except payment, a void method is added
in payment and an override done in account_payment. That was when both
modules are installed code is correctly triggered.
This commit is related to task ID 1813602. Closes#22746 .
This was already the intended behavior, but in Python a return inside
of a try...finally does not behave this way. From the Python
documentation [1]:
When a return, break or continue statement is executed in the try
suite of a try...finally statement, the finally clause is also
executed ‘on the way out.’
This can cause issues because some payment acquirers will return an
error when refunding a pending transaction. This puts the transaction
in the 'error' state which means it won't be refunded anymore.
Additionally, putting s2s_do_transaction in a try...except like this
hides any traceback that occurs which makes troubleshooting harder.
[1] https://docs.python.org/3/reference/compound_stmts.html#finally
Steps to reproduce the bug:
-Just purchase a simple product using Authorize.net
-Click on "Pay Now" to be redirected to Authorize.net gateway
Bug: The company field added during checkout page was not filled.
opw:1817597
Purpose
=======
It looks a little to restrictive to only allow bank journals on payment acquirers.
For example on could want to define a manual payment acquirer linked with a journal of type "cash".
Allow both journal types instead of only bank.
Code to thumbnail payment icon image had an error for python3 because
from RPC the image would be a text string instead of an expected
bytestring.
This change accepts both and made another small fix in the view since
image_medium doesn't exist (and image is already thumbnailed).
A third fix was that removing an image caused an error.
opw-803722
closes#22088
When installing a payment acquirer from the kanban view, this would by
luck display the form view correctly.
But if we go back to the listing then forward to the form view, things
go awry.
This is because the listing action views have not been updated after the
module installed, this worked at install because we loaded a new action.
This commit change the action so when installing a payment acquirer from
the kanban view, the view is simply reloaded.
opw-786454
closes#21757
* add a method computing available acquirers and payment tokens for a
given partner and company. Those data will be used notably in customer
portal when displaying the payment form;
* raise if no partner_id set in s2s process. Indeed this field is
required but values come from a dict. Current code raises an error
about None being converted to Int instead of giving the real error;
- Fixed 500 errors when trying to display payment form because of variables partner_id/acquirer_id missing.
- Accepted credit cards are now display next to the acquirer name on the payment form
- Online quotation and e-commerce now use the new payment form.
- Added the ability to chose on an acquirer if it uses only form/s2s or both.
(Still need some code cleaning)
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.
- 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.
When registering a payment token, validating it using a payment of a small amount followed by a refund
allows ensuring that the 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.
payment_ogone: add support for tokens validation
Since subscriptions only accept tokenizable (credit-cards and such)
payment options, we must use the token_implemented field to filter out
non-tokenizable payment options (such as wire transfer) and because
token_implemented is a computed field, a search function had to be
created
Toufik Benjaa