- 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
Rev. cf1df16aea introduced new callback
fields with restricted access. The lazy hash generation in create() was
however causing access errors for manual transactions created by users
who are not administrators (e.g. Accountants).
Those manual transactions do not typically need a callback, but checking
the presence of the callback requires a limited sudo() context.
Similarly, the execute_callback() method may be called for a manual,
non-admin transaction, and should not do anything if there is no
callback, instead of crashing with an AccessError.
The generation of the hash and execution of the callback should be done
with a normal environment, though, as these must only be used for
transactions run by the system.
opw-747536
Purpose
=======
The field journal_id on a payment.acquired is required on the view. The only issue is that the journals cannot be created before having installed a localization. When the payment acquire module is installed before the localization, the journal id is not set on the payment acquire and it's impossible to make a call to `write` (For example publish the acquire)
Specification
=============
When making a write or a create on a payment acquire, udpate the journal_id with a default value if not set.
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`
* add a constraints about authorized state for tx and authorize feature
available on acquirer;
* order acquirers first by publish, then sequence then name;
* add a sequence on some provider data and use a default to have some
popular acquirers first;
* use update instead of write in an onchange;
* add provider, related on acquirer_id.provider, in order to display
certain piece of information on tx depending on their provider;
* better tx form view and partner address display;
* remove unnecessary notebook on tx form view as it is not used;
* rename Payment Acquirers menu into Payment Methods, easier to
understand;
* acquirer kanban view improved to install / activate / configure them
depending on their state;
* be able to publish / unpublish acquirers without having to wait for
website_payment to add a button;
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
SIPS payment has two limitations:
- A payment reference can only be used once, even if the payment was not
proceeded
- A payment reference can only contain alphanumerical characters
These limitations do not fit the payment process which:
- Reuses existing transactions
- Introduces a `-` character when creating a new transaction for the
same order.
First issue is solved by an ugly hack since there is no link module
between `website_sale` and `payment_sips` in order to override the
behavior of `sale_get_transaction`.
Second issue is solved by modifying the character to `x`. In this case,
we could consider overriding the method `get_next_reference` in
`payment_sips`. However, this method is called before the creation of
the transaction, and we should do a crappy workaround using the context
to get the `acquier_id`.
opw-728209
Allow to configure the bank statement import mode from kanban
When doing a manual journal entry, don't show the maturity date
Removing Issued total, using credit instead (less code, more
useful to have due amounts, instead of overdue)
Creating a bank, set a name 'BofA Current' and an
account number (that way, the account.account is based
on name)
Settings Wizard & menus: better sentences
Statement CSV Import: installed by default (it
does not add any menu)
remove use_in_payment: complex field, only
used for a default value
Small code cleanup
[IMP] sale: moving order date to secondary tab (strange on a quotation)
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 payment reference of a S2S transaction has the given format:
'PAYMENT-9-170110_200204'. However, the reference is too long for some
providers such as Authorize (limited to 20 characters).
We make the reference less verbose as a first step to solve the issue.
However, case-by-case solutions will need to be found since the
reference depends on the id, which will ultimately grow.
opw-704615
If the database is create in monolangue and `en_US` is not present, the default
value computation crashes as tries to assign a value not present in the
selection (all installed languages).
Use the environment language as default (same as the default of res.partner).
It may be empty but not a value not existant in the database.
Fixes#15165Closes#15176
Remove field 'display_on_footer' to stop displaying
account journal on report documents.
As the field is removed but also used in payment to
generate default 'Thanks Message', put a new field
on account.journal in payment module, to keep the
role 'display_on_footer' had in payment.
It is already defined as a payment method (subtype=inbound) and that's what we want. No need of adding 'electronic' in 'payment_type' selection (that crashes if we select that, btw) and 'payment_method_id_code' is a duplicate of 'payment_method_code'.
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.
Since the creates overrides needs some information that do not end up
in the final record, let's avoid warning by removing all non-model
fields from the call to super.
This allows using a modern e-commerce flow where amounts are first
authorized at checkout then captured when the picking is in fact
shipped instead of immediately capturing the amount.
To access this flow, a new selection value is available on the payment
acquirer: "Authorize the amount and confirm the SO on acquirer
confirmation". If this value is selected, s2s/form transactions should
only require authorization to the acquirer; the user can then
capture/void the payment manually from the Odoo backend transaction
form view by simply using buttons.
tbe-odoo