Now having
* sanitize: run the sanitizer to clean the html (removing javascripts,
unwanted tags, ...)
* sanitize_tags: only a subset of tags is allowed in html content.
Unwelcomed tags are remove dand their content stripped.
* sanitize_attributes: only a subset of attributes is allowed.
* sanitize_style: only a subset of style attributes is allowed. Style
attributes are parsed to keep only a white list.
* strip_style: all style is removed. It bypasses sanitize_style as there
is no need to sanitize something that is removed.
* strip_classes: remove class attributes
Fields parameters have also been updated to match the sanitize options. Html
fields by default are sanitized with sanitize_tags activated but without any
further options. All addons have been updated to match the new options
according to their previous behavior.
* 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.
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.
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.
Both website_sale and website_quote have logic to independently
confirm sales orders when a successful payment transaction is
processed.
Rev 46c5f93b6c introduced an extra
check and logging for transactions with mismatching amounts in
website_sale, but the same change was not done in website_quote.
Consequently, when both modules were installed, the tx mismatch
check was bypassed by website_quote, and a spurious logging message
was emitted by website_sale if the website_quote logic had executed
first.
This patch makes tx handling consistent in both modules, and avoids
the misleading log message when both modules are installed.
The transaction `type` of an order can depend according
to the order.
For instance, if the order leads to recurring payments,
the transaction type became `form_save`
instead of `form`.
This new method allow to easily override this `type` value
for other modules, so the entire button
rendering code does not have to be
copy/pasted.
Yannick Tivisse