When a delivery carrier can't compute the delivery price, it returns an error
that is shown instead of the price (eg 'bpost Domestic is used only to ship
inside Belgium..').
But since 1ab53c27f everytime the user compute a carrier price and there is a
coupon allowing free delivery, every listed delivery carrier would have their
badges set to 'Free', including also carrier in error state.
This commit will not replace the error message by 'Free'.
Coming from #31857 (task-1867265)
This commit remove part of the condition as an empty jQuery element is always
truthy.
This commit is cleaning code to prepare the new feature to allow carrier prices
to be loaded asynchronously on cart.
See #31857 (task-1867265).
When displaying the followers of a document, followers who are set as inactive will be displayed in a different layout than the active ones. The purpose is to mark a clear difference between active and inactive followers.
Task #1957849closesodoo/odoo#32084
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The present work is part of an ongoing plan aiming to refactor/improve the reporting views (in particular the graph view).
The most notable changes are
- better support of comparison mode (comparison of different time periods)
- better tooltips and legend (content/style)
It has also been decided to use Chart.js instead of nvd3 to draw charts.
The main reasons are that Chart.js is better maintained/designed and offers many interesting features.
Thus we have rewritten all the code depending on nvd3, adapt it to the new library, and remove completely the nvd3 library and the references to it.
Task Ids: 1911201, 1946138
closesodoo/odoo#31766
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit is one part of the task 'removing nvd3'.
We use now Chart.js to draw charts. This makes old CSS rules
related to nvd3 useless.
Task ID: 1946138
It has been decided to use Chart.js instead of nvd3 to render charts.
In this commit the graph view has been largely rewritten to benefit
from the options offered by Chart.js.
Task ID: 1946138
This commit extends the support of comparison mode for the graph view
and refine the tooltips and rendering in line mode.
The graph view code has also been slightly refactored.
Task ID: 1946138
The commit https://github.com/odoo/enterprise/commit/19a144d6af2974e964c6487170e6bca1b14d3898 has
modified how libraries are loaded at several places and has
introduced a bug in sale_subscription_dashboard where the
libraries are no longer loaded at all. We fix that situation
by calling super in the willStart method of AbstractAction
that inherits from Widget. Abstract actions can now also
benefit from the mechanism present in Widget willStart.
Before this commit, the 'on_attach_callback' method of a subwidget of
the form renderer would not be called when the renderer renders
itself but is already in the dom. This can cause problems when a
subwidget has to know if it is in the dom for its own rendering.
This commit fixes that situation.
Before this commit the value of a field (of date/datetime type)
used as a groupby was not correctly formatted in the test environment
when the granularity was 'quarter'. This commit fixes that situation.
Old subwidgets of a widget inhereriting from BasicRender were not
correctly destroyed. This was the cause of various problems when
cycling over this.widgets.
In the previous commit the analytic entries generation when posting a
move was optimized to be done in batch. The performance is break
when sale module is installed. Indeed, in case of reinvoicing a
analytic line, AAL creation will trigger a sale.line creation.
This mecanism is very inefficient because
1/ AAL creation and Sales line creation are not batched
2/ sale line creation is done after the AAL creation, and then linked
with a `write` operation. So one `create` and one `write` per AAL to
reinvoice.
3/ To determine on which Sales Order to reinvoice, many `search` can
be performed per AAL.
Also, this looks strange that AAL creation might result into a sales line
creation.
This commit changes this in order to optimize and clean the code:
- the account.move.line (that creates the AAL) will also create the
Sales lines
- SO lines creation will be done in batch
- minimize the number of `search` done during the process
- the SO line will be linked to the AAL by passing the SO line id in the
create values of AAL (no `write` operation one AAL and SOL are created).
This was the last part of legacy code of 'sale_analytic.py' that we need
to get rid of. There are still work to do, but I think now, the
business case handled here can now breathe and have a peacefull life.
Task-1911898
closesodoo/odoo#28939
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
When posting an account.move.line, the ones with an analytic account set
will create analytic entries. As this is purely and simply data
generation,
they might be create in batch, using the new "create multi", in order to
perform only one INSERT query for all the lines to generate.
This commit aims to optimize the analytic.line creation by doing it in
batch.
Task-1911898
/!\ Cherry-pick of odoo/enterprise@8b85628c65 that was lost between
coupon move from OE to OC and forward-port
It is possible to setup multiple global promotions, i.e. 5% discount
after 5 products and 10% discount after 10 products. Buying 10 products
gives the 10% discount. But if you select 5 products (5% is applied)
then add 5 more products, the 10% discount is not automatically applied,
the custommer must remove the 5% discount in order to get the 10% one.
This commit automatically upgrades the promotion to use the best
applicable discount.
opw-1953224
closesodoo/odoo#32314
Signed-off-by: Christophe Simonis <chs@odoo.com>
website_sale_coupon was moved from enterprise to community just before a
forward-port bring changes to that module and before that module was removed
from enterprise.
- Store previous arch to be able to reset it (soft reset)
- Add the possibility to reset from file if possible (hard reset)
- Adapt frontend reset page to these new fields
- `arch_fs` hack to check if view was modified got moved to new field
`arch_updated` as we now need to keep track of the `arch_fs` to reset a
broken view.
Closes#32009 (task-1943001)
This commit also:
- adds the possibility to reset a view arch in its form view, including a diff
viewer (github like).
- adds string helper on those arch fields, as they are not documented, it is not
always obvious to get the purpose of each fields.
- adapts the font-size and headings to fit Odoo style on the error 500 page.
The error page does not use Odoo's assets, just bootstrap.css (the cursor
might be broken on the error 500 page so we can't use Odoo assets).
- raise the caller on unexisting t-call during QWeb rendering.
- adapts reset view code to single view as the code still had remains of its
initial release (Odoo 9.0). Handling multiple views has no sense anymore.
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Only the variant is using this code, so it was a bad idea to make the mixin
more complicated than it had to be.
Update the image tests to make sure this is working correctly. The test were
only testing the size of the images, now they also test the actual content.
Part of task-1949729
closesodoo/odoo#32253
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Reset view feature code still had remains of initial release (Odoo 9.0).
At that point all the view tree was returned, not only the broken view.
Since it has been fixed in 12.0 and refactored in saas-12.3 with this PR, it
now only takes the broken view as argument, handling multiple views has no
sense anymore.
Thus, this commit remove the (unused) multiple view compatibility.
This commit also add a test to test the refactoring or this feature.
Coming from #32009 (task-1943001)
Before this commit, when a t-call was calling an unexisting template, a QWeb
exception would be raised with the callee and not the caller as template.
That would be an issue since there was clean way to retrieve the view that did
the wrong t-call, for instance to be able to repair that view.
Now, in such a case the caller view will be returned.
That will avoid crapy code to retrieve the caller, eg searching on every Qweb
view archs.
Coming from #32009 (task-1943001)
- Store previous arch to be able to reset it (soft reset)
- Add the possibility to reset from file if possible (hard reset)
- Adapt frontend reset page to these new fields
- `arch_fs` hack to check if view was modified got moved to new field
`arch_updated` as we now need to keep track of the `arch_fs` to reset a
broken view.
Closes#32009 (task-1943001)
As there is a lot of arch fields, and those are not documented, it is not
always obvious to get the purpose of each fields.
This commit simply adds string helper on those.
It will be even more pertinent with the new reset view feature which adds two
new arch fields.
Coming from #32009 (task-1943001)
The error page does not use Odoo's assets, just bootstrap.css (the cursor might
be broken on the error 500 page so we can't use Odoo assets).
This commit mainly adapts the font-size and headings to fit Odoo style.
Coming from #32009 (task-1943001)
This commit is not needed (and not wanted) in saas~12.1 due to
07bef887af that convert field
`move_ids_without_package` to a computed field with an invert method.
The invert method writes on `move_lines`, which will recompute the value
of `weight` field correctly.
This reverts commit b2b395467f.
next_activity broken by a previous refactoring of js.
date picker broken by bs4 and JS don't handle local format.
closesodoo/odoo#32263
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Purpose
The assignation method should always give the new conversation to the operator who
has the less active conversation.
If two operators have the same amount of active conversation, it should chose one of
them randomly.
We also want the visitor to get the same operator (if available) from its last visit.
Specifications
The method 'get_mail_channel' on the 'im_livechat.channel' model used a simple random.choice in
the available users to select the operator.
It was improved to select the operator that has the lowest number of open livechat sessions. If multiple
operators share the same number (lowest) of open livechat sessions, it selects randomly between those.
For the visitor to get the same operator as during its last visit, we save that information in a cookie (1 week lifetime), and give this optional parameter to the server when asking for the livechat session.
To make the code clearer, some methods were reorganize and convert from `api.model` to `api.multi` (ensure_one) to be more API-compliant.
Task-1919871
closesodoo/odoo#29888
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Romain Derie