In 8.0 private fields have been recently set as visible only to employees
at commit b226510840.
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.
Xpath has been altered and logos displayed in right column or portal.
The pupose of these logos is to know when you arrive on the website (ecommerce)
with which payment method you can paid.
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.
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
Sale orders created through the website that have to be automatically
invoiced should ignore the delivery invoicing policy.
Otherwise you can end up with either an invoice not being generated at
all. This means the user has to manually generate and add the payment to
it. Even worse is if only some purchased products have invoice policy
delivery. In this case a partial invoice would be generated to which the
payment would be added, leading to a mismatch between invoice total and
payment amount.
Introduces two new options:
- confirm_so: to confirm the sale order on acquirer confirmation
- generate_and_pay_invoice: confirm_so + generation of invoice and
payment registration
Martin Trigaux