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.
Fees were not recomputed when the amount or the acquirer of the
payment transaction was changed.
This can happen if the user clicks on
"Pay now", which creates the transaction and computes
the fees for the first time and then redirects
to the payment provider, and then the user
came back from the payment provider, hitting the previous
button in his browser, for instance, and then
changes the content of his cart (the quantity, or even
the products) or change of payment provider
(from Ogone to Paypal, for instance).
opw-649509
How great is it to get Odoo (almost) 9.0 (almost) translated?
Clean .tx/config file
Regenerate .pot files
Fetch current translations from Transifex (10% completion)
Now that most refactoring has been merged
It is better to have red a great work of another culture in translation than never to have read it at all.
― Henry Gratton Doyle
merge *ALL* the dicts
The form rendering used to receive a dict for partner information and a dict for tx information and to transmit another dict to the qweb template; now everything is done in a single dict
- replace the portal_sale blue ribbon by a website_portal_sale link from the portal home
- remove all fields and methods related to banner in portal_sale
- remove "validation" field in payment_acquirer since it was only used here
- general:
- add payment.method and payment.transaction menu in invoicing
- payment.acquirer:
- add image field
- add stat button to see payment.transaction objects
- payment.transaction:
- language field is now a selection instead of a char
- rename s2s_cb_eval field in callback_eval
- form view cleaning
- on_change_partner_id now fills in the partner details
- add an ir.sequence for transaction name
- add a many2one to payment.method
- country defaults to the country of the company
- payment.method:
- add a one2many to payment.transaction
- add a stat button to see payment.transaction objects
[IMP] website_quote: rename s2s_cb_eval payment.transaction field to callback_eval
[IMP] payment_* (all providers): add image data and rename s2s_cb_eval field to callback_eval
Better display of contacts, simplified contact creation, use default image
for shipping and delivery, and various fixes and improvements in the
form view.
Main impacted addons :
- account: add a bank_account_count field and stat button that replaces the
2many field
- base_vat: remove the button to check vat, as there is already a constraint
and removed and unused import
- payment: add a payment_method_count field and stat button that replaces
the 2many field
- website_sale_delivery : set the field website_published into a stat button and set the form into a sheet
- payment : Payment acquirers unpublished by default, and website_published set into a stat button
- website_partner : res_partner unpublished by default, to avoid partners as “Plusbelle LaPoubelle” to be published on the prod (True Story)
- website_sale_delivery : Delivery method unpublished by default. Adapt the demo data to be published (to avoid breaking a test), and set the field website_published into a stat button.
In the partner model, there is only one field `name`.
The first name and the last name are not within two
separated fields.
By assumption, the firstname is written before the last name
(first <> last)
This assumption should be kept when sending the
first name / last name of the partner to the payment acquirers
e.g. Paypal.
opw-643120
-->Company form view :
- Campany Tagline moved in the header, invisible if empty
- Partner field set in group_no_one
- Account Holder removed from tree view
- Intercompany rules tab/Responsible fields into group_no_one
-->Account res_config form view :
- Charts of account : code and #digits fields removed, as they depends of the country
and are configured in the datas
- Use Anglo Saxon checbox : Automatic, removed from the view
- tax_calculation_rounding_method field set automatically in the CoA : Removed
- Manage customer payments and follow-ups are enabled by default, so removed the option
NB : Some fields has been removed from the setting view because of legal issues and
also because they are automatically filled with the CoA.
If they have to be modified in some countries' CoA, they have to be added to the view
in these specific CoA, not is the standard view.
This commit adds a new model, Payment Method, which stores
a reference to the payment acquirer's database and a reference to
a partner. Each payment module must have its own implementation.
The implementation is completely abstract but may not suit every
provider's way of implementing recurring payments.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.