| Age | Commit message (Collapse) | Author |
|---|
|
Customer portal controller and templates contained in website_payment
module are moved to payment. This module now uses the customer portal
defined in portal module and most of website_payment code is moved
to payment.
website_payment now contain code really related to website, such as
payment acquirers configuration for website.
|
|
on registration
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
|
|
|
|
employees only
In 8.0 private fields have been recently set as visible only to employees
at commit b2265108406e0dc1d1e1250fdbad5bc2cee2006d.
However between v9 and v10 two new payment acquirers have been implemented
payumoney and stripe. Those addons now have their credential set as private.
Methods using the acquirers have been sudoed accordingly to avoid access
issues when rendering the buttons. Other payment modules will be updated when
the forward port from 8 to 9 and pre-10-master will be done.
|
|
Update design for registered cards
@courtesy of @fhe-odoo
|
|
|
|
Since saas-3, website controllers use `request.website.render`
to render the template of a web page. This was kept for retro
compatibility. It's time to stop using deprecated stuff.
Same for `_render` method on website.
'json' route don't use `request.render` since
`JsonRequest` has no `render` method.
|
|
I assume this was necessary before the migration of payment because
an api.one wrapper was added by the auto-guess api feature.
Since payment has been migrated, this decorator is no longer present
and the result of _registration_render is no longer encapsulated in
a list. Therefore, taking the zeroth element was akin to taking only
the first character of the rendered html. Usually \n, which is not
useful but which also prevented the crash to be easily visible.
|
|
Methods with signature
- cr, uid, id
- cr, uid, <browse_record>
have been refactored to be future multi ensure one methods.
|
|
|
|
|
|
On the other routes (e.g. /my/, /my/contract/) payment information on the parent
contact are displayed but can not be access in the my payment route.
You get in a unconsistant situation where you can access the contract of the
company and its payment information but can not use this payment information.
opw-681491, opw-681502
|
|
payment.method was not a good name because it was too easy to confuse
with account.payment.method.
|
|
* Fixes a bug that prevented the system to fetch the default provider
because the default_get call was wrong (wrong model + missing
company_id kwarg)
* Displays the amount as a monetary widget (to do that, the amount
must be sent as a float in the controller)
* Display the acquirer 'pre_msg' field to display eventual fees
|
|
Missing s of method for allowed methods.
|
|
longer prevent paying
Payment transactions referenceis have a unique constraint which was problematic when a payment was cancelled from the acquirer's page.
To stick the to DRY principle, I factorized a method that checks for existing references and happens a numerical suffix if necessary.
This was already implemented in website_payment but was moved to payment and used in website_sale.
|
|
- generate payment from the frontend using a simple form
- send a payment with a simple url
- define a default provider for payments
|
|
With this module, you can register payment methods with a nice formatting
|
