* Remove dead code
* Clean variable assignation to a record set and use a dedicated variable to
hold the result instead of setting a property on records
website_quote still calls sale_order_line.product_id_change() in old API,
giving arguments that are not supported anymore. It does not crash because
'reasons'. However the new onchange does not return values since v9. The
call is therefore not necessary anymore and the computation has been adapted
accordingly.
Sometimes, the sidebar on quotation previews can overflow the footer
if the window height is too small. To prevent that, the position of
the sidebar is blocked before overflowing, thanks to affix.
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.
A new API is introduced for price computing using pricelists. It is simplier
to use in most use cases, which is computing the product price in a given
pricelist. Old methods return dictionnaries and tuples, which are rarely
used in the code.
product_uom._compute_price() is now an ensure_one multi methods, taking
a browse record as second unit. This helps simplifying and unifying the
various calls and price computation methods.
Commit c21568e14f deactivated the sanitization of frontend html fields so
that their modification through the editor worked again. However,
this broke the possibility to display their traduction and to modify
them.
The problem is that the translate option of html fields should not
equal "True" but instead be the html_translate function defined in
openerp.tool.translate. The translate=True option is automatically
change in html_translate though but there is a condition: the field
should be sanitized, which is why this broke since the sanitization
is disabled.
This commit sets the translate option of non-sanitized html fields
to html_translate. Maybe we should investigate for this to be automatic
for non-sanitized html fields as well.
Thanks to @rco-odoo.
Since commit c9e38cae9f in saas-10, the html fields are sanitized in
strict mode by default. This breaks all html fields behaviour when it
is editable in the website editor.
This commit deactivate the sanitization for such HTML fields (like it
was already the case for blogs contents or products descriptions for
example). A more specific sanitization will be implemented in future
versions.
The form_save payment type is used by acquirers (currently only ogone)
to return a reusable payment token on successful payments. These can
then be used to charge the customer again.
To be displayed correctly on odoo app (In a given category and not only in all or hidden)
the module category in the __openerp__.py file should be one of these:
"Accounting",
"Discuss",
"Document Management",
"eCommerce",
"Human Resources",
"Industries",
"Localization",
"Manufacturing",
"Marketing",
"Point of Sale",
"Productivity",
"Project",
"Purchases",
"Sales",
"Warehouse",
"Website",
"Extra Tools",
'Accounting & Finance' will not work, as 'Project Management', ...
l is not defined, it is line.
Bug introduced with commit odoo/odoo@5f5f8d8.
But it was never detected before because there was
no value for b2b/b2C before commit odoo/odoo@e6184aeb37
so total/subtotal in report was never print.
Allow to set in configuration mode b2b or b2c.
Change the column of order line in sale view and in reports depending of sale.
Fix price_reduce field (wrong if tax was included in price)
and merge with code discounted_price from website_sale.
Change header from reports "Price Tax Excluded' by 'Price' in report.
That is wrong, sometime the amount can haxe tax included in the price.
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
website_sale and website_quote both did their own
form_feedback. This causes issues because:
1. it would force upcoming features to have to be duplicated as well
2. there's a risk that improvements/bug fixes will only be applied to
one module, an example of this happening is
46c5f93b6c.
Dhaval Panchal