Before this commit, creating a leave for multiple employees
from the manager's page allowed to create leaves regardless
of the concerned employee's allocations.
After this commit, an error message will be displayed to inform
which employee cannot take that leave.

Also removes unused imports.

task-2995120

closes odoo/odoo#103729

X-original-commit: 636a8276e6797c1d8fe43da61d2fd26b558bfa45
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Part-of: odoo/odoo#102438

closes odoo/odoo#100573

Related: odoo/enterprise#31507
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Probem:
With some time off type as default type in an allocation request
you get a traceback as soon as you try to open the allocation
request form.

Cause:
FIX commit [1] introduced the issue as it didn't consider the
possibility of a false date_from

Improvement 1:
Having a date_from False sets a False in the leave request name
displayed on the form, we change that to have an empty string
instead

Improvement 2:
The timezone bug fix in commit [1] is only applied on a specific
configuration, we applie it to all configuration of leave request
name

[1] 5a50dea2652cff014d9198f59265cf36a3ec1865

opw-2961344

closes odoo/odoo#99454

X-original-commit: 3b9a012e4a0839bc5da2daf51d56591d2863b4be
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>

odoo/odoo#96545 added an extra query - the query count needs to be bumped.

closes odoo/odoo#98348

Signed-off-by: Kevin Baptiste <kba@odoo.com>

As part of hr_holidays B2B, the holidays allowances were moved from hr_leave_type to hr_leave_allocation.
This didn't allow to take a leave longer than the maximum duration of an allocation. Also, despite all the
allocations could have enough days for a certain leave, it was not possible to use all available days without
splitting the leaves across the different allocations.

This commit moves the holidays allowance to the hr_leave_type to remediate the issues described above.

task-2834887

closes odoo/odoo#98317

X-original-commit: 8c37d5c7cc397e517c43c1ec13a131b4b35e48b7
Signed-off-by: phwa-odoo <phwa@odoo.com>

closes odoo/odoo#98058

X-original-commit: 6fd3c6640c3bb15ce181b14119aec7c2d851cf1d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
   fields having a tooltip in the future UI.
4/ some cleanup of existing messages too

The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX

closes odoo/odoo#97279

Signed-off-by: Fabien Pinckaers <fp@odoo.com>

closes odoo/odoo#95556

Related: odoo/enterprise#29247
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

In module mail, invalidating 'message_ids' on a mail thread also
invalidates its inverse field 'res_id' on messages.  If you haven't
flushed it before, your cache will be inconsistent, as shown by the test
/mail:TestMailgateway.test_message_process_bounce_records_channel.

In module purchase_stock, add depends on report.stock.quantity.  This
ensures that when the model is queried after changes in other models,
the data on which the SQL view depends is flushed to the database before
querying that model's table.

closes odoo/odoo#66938

Related: odoo/enterprise#16722
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>

closes odoo/odoo#94885

X-original-commit: 77c0dc3eb75b568b4e6aab9bc26f6e5b5f0f8d4b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Purpose
=======

Currenlty an error is raise saying that a leave cannot be set accross
overlapping contracts.

But in this special case we could split the time off and allow this simple
action.

Taskid: 2836901
X-original-commit: 1012a7ea8033675b6ebab96922e124b04e5ed884
Part-of: odoo/odoo#94885

Purpose
=======

We currently prevent leaves overlapping several contracts to avoid messing
with the generated resource.calendar.leave.

In case the contracts are on the same resource calendar, this shouldn't be
an issue actually.

Taskid: 2836901
X-original-commit: 4e87c30bb136083153091e67e6dd9d9f64fa94c2
Part-of: odoo/odoo#94885

Prior to this commit if work entries/payroll was installed you could not
cancel a time off in the future if the work entries were generated for
that period, however you should still be able to cancel a time off as
long as the work entries have not been validated yet.

TaskId-2791386

closes odoo/odoo#94165

X-original-commit: 975ac8d2a1809bf7725d577b0fa9143a5b255e0d
Related: odoo/enterprise#28673
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

closes odoo/odoo#87527

Related: odoo/upgrade#3497
Related: odoo/enterprise#26939
Signed-off-by: Raphael Collet <rco@odoo.com>

Prep work to allow work entries to be created from multiple sources when
using contracts.
The end goal is to be able to generate work entries from attendance as
well as the planning app.
After that the plan is to make sure the implementation works well with
payroll for hourly wages.

This commit contains the necessary changes for the next work_entry
modules to work.

TaskId-2466871

Remove most values uselessly specified because giving the same value as 
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)

* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default

This will reduce noise/inconsistencies between manifests specifications, 
simplify analysis of manifests content, ...

closes odoo/odoo#90209

Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

