Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
The form builder offers the possibility to add a "Custom File Upload"
field. When the user clicks on "Send", an error occurs ("An error has
occured, the form has not been sent.").
This is because we try to send a mail linked to "mail.mail", which
doesn't make sense.
The case was actually taken into account in the code, there was just an
oversight in the code.
opw-684040
Change checkout process.
- Billing address is always the connected partner_id or neww partner_id.
- Shipping address is contact of current commercial_partner_id
- New checkout design for address selection
- Add delete a line in my cart
- Fix input quantity size
- Refactor/Reindent xml template from website_sale
- Improve the modularity for checkout (preprocess, posprocess, required fields, ...)
- Allow to use form builder in extra step for OEE (No edit mode)
- Add route to have states according country selected (need to be overridable for website_sale_delivery)
- ...
By default, werkzeug doesn't preserve the order
of the parameters sent to routes.
As stated in the werkzeug documentation:
```
parameter_storage_class
the class to use for args and form.
The default is an ImmutableMultiDict which supports multiple values per key.
alternatively it makes sense to use an ImmutableOrderedMultiDict
which preserves order or a ImmutableDict which is the fastest
but only remembers the last key.
It is also possible to use mutable structures, but this is not recommended.
New in version 0.6.
```
For some of our use cases, it makes sense to keep the order
of the route parameters.
e.g. In the website builder, when building a form
with a bunch of inputs values that will be concatened
in a lead note, the user expects the answer to be displayed
in the same order than the form inputs.
This change is seen as a bit risky as it could lead to
performances issues in the http routes processing, and this
is the reason we do not merge this in stable 9.0 at the moment.
If needed, it could be back ported later to 9.0, after
several weeks/months of testing in this release(saas-10 atm).
opw-677508
* The compiled templates are cached per user, lang, inherit context values
* ir.ui.fields: attributes method return an dict, and record_to_html return only the content value of the field
* all rendered text use build_text and all attributes use build_attribute
* t-esc-options is removed and replace by format_value method
* AssetsBundle receive the list files and remains
If the feedback of a form is too slow, people might be tempted to
click a second time, trigerring a second request. If, after that,
the result has not been received yet, the user might be tempted
to click a lot of time because he is angry at such slowness. This
behavior would trigger a record creation each time the user clicked
the submit button. This fix disables the button once it has been
clicked once, and re-enable it if the record could not be created,
which means that there was an error in the input and the user needs
to change the values and try again.
The button has been changed to a span to avoid the default browser
behavior to post the form when no function is bound on the send button.
If the feedback of a form is too slow, people might be tempted to
click a second time, trigerring a second request. If, after that,
the result has not been received yet, the user might be tempted
to click a lot of time because he is angry at such slowness. This
behavior would trigger a record creation each time the user clicked
the submit button. This fix disables the button once it has been
clicked once, and re-enable it if the record could not be created,
which means that there was an error in the input and the user needs
to change the values and try again.
The button has been changed to a span to avoid the default browser
behavior to post the form when no function is bound on the send button.
Martin Trigaux