The style of a link (color) of a many2one is only applied over the
first line (probably for eg. the partner on an invoice that has the
partner name and on following lines the address).
In some instance this make some sense, but on other (the name of a
product is too long from where it is) it makes no sense and seems buggy.
With this change, we have the link style over the whole link which seems
good enough.
opw-1947113
closes#31568
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when a view was removed during a module update (eg: the
record was deleted from the file), its COW views would not be deleted.
This could lead to unwanted behaviors including tracebacks(1).
This commit is somehow related/an extension of b5fe23055d that handle COW view
write during module update and 2e32cc5aa3 that remove COW views during module
uninstall.
task-1931683
Note: Some existing tests had to be run post install
(1) A view doing a t-call is COW'd, then that view and its t-called view are
removed. If the cow view is not removed, the t-call will crash (see tests
in this commit for detailed case).
closesodoo/odoo#31295
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Do not apply the duplicated route to the products/categories/warehouses
the original one was applied to.
Fixes#31610closesodoo/odoo#31619
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit has been backported in 11.0 [1] and then reverted [2],
because it introduced a regression in web_studio, discovered at opw-1947380
As no forward-port has been done between the backport and the revert,
the forward-port of the revert also contains the patch itself, resulting
in a noop.
Actually revert 06d73eab62 in branch `12.0`.
[1] d855e3911f
[2] 1748b46718closesodoo/odoo#31637
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this commit, when printing an invoice, the taxes were grouped
by their tax group (NOT by their parent tax)
Summing the base of each tax in the process.
This was largely insufficient, as tax groups can have taxes
with different rates or computation method within them
The summing of the base of each tax for reach tax group was in this case plain wrong
This commit aims at grouping by
group > computation method > amount
Which makes more sense
OPW 1947202
OPW 1945353
closesodoo/odoo#31617
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
On /shop, we access the image field to generate the image widget, but we don't
actually need the image content, we just need its url. When `bin_size` is added
we don't compute all the resize for nothing.
opw-1923999
task-1922055
PR: #30274
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The `_get_combination_info` override in website_sale_stock is only necessary
when we want to get the stock, which is on the product page RPC.
Before this commit, the stock would be computed all the time, which slowed down
the requests for no reason.
opw-1923999
task-1922055
PR: #30274
In order to increase performance, it was decided to avoid computing the first
combination on the /shop page, because it has to be done for many products in a
loop. Instead, we only display the template data, which is faster to get.
This implies that when using only one variant, we need to always write on the
template image instead of the variant image. This is needed because when there
is only one variant, the user doesn't know there is a difference between
template and variant, he expects both images to be the same.
To achieve this, we also had to change how the quick buttons work on the /shop
page ("add to cart", "add to wishlist" and "add to compare"). Indeed it was
decided that their behavior should be the same, no matter how many combinations
existed or not on the template. Therefore, the standard behavior of those
buttons is to always do their action on the first possible variant, that is
cached so we can use this logic without ever needing to read anything else than
the template data (and the cache).
opw-1923999
task-1922055
PR: #30274
Change the domain to not include `.id` and to use `in` to prevent subqueries
to be ran by the ORM for each attribute value.
On the filter, directly use `attribute_value_ids` instead of the computed field
`product_template_attribute_value_ids` that leads to the same result, to prevent
unnecessary compute of that non-stored field.
Cache the result of the method. The cache is invalidated when the configuration
of attributes and values change.
We can remove all cache invalidation from the tests since it is done at the
appropriate times in the business code now.
opw-1923999
task-1922055
PR: #30274
Take advantage of prefetch and api.multi, instead of calling plenty of methods
that didn't cache their result and did separate queries for each record.
opw-1923999
task-1922055
PR: #30274
The method was doing an unnecessary sort since the _order has been fixed in
f8dad1bb4b
Moreover, it tried to find the ptav through the attribute_id related field and
a map on the other side, instead of directly relying on the ids of the ptv.
opw-1923999
task-1922055
PR: #30274
We replace `_get_first_possible_combination` by a generator. By iterating it, we
can find as many possible combinations as we want, as suggested in task 1936680.
So if we need to get or to know if any arbitrary number of combinations exists,
we can just iterate on the generator multiple times, without having to start
over from the start every time.
opw-1923999
task-1922055
PR: #30274
Before this commit, the list view of variant didn't use `_get_combination_info`
so the displayed price was not taking into account important settings such as
B2B/B2C and currency convert.
This reverts commit 08b2d1f9ac and the
subsequent commit a75533daf2be325e059f0d4badfb0cf3a2f7590f, because they
caused more problems than they solved.
Not only did we get issues with missing footers in some cases, but the
address box also gets misplaced on the left in many layouts.
See #31184, #31533, #31531
See opw-1925894 (reason for patch), opw-1948160 and similar ones (regressions)
Closes#31626
Before this commit, when hovering on a email icon of a message
in chatter without any customer email data, there was a crash
with the following error message:
"No enumerator given to foreach"
This was caused by `undefined` being passed to `t-foreach` when
there are no customer email data on the message. Since
`undefined == null`, it raised the error above.
closesodoo/odoo#31587
Signed-off-by: =?utf-8?b?QWxleGFuZHJlIEvDvGhuIChha3Up?= <aku@odoo.com>
This commit introduced a regression in web_studio, discovered at opw-1947380
A fix in web_studio will be integrated too but the regression is the proof this
commit should not have been integrated in 11.0.
While the new behaviour introduced at d855e3911f makes more sense, it is still
a change of behaviour that should not target a stable version.
For the problem raised at opw-1887162 that d855e3911f was trying to fix, a
workaround should be used instead.
For instance, setting a widget='html_frame' allows to translate in the website
editor that handles this correctly.
In master, the new behaviour can be maintained and eventual regressions will be
investigated there.
closesodoo/odoo#31585
Signed-off-by: "Martin Trigaux (mat)" <mat@odoo.com>
`this._id` is overriden by the crosstab_bus, so the event handlers
weren't unbound at destroy.
closesodoo/odoo#31578
Signed-off-by: "Aaron Bohy (aab)" <aab@odoo.com>
Since https://github.com/odoo/odoo/commit/5a030db3eb77b6d80187f8ae1a64303b2f50391d
the HTML editor displayed the translated versions of the templates it
allows to customize. So if the user edited and saved such a template,
the non-translated version was saved with translated-version content.
The behavior before the mentioned commit was:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, re-make a RPC to load the view again
The mentioned commit made this simpler by making:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, simply show the previously loaded view
... the problem was that the step (2) of the old behavior was
explicitly saying (client-side) to load the view's untranslated content.
This commit makes step (1) always load the untranslated versions of the
views (server-side).
It seems that our beloved administration is not happy with the FEC file
ending with an empty new line
Hence, this commit makes the FEC file last line end without \r\n characters
and there is no empty new line
OPW 1943302
Before this commit, a pricelist discount based on the product qty could
be created and the user may believe that it will work also for event
tickets.
Now: when configuring a pricelist discount based on the product qty a
warning message is show to alert that this kind of discount don't work
in event tickets.
opw-1940368
closesodoo/odoo#31459
Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>
Together d60f2ab0e2 and
24ca67b545
corrected the triggering of automated actions at *each* recompute of a field
It is problematic since, maybe, the field that should trigger an action
*is* a computed one. It often happens with "state"-like fields
This commit aims at applying the logic of those two commits,
except in the case we do want the action to be triggered
even in a recompute case
OPW 1935727
closesodoo/odoo#31422
Signed-off-by: "Lucas Perais (lpe)" <lpe@odoo.com>
On some chart of accounts, some records (e.g. account.tax on l10n_be) have
children and some are deactivated when the chart of account is created.
The children on the account.tax and templates were not created in the same order
The deactivated records were not found in the search.
Before this commit the translations did not match the right record on the
account.tax (e.g. 21% tax translated with a 12% name in Dutch)
Bug noticed with avw
closesodoo/odoo#31510
Signed-off-by: "Martin Trigaux (mat)" <mat@odoo.com>
Have a product that is an event, with the price of 1500.
Create a ticket for this product in an event, with the price of 600.
In a SO, add a line with this ticket.
Before this commit, when you change the product, to another product that
is also an event, the event, the ticket and the price stayed the ones of
the first product.
Now, the event, the ticket and the price are updated when the product is
modified.
opw-1940368
Werkzeug version was being checked to avoid passing quote=True to
werkzeug.utils.escape (as that parameter was changed to `True` *and
deprecated* in 0.9).
However because DeprecationWarning was made silent by default in
Python 3.2 and the way the check is implemented worked for 0.9 it
looks like nobody really noticed it's broken in the usual manner of
half-assed version checks: works for 0.9.0, doesn't work for
0.12.3 (because lexically 0.12.3 < 0.9.0).
Fix by using proper version parsing and comparing the result of that.
See also: odoo/odoo#28116closesodoo/odoo#31553
Signed-off-by: "Xavier Morel (xmo)" <xmo@openerp.com>
The location_id and warehouse_id fields on product.template are just
dummy field intended to add something in the context that will be used
to compute the data being rendered (eg. for location, the quantity
displayed is the quantity of the product in the searched location).
But the feature was broken at a point, and has been solved in 11.0 with
7c7b099273.
This solution was not implemented in 10.0 up to saas-15 since this is
not acceptable for a stable version.
This changeset is only for 10.0 up to saas-15 to implement the fix
differently.
opw-1945417
closes#31475
Have a product that is an event, with the price of 1500.
Create a ticket for this product in an event, with the price of 600.
In a SO, add a line with this ticket.
Before this commit, when you change the tickets qty in the SO the price
change from 600 to 1500.
Now, the unit price stays the one of the ticket.
opw-1940368
In 187c32c2 some improvements were made for conserving/restoring group
bys on the pivot view.
This introduced an issue on the column group by:
- before reload, if we set manually a column group by (+ icon in the
header) it would be saved and not lost (unless a context or filter
in the search view override it)
- after reload, the following manually set column group by are not saved
anymore on subsequent reload (the column group by at the first reload
are set back)
This behavior is not normal since the behavior (conserving or losing
column group bys) should be the same at first reload or second reload.
The issue was caused by the duplication of group bys that were not
synchronized (one on the column root header, one on the pivot model
instance).
Without the change, the added test failed with: "Column groupby not lost
after second reload" and product_id is hidding from the object
pivot_column_groupby dictionary (having only "customer").
Using _.clone on initialRowGroupBys was necessary change because without
duplication of "groupbys", the initialRowGroupBys would be changed on
expandHeader which is unexpected.
opw-1941095
closes#31407
Nicolas Lempereur