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)
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>
Like every changes in web client, and in the assets composition, "some
people" forget to update the specific assets of livechat.
Specific livechat assets allow to load a small part of odoo js
framework in order to be embedded on external website.
Task-1919871
Task #1919871
Purpose
=======
If a visitor comes on the website and launches a livechat, it will be randomly assigned operator A.
If he comes the next day and opens a livechat again, we want him to have the same operator if he's available.
To handle that use case, we added a cookie that stores the "previous operator id" information for 7 days.
Task #1919871
Purpose
=======
The method 'get_mail_channel' in 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 active livechats. If multiple
operators share the same number (lowest) of active livechats, it selects randomly between those.
A livechat is considered 'active' if it has at least one message within the last hour.
Spec
=======
The assignation method should always give the new conversation to the operator who
has the less active conversation.
If two operators have the same amout of active conversation, it should chose one of
them randomly.
Purpose
=======
Several methods of the 'im_livechat.channel' model were passed a 'channel_id' to work on.
This has been changed so that the caller can use those methods on an instance of this model instead.
Some methods have also been switched to private because they had no apparent reasons to be public.
This is a preliminary cleaning for task #1919871
Specicial note for the "loader" template:
To load the livechat assets in a website page, the 'loader' template of livechat
is directly called (instead of being returned through a controller) in order
to avoid a new call to server.
As this commit moves 'sudo' to make method callable on the record directly, it
still needs to be sudo. First solution was to add the 'sudo' in the template, which
is a bad practise.
This commit creates a proxy method on website model returning the livechat info
with 'sudo'. This avoid having the 'sudo' done in template. Like always, explicit
is better than implicit.
Task-1919871
*: project, crm, maintenance, helpdesk,
It is useless to track fields during create since they
have no initial value and future tracking message will
show changes on tracked field.
We can log a default creation message instead
(as it is now if there is no mail_create_nolog context key)
This change will implies
- less queries when creating record
- cleaner creation messages
- less occurence of mail_create_nolog ctx key
Removing tracking at create could break the creation subtypes
mechanism (example: following task creation subtype on project)
Instead of using _track_subtype to give a subtype at create,
a new _creation_subtype method can be override. If a creation
subtype is set on a specific modlel, creation messages will be
create by message_post instead of _message_log.
We also need to adapt the message_track_post_template in order to
keep this feature whithout tracking.
Task: #1916916closesodoo/odoo#31945
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, a pricelist could be easily misconfigured when
multi-company and multi-website were both activated.
Eg: website 2 is for company 1, create a pricelist and set website 2 and
company 2, it would make no sense and code would not behave as expected.
Now, we prevent this type of misconfiguration by ensuring a pricelist can't
have a website which is from another company than the company set to the
pricelist.
We also filter website in m2o widget to only show company's websites.
Closes#25109
---------------
With this new constraint, l10n module would need to force company:
l10n modules install will change the company currency, creating a pricelist for
that currency. Do not use user's company in that case as module install are
done with OdooBot (company 1).
Step to reproduce:
- Active multi-company and create a new company
- Switch to that company and try to install any l10n module not in EUR or USD
- It will create a new pricelist for that company for that new currency
- It will crash as module install are done as OdooBot which is in company 1.
It will search websites in OdooBot company (self.env.user).
It will then create the pricelist with company 1's website which is
uncompatible with the new company, thus raising the constraint.
closesodoo/odoo#31929
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* website
Review the blog layouts to
- Use cards where necessary to match the forum / event redesign
- Use correct bootstrap / HTML
+ Some minor improvements
task-1948882
closesodoo/odoo#31749
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- No cards for menus
- Use the grid system for better blog post card footers
- Correct grid system for blog list grid view
- Remove some useless custom css
- Restore 'groups' in xml data
- ...
Part of https://github.com/odoo/odoo/pull/31749
task-1948882
Pierre Masereel