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
* 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
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.