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
Adding date & datetime inputs in the website
form builder couldn't work, because
the posted values for these input
types were not treated at all,
and they were not in the format
the date/datetime were stored in database.
opw-672674
* blacklist all fields by default
* don't use blacklist in get_authorized_fields which is called to see if
a field can be added to a form, instead only use it afterwards to see
if the field can be written to by the formbuilder. That way
formbuilder can whitelist fields which are actually added to forms
on-demand resulting in a more secure interaction
In some instance, the mail content of a sent form would only be text
formatted. This could lead to a message with no newline, thus making it
illegible.
This fix has to be ugly since body_html field of a mail.mail is of type
text.
In the form builder, custom field name could contain special char but
the get key values are of the type str whilst the value are in unicode
type.
Thus when concatenating them, one should be converted so they are
uniform and don't lead to an encoding error.
opw-656745
- Fixed the module name and category in manifest
- Fixed website_form_blacklisted being ignored
- Unauthorized readonly and magic fields
- Reset the form on successfull submit
- Added missing date field
- Added date and datetime validation
Christophe Simonis