In non-xml-debug mode we want assets to be cached forever, and the admin can force a cache clear
by restarting the server after updating the source code
Remove 'field' from 'value_to_html' method attributes
't-esc' escape the result of the widget.
(Added 'remove_span' as option for monetary widget)
E.g.: <t t-esc="32" t-options='t-options='{"widget": "monetary", "display_currency": website.currency_id, "remove_span": True}'>
result: $ 365.00
The _get_asset_content is cached in function of the template option, don't use context to load content because we must load the asset in function of the compiled caller template.
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)
- ...
res_partner now have a new concept of company_name. (duplicaed of parent_id)
That allow to a frontend user to have a company name without create a useless
tree of "Company -> Partner -> Contacts"
Before this commit, we was using street2 or street field to do the same thing.
That was confusing in some screens because according from where the partner has
been created, the company name was stored in distinct field and that was like
a bug for some users.
commercial_company_name is based on the same behavior of commercial_partner_id.
It is base on the field company_name.
In Partner form wiew, a quick button has been added in edit mode if however
the user want to create the partner tree to add new collegues.
Some address have required state.
We add by default moreover 500 new states.
We try also to merge duplicated states
wich have the same country and code.
Once merge is done, we try to had the unicity constraint
to avoid futur duplicates.
Merge code, should be removed in v11.
Setting the env of the qwebcontext is not sufficient because the closure
of the `loader` carries its own contexts and lang, so subsequent t-calls
may still use the original language.
This was broken by the new API conversion at commit
4ddc323139,
and further broken by the forward-port
6c8141a1dfa9fa44067d052b368e3851972d836cA with a wrongly indented line.
This prevents a model extension from:
- changing an abstract model to a non-abstract one,
- changing a transient model to a non-transient one or vice-versa.
Using a frozendict as context breaks the `t-lang` mechanism, as
the `loader` is not aware of the changes of a copied frozendict
and thus is still using the values from the original context,
including the lang one.
This reverts commit e1deae7eab.
The protection prevents fields to be invalidated/recomputed on some records.
This mechanism is useful against accidental cache invalidation when computing
or inversing fields. It also prevents to trigger the recomputation of fields
before and/or after their inversion.
Add a test on stored field with compute and inverse methods: the test checks
how many times the compute and inverse methods are invoked in several cases.
Essentially, the field should not be recomputed when it is written.
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
There's really no reason to limit group_operator to numeric fields and Postgres's flexible aggregate make the ability to aggregate on non-numeric fields (and/or non-numerically)
* moves group_operator to Field
* adds a default value of `sum` on integer, float and monetary fields
* in read_group, filters on fields with a group operator rather than by
type (also allow id fields, since Id doesn't have a group_operator by
default it will be ignored anyway) (sequence is still specifically
excluded for now because they're usually regular Integer fields)
Closes#12372
1/ The tip should be on the textarea, not on the button.
2/ The access right field on the quick user creation form is confusing.
I propose to put it in "Technical Feature" so that it's not visible for normal users.
3/ dissociate les settings tour from project tour
This extension of the method `mapped` is a consistent extrapolation of mapping
a recordset through an optional sequence of relational fields. It removes the
necessity of special-casing the empty sequence, and also avoids an obscure
exception in that case.
Bug introduced in 7eab8e2.
As `self.env.user` is browsed with `sudo`, the result of this call
will always return the admin's current company and not the user's current
company.
opw-681809
Jeremy Kersten