When creating a global time off in one resource.calendar A , it will be
propagated on any new resource.calendar B.
However the reverse is not true, if I delete the global time off in
calendar A it will not be deleted in calendar B.
During the work entry generation this is not taken into account, a
contract using calendar A will generate leave work entries because of
the global time off in calendar B.
This is due to a change in PR odoo/enterprise#15091.

The domain is now correct and will only fetch the right leaves.

TaskId-2627378

closes odoo/odoo#88725

X-original-commit: 0bac1d33a25e37ebece69de030b9fd72caa43a02
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

In 2685472 new computed fields were added in calendar_event. This commit
updates the query counter tests that were failing.

task-2685472

closes odoo/odoo#79654

Related: odoo/upgrade#3182
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

X-original-commit: ae165f48178d89ad1b74961c7d4829f1ff5ca0c4

There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.

The report rendering and call `ir.qweb` instead of `ir.ui.view`.

Part-of: odoo/odoo#85110

Prior to this commit, the multi company rules were bypassed due implicit
sudos (compute_sudo and self.env.user).
The function computing the number of days will now make sure to include
the right domain.

TaskId-2791030

closes odoo/odoo#86361

X-original-commit: dbcb37ec
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Purpose is to update counters according to current runbot's state. This eases
checking impact of future performance improvements done.

Task-2631088 (Appointment: profile and add performance tests)

closes odoo/odoo#85838

X-original-commit: b0c7a6397526ad2698fac0701e4323c019ea8bf6
Related: odoo/enterprise#25002
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases

closes odoo/odoo#84908

Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>

Notably after odoo/odoo@f9442f47eb2d6e1d2e3e9fac39e503f0aa86e333 query counters are heavily impacted
and a lot of them has lessened.

closes odoo/odoo#83832

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Issue
-----
Via the field prefetch mechanism, when we need a value of one field
(not in cache of course), the ORM will prefetch all fields
(which has the attribute to `prefetch=True`, the default value of this
attribute is `True`) for all record ids in `_prefetch_ids`.
Then, for each translate fields (where translate is not a callable)
the ORM need to make a `LEFT JOIN` on the `ir_translation` to fetch the
translated value. For big model, it leads to a simple `SELECT` with
several `LEFT JOIN` on ir_translation but each LEFT JOIN have a cost
in the planner time (a small cost in the execution time) of PostgreSQL.

By example, for `product.template` (stock/sale/purchase installed),
there are 6 LEFT JOIN to get all translated fields (5 of this
fields are rarely used).

Proposed solution
-----------------
Deactivate the prefetch by default for all translate fields expect if
this field is the `_rec_name` of the model (which is more likely to
be used).

In the example on the `product.template`:
Without prefetching the translated fields, there is only one LEFT JOIN
(the name, which is translated but is the `_rec_name` of the model).
With the 6 translated fields to fetch, the
query takes 5 ms to plan and 2 ms to execute VS with 1 translate field,
it 1 ms to plan and 1.5 ms to execute.

Side change note
----------------
- All translate of fields of `website.seo.metadata` should be prefetch
to avoid lot of website errors (it is because, website put in cache data
in sudo before reading it without sudo)
- `description` (`mail.message.subtype`), `subject` (`mail.template`),
`body_html` (`mail.template`) should be prefetch to avoid lot of extra
query from mail module.
- `vat_label` (`res.country`) should be prefetch to avoid a extra query
for each website page.
- Increase some queryCount (when it is legit, due to `subtitle` of
`blog_post` or `description` of `event.type.ticket`, etc)

task-2738029

closes odoo/odoo#82896

Signed-off-by: Raphael Collet <rco@odoo.com>

closes odoo/odoo#83410

Forward-port-of: #83278
X-original-commit: db203ae7a6eee715fbc32939c5e38457cee7762a
Related: odoo/enterprise#23755
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Some demo data have been added on the planning module.

task-2677949o

closes odoo/odoo#80439

Related: odoo/enterprise#22536
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

Description of the issue/feature this PR addresses:
In hr_holidays, there is no information about the conflicting time off when a second time off is scheduled at the same time.
There is a validation error saying "You can not set 2 time off that overlaps on the same day for the same employee".
The validation error should display the conflicting time off

Current behavior before PR:
The validation error displays the following:
"You can not set 2 time off that overlaps on the same day for the same employee"

Desired behavior after PR is merged:
The validation error will display the following:
"You can not set 2 time off that overlaps on the same day for the same employee.
Existing time off: Mitchell Admin / Trip with Family : 24.00 hours / from 06/09/2021 to 08/09/2021 / To Approve"

task-2641682

closes odoo/odoo#76452

Related: odoo/enterprise#22490
Signed-off-by: Kevin Baptiste <kba@odoo.com>

closes odoo/odoo#80181

X-original-commit: efd178da
Related: odoo/enterprise#22439
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>