PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements. Purpose is
to improve count performances (meeting count, applicant count), ... by using
a read_group and maybe adding missing indexes.
LINKS
Task ID 2196182
PR #44662
Related: odoo/upgrade#973
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements. Purpose is to
improve forum.post child_count performance.
LINKS
Task ID 2196182
PR #44662
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
There may be a lot of clicks linked to a given link tracker. Compute the count
of clicks in batch with a read_group to improve performance.
Same for utm campaign mailing count performances.
Some missing indexes are added to speedup queries.
LINKS
Task ID 2196182
PR #44662
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements. Purpose is to
improve meeting count performances.
An index on applicant is also added to speedup queries.
LINKS
Task ID 2196182
PR #44662
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements.
Purpose is to improve lead_count performance. Some people claim to gain a lot
of queries: from 90 to 30 SQL queries to read 39 partners. Hard to reproduce.
LINKS
Task ID 2196182
PR odoo/odoo#44662
Co-Authored-By: Fabien Pinckaers <fp@odoo.com>
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
In v12, the hr module did not have a hard dependency on mail_bot, so the users could uninstall it if they did not want/need its functionality. In v13, mail_bot was added as a dependency to include the notification widget and the odoobot state in the user forms modified by the hr module. However, this also brings potentially unwanted functionality to anyone who installs an hr related application.
This commit removes the dependency on mail_bot by adding the mail_bot_hr bridge module, which has the odoobot state field and includes a dummy notification widget.
Additionally, the automated answers from OdooBot like "Pong" that fill the chatter and annoy many users have been removed.
Task ID 2200878
closesodoo/odoo#48521
Related: odoo/upgrade#1089
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when there is promotion with usage Automatically Applied
and creating quotation without reward line but on copy of that order
the reward line will be added even the original quote did not have the
reward line(discount).
So in this commit, on copy of the sale order, unlink and apply reward
line only if origin sale order has the reward line.
TaskID: 2228249
OPW-2227968
closesodoo/odoo#49798
X-original-commit: 88aae85cafaeec763a05f49003aff5d593a8922d
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Co-authored-by: Mahendra Barad <mba@odoo.com>
Co-authored-by: Rushi Sathawara <rus@odoo.com>
Currently in kanban view which contains search panel when user click
on kanban dropdown menu then a dropdown menu will be hidden due to
scrollbar of kanban view.
This issue arises from this commit:
https://github.com/odoo/odoo/commit/a95cbbd631a2fa9be62eb42cba43e853fdf4b789
closes odoo/odoo#49791
Task-id: 2204306
Closes: #47586
X-original-commit: d613bb8ba4f5a4d818592a80f4aee2ef67916bc0
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- install website
- install the theme "clean"
- go to website > customize > customize theme
- select the first "extra color" (alpha) and change it
Previous behavior:
All extra color that have not been set previously have changed
automatically without notice
Current behavior:
the theme is either showing primary/secondary colors or only "extra" colors
Good themes are supposed to enforce primary = alpha and secondary = beta
All extra color that have not been set previously change automatically but
an information tooltip shows up when you hover alpha to avoid confusion
opw-2180611
Forward-Port-Of: #46099closes#49730closesodoo/odoo#49789
X-original-commit: c9aada53b1e6b24da4e1fe9ac4d44db3ff8cacda
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
For some specific report (i.e account followup report) the mail_message
sent will contains no company informations because it will be sent on
the partner context, so when generating the template the logo will be
retrieved from the route /logo.png?company=False which yield back the
odoo company logo.
Adding a default 0 allow to retrieve the company logo for the current
user
opw-2232184
closesodoo/odoo#49787
X-original-commit: eea99fe1e00eb2dbd2bbeaca3e2f09845b426267
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Impacted modules:
hr, hr_contract, hr_recruitment, hr_payroll, fleet, hr_skills, hr_appraisal, ....
Several onchanges have been converted to computed fields in the following modules :
Community :
- hr
- hr_contract
- hr_recruitment
- hr_work_entry
- hr_maintenance
- hr_expense
- hr_expense_check
- hr_holidays
- sale_expense
- account_analytic_default_hr_expense
Enterprise:
- hr_contract_salary
- hr_referral
- hr_payroll
- hr_payroll_expense
- test_l10n_be_hr_payroll_account
There are still 2 onchanges with complex behavior that couldn't be converted easily:
- an onchange that updates "tz" (timezone) that is defined as a related field
to "resource_id.tz". Apparently it is useless except to initialize the default
value of "tz".
- an onchange that updates "name" that is defined as a related field to
"resource_id.name".
the applicant.
closesodoo/odoo#45414
Taskid: 2169099
Related: odoo/enterprise#8572
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the 'selection' fields were treated like 'char' fields in the
"Add Custom Filter" menu of the control panel's filter menu. This meant that their
value was defaulted to "".
Now, the default value of a selection field is its first selection value.
closesodoo/odoo#49772
X-original-commit: 62b62570725bc8eb3d3fa77fd1e8efd7a4fb5d2b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Purpose
=======
Avoid to show to much information to leave responsibles.
Specification
=============
- Dynamically add/remove the leave_manager_ids on the group
group_hr_holidays_responsible, on employee creation/modification
- Retrict the available employees when creating a leave. For
manager/users : Everyone. For responsibles: The employee for
who the user is responsible. Otherwise: Only me.
- Don't obfuscate the leave name on employees for who I'm the
responsible.
- Add a new SQL view for "Everyone" report. To select only the
information we want to share instead of showing the hr.leave
model directly.
closesodoo/odoo#47659closesodoo/odoo#49765
Taskid: 2206862
Related: odoo/enterprise#9239
Related: odoo/enterprise#10021
X-original-commit: 781147dcaf1552b8f2ab687ed73034b8fd1f7352
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Or, in other words, set auto probability to 0 if no statistics yet.
Before this commit, if the automated probability could not be computed,
the automated_probability field on crm.lead was not modified.
That led to having leads stuck at 100% once won, even if going back to another
stage.
This happened only :
- in an empty DB (no demo data) or
- in a DB where the PLS cron had never ran and the PLS threshold was
inactivated (=0).
Because, if the frequency table has never been built, we cannot compute the
automated probability.
After this commit, if the automated probability cannot be computed, we set
it by default to 0. If the probability and the automated probability was
aligned, probability is also set to 0.
Note: this could be an issue if both probabilities were aligned, then
someone deactivate the PLS cron and set the threshold to 0 (if not yet the
case), and clear the frequency table. (unlikely to happen but still..)
When updating updating a lead, we would lose the probability
-> auto proba set to 0 + proba set to 0 as they were aligned.
Task ID: 2232036
closesodoo/odoo#49766
X-original-commit: b43ecf73958273a126135966422112b90f9f12cc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to clean test that broke nightly recently.
Task ID
closesodoo/odoo#49759
X-original-commit: 61f9b05ccc61a7e00dc5cc43cb1f8196195bee60
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
According to some PO, the email is useless to salespersons.
According to salespersons, the email is very useful.
This reverts a26a010324
opw-2215123
closesodoo/odoo#49756
X-original-commit: 0709890357005e4c1b205816061c3ec1582ad16d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider the customer invoice journal J with the default credit account A1
- Let's consider a customer invoice I with one line L1
- On L1 is set account A2 and product P1
- Import on I a new line L2 with account A3 and product P2
Bug:
The account of L1 was changed by A1 instead of keeping A2
opw:2230808
closesodoo/odoo#49582
X-original-commit: 115a18a1cdecdc6d76920efdf323fb91f2f408ee
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Issue
- Install Dashboard & Sales
- Add a graph & a list to the dashboard
- Go in the dashboard
Rendering ok
- Click on a list item
- Go back with the breadcrumb
Traceback
Cause
When going back with the breadcrumb
we retrieve the previous view controller.
https://github.com/odoo/odoo/blob/9400059073d7401789eb1a60d6a0ec6f58dfc66b/addons/web/static/src/js/chrome/action_manager_act_window.js#L457
By restoring the board controller, we
restore all the subcontrollers too.
But the actual board renderer is re-creating
controllers. This creates inconsistencies
with the view.
Solution
Remove the restored controllers
OPW-2232713
closesodoo/odoo#49728
X-original-commit: 4f3d818052d689da762d8afbf1789daaa3d39821
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Consider a sales order with a single line. Edit the sales order: remove
the line, and add another line with the same subtotal. When saving, the
total of the sales order is 0.0.
Here is the explanation: the form view performs a `write` on the sales
order, and modifies the lines with a command `2` (remove line) and a
command `0` (create line).
After deleting the first order line, the cache is emptied, and a call to
`flush()` forces the recomputation of the total. The value is computed
to be 0, and assigned to the field. The assignment converts the value
for the cache, without prefetching the currency field (optimization),
and puts 0.0 in cache. The assignment then converts the value for the
database, which prefetches most fields on the sales order: the cache is
now inconsistent and contains the old value V, while the database is
then updated with 0.0.
After creating the new order line, the total is once again recomputed.
Its value is V, and because the cache also contains that value, no
update is performed to the database, which remains at 0.0!
The fix consists in avoiding the prefetching of fields when accessing
the currency field to round a monetary value.
opw-2223134
closesodoo/odoo#49741
X-original-commit: 048ea2f20a0a2fa6d629cbe262cbbe765248d36f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
During the onboarding, if Invoicing is installed but no chart of account
is set the field property_account_receivable_id and
property_account_payable_id prevent from validating a new partner
because they are required but not auto-filled, and the fields are not
visible if Invoicing is not installed.
closesodoo/odoo#49732
X-original-commit: 29c362b7c3353c2be11ab117f454d04ed9853f75
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
It is now possible not to format integers according to locale
This is particularly interesting and relevant when a number holds
some sort of code rather than a number
Task 2050119
*: base, fetchmail, l10n_cl
closesodoo/odoo#39767
Related: odoo/enterprise#6964
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit introduces a new option in fields inheriting from type Numeric
which is `format`.
By default, Numeric fields are formatted according to their subtypes and locale
Adding, in a view, the option format set to a falsy value
will prevent the field's value from being formatted.
```
<field name="int_field" options="{\'format\': false}"/>
```
Task 2050119
Before this commit, the SearchPanel widget was given a single unified domain coming
from the view/controller. The issue was that some modules injected additional leaves
in this domain and there was no way to remove them/separate them from the original
view/controller domain.
Now, another paramater (the `viewDomain`) is given to the SearchPanel, containing
the distinct domain related to the view. The Lunch module has been adapted to give
the `location` domain through this new key.
Note that some tests steps had to be inverted since the method retreiving the
domain of the view/controller is asynchronous (needed by Lunch to give time to the
model to be loaded). It mainly concerns the RPC order which does not matter in this
case.
Task 2239706
closesodoo/odoo#49720
X-original-commit: e895e553899933be14c8abfd8c676b44a7f534d8
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Many users have complained about the automated OdooBot answers like
"Pong" when the bot is pinged, that fill the chatter when the user has
the mail_bot module installed, and add no real value.
In v12, the hr module did not have a hard dependency on mail_bot, so the
users could uninstall it if they did not want/need its functionality. In
v13, mail_bot was added as a dependency to include the notification
widget and the odoobot state in the user forms modified by the hr
module. However, this also brings potentially unwanted functionality to
anyone who installs an hr related application.
This commit removes the dependency on mail_bot by adding the mail_bot_hr
bridge module, which provides integration between mail_bot and hr if
both modules are installed.
Before this commit, pricelist boundaries were dates. It was not possible to get a modified price at a precise time: e.g. modify the formula at 12h00.
closesodoo/odoo#49030
Taskid: 2221094
Related: odoo/upgrade#1055
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The purpose is to have more common code for failure and notifications, with less
override in `sms` and `snailmail`.
task-2176017
closesodoo/odoo#44170
Related: odoo/enterprise#9140
Related: odoo/upgrade#918
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Have a static template of the form:
```xml
<div t-name="ComponentA">
<ComponentB title="no export" />
</div>
```
To be used by OWL (github.com/odoo/owl)
In this context, the title in the attributes of ComponentB
should not be considered as *the* title attribute of HTML
but as a sort of variable declaration
Before this commit, the string contained in the value of this
title attribute was exported. It was not translated at runtime,
but we want to export as less stuff as possible in PO files
So, after this commit, none of the attributes held by a OWL directive
are exported
This commit relies on OWL Syntax, which makes mandatory
for a component directive's first letter to be capitalized
https://github.com/odoo/owl/blob/master/doc/reference/component.md#composition
Also, it relies on the good practice and widespread convention to have
every HTML node lower cased
https://www.w3schools.com/html/html5_syntax.aspclosesodoo/odoo#46191
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit removes the unnecessary usage of `signature` instead of
`unique` in the route params for `web/image`.
closesodoo/odoo#48437
Related: odoo/enterprise#9501
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This commit makes so that we also fetch the checksum of the attachments
of mail.messages to use it for cache control.
Before this commit, the urls of message attachments had
`undefined` for the signature parameter.
Creating New records for account.payment from Grouped kanban should not be allowed as they are not consistent and Leads to error. (Eg, Try to create New Payment when grouped by State, Add new Column when grouped by Journal)
With this commit, We disable the creation of new Payment/Relational records from this view.
closesodoo/odoo#49619
X-original-commit: 6774f9cfe768e5cffce4cfd458910af450ef7616
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Steps to reproduce:
- install calendar and dashboard
- go to calendar > favorites > add to my dashboard
- go to dashboard
Previous behavior:
the calendar view in the dashboard does not show the main widget
because height is 0px (because the structure is different that normal
calendar view where view height is restricted based on viewport).
Current behavior:
calendar views are properly displayed in dashboard
opw-2226565
closesodoo/odoo#49709
X-original-commit: d1218004aa0b4a1840c99346baef73bc5fbb90a1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
Use `float_compare` to avoid the usual float representation comparison
errors.
opw-2215497
closesodoo/odoo#49702
X-original-commit: 500240874cd21c6950210968c8c7e8d84c1c4bee
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There's a traceback when we edit an activity on a campaign
* Create a child activity
* Save the activity (not the campaign)
* Edit again the activity
* -> Traceback
Introduced in a9cebd5
Task ID 2220930
closesodoo/odoo#49698
X-original-commit: efa8952c39b0bcb0969013dc22e05b5d61ff1c66
Related: odoo/enterprise#9964
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Go to the calendar list view
- Click on 'Create'
- Tick 'All Day'
- Set a start date
The end date is set to the day before.
This happens because in this case, the default duration is zero.
opw-2236766
closesodoo/odoo#49682
X-original-commit: 0b6ae3ed4ff20898cd88b97a644190b20f11cf8f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When creating or writing on a account.journal model,
it is possible to pass a char representing the bank account number
into bank_acc_number instead of passing directly a res.partner.bank.
In case we pass bank_acc_number the system will try to create automatically
a new res.partner.bank for us, however if a res.partner.bank already exists
with the same account number it will result in an error as we have a unicity
constraint for that. Therefore it is best to first seach for such an existing
res.partner.bank before trying to create it. The search is done on the
sanitized_account_number field as the unicity constraint is on that field.
closesodoo/odoo#49637
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
PURPOSE
Clean mail alias mixin use through addons and clean its code
SPECIFICATIONS
Remove unnecessary code overlap: duplicate of model computation
or alias definitions.
Remove alias creation relying on context and instead give a single
method to override giving alias creation values.
Go through all addons using aliases to clean its usage code.
Remove remaining alias fields on res.users, linked to a now removed
feature.
Finally make alias creation work in batch mode in mail_alias_mixin.
LINKS
Task ID 1919277
Community odoo/odoo#41160
Enterprise odoo/enterprise#6983
Upgrade odoo/upgrade#872
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to allow multi-create in alias mixin by correctly
creating / updating aliases in batch.
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Clean the usage of mail aliases and more specifically its associated mixin
`mail.alias.mixin` .
Stop using context for model of aliases, and correctly give model_id and
parent_model_id to the call chain through a cleaned code easier to override.
We also merge methods get_alias_model_name and get_alias_values in single one
called before record creation (alias first values) and right after (to have
values depending on actual record).
LINKS
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Purpose of this commit is to clean manual alias creation by correctly giving
field values instead of relying on magic from model_name to model_id. Code
is more understandable now.
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Denis Zhadan