1. Methods associated to touchmove and touchstart listeners should not
call preventDefault because they are passive by default. Calling preventDefault
will do nothing but in chrome browser, error message is issued.
2. We now allow resize based on touch events.

closes odoo/odoo#54612

X-original-commit: c6b7133d9c9dc52a8d283124b5a4497940e54682
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

The primary goal of disableRubberbanding is to disable scrolling during
touch event by default and to allow only selected descendants to have scrolling
active during touchstart+touchmove event. Only elements with class="touch-scrollable"
are allowed for touch scrolling. This restriction can be a good idea but it
results to bug-ridden explicitness which is not necessary because scrolling
should be allowed automatic by default in the first place. In this commit, we
allowed scrolling by default by:

1. We remove disableRubberbanding.
2. We set the position property of .pos to fixed. This is to accomplish the
original goal of disableRubberbanding (fixing the root element in its position).
3. We remove the touch-scrollable class as they are not needed anymore and
no style associated to it.

Removing the disableRubberbanding method also fixes the Intervention error during
touch scrolling event. The reason for that error is we are calling preventDefault
in the event that is passive. touchmove and touchstart events are passive by default
- which means that preventDefault won't work.

X-original-commit: 54f7fb49dae3aab6a005402a1ac60262bbd15edc

After the commit 2a57a156
Cloc excluded by default one more folder, it should appear
in the documentation of the tools

closes odoo/odoo#54609

X-original-commit: 93261c78
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

This allows user to close multiple windows with ESC key.

task-2283891

closes odoo/odoo#54604

X-original-commit: bac3d7792a48f86a39f92e0fcfc18d522ce00d94
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

odoo/enterprise#11836
task-2296875

closes odoo/odoo#54600

X-original-commit: 687628fa35063db5b44abcc758cae0a597df5ffe
Related: odoo/enterprise#11904
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Before this commit, try to post a comment will raise a traceback in front end
because textarea is not found.

Now, we check that we are writing in textarea content and no more in textarea
comment.

closes odoo/odoo#54595

X-original-commit: 867458456b13daf9b5586c17b7475e68d9d008e1
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

task-2280146

closes odoo/odoo#54599

X-original-commit: 3114c7dab3c7f0f63e59f01fd06237fdc109203a
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Limit must be 70 not 71

closes odoo/odoo#54587

X-original-commit: 7d808675
Signed-off-by: Josse Colpaert <jco@openerp.com>

Adding additional product to a production but consuming 0 on it will
trigger the consumption warning wizard while no difference with the bom
are occurring. This commit do not trigger the consumption issue in that
case.

Task : 2278147

closes odoo/odoo#54561

Related: odoo/enterprise#11885
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

On a MO which product_id has a serial tracking, some components and 2
or more WO:
The method _set_qty_producing of a WO will call the MO _set_qty_producing
method even if no changes is made on qty_producing which can produce an
undesired aditional move line when creating the MO.

On a MO which product_id has a serial tracking and some components:
Changing the qty_producing on a MO was adding a line on the component
move.

Since the _set_qty_producing method is called when creating a WO it sets
the qty_producing of the MO to 0. As it does not make sense to have a WO
set the qty_producing of a MO to 0 we will not replicate it.

task-2278147

closes odoo/odoo#54579

X-original-commit: ca8275aa28010b73cad14f667068e9cfc6c651a5
Related: odoo/enterprise#11896
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

_set_quantity_done_prepare_vals is call to (re)create move line
during some onchange/compute. But it never removed empty line.
Then remove empty line (when no reserved quantity and no done quantity)

task-2278147

X-original-commit: a1ab74d6cd75cee64fcd432d387180299fd64c72

The tests must be only imported in a test context, not in a running
context.
Since 92a7f8c1 a new test requirement was added but it should
not be necessary to run a module, only to execute the tests.

closes odoo/odoo#54578

X-original-commit: 15f2bbd4
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Since recordsets are self-recursive, they should be treated like
strings (where iterating a string yields a string, infinitely) in case
somebody happens to return a non-downgraded recordset from a method.

closes odoo/odoo#54572

X-original-commit: 6d88845f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Improving field's string to make it alignes with all other fields in
Odoo.

closes odoo/odoo#44055

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Before this commit:
If a template_id is put on the first stage, a partner is
automatically created at the creation of the applicant. And if the
applicant had a phone or a mobile, they are removed.

After this commit:
The phone and mobile are saved on partner and not removed from
applicant.

taskId 2299970

closes odoo/odoo#54574

X-original-commit: 3735c3363f422d01ae1ff96e761a1b206fc32a69
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: jbm-odoo <jbm-odoo@users.noreply.github.com>

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

closes odoo/odoo#54444

--task: 2296213
Related: odoo/enterprise#11833
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2296213

Also, this commit fixes the usage of the 'invoice_policy' field in test that is introduced by the 'sale' module.

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2296213

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2296213

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2296213

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2296213

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2296213

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2296213

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2296213

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2296213

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2296213

If a test is supposed to be run with the Belgium CoA, we expect the company is created by default with the EUR currency.
Before this commit, the currency of the company was replaced by the current company's one: USD (most of the time).

The tests must be only imported in a test context, not in a running
context.
Since 92a7f8c1 a new test requirement was added but it should
not be necessary to run a module, only to execute the tests.

closes odoo/odoo#53628

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

At bee938e0 (following task-id 2042303), the label of the action was
changed globaly.
The action is however shared with multiple menus like Inventory Report.
The Update Quantity label only makes sense when coming from the
product where the quantity will be updated.

Closes odoo/odoo#50523

Before this commit, calling `mapped()` on a relational field of a single
record inside a for loop does not correctly propagate the prefetch ids
from the bigger recordset down to the record inside the loop:

    [rec.line_ids.mapped('name') for rec in recs]

To be more precise, `recs` correctly propagates prefetching information
down to `rec.line_ids`, but method `mapped()` does not pass it along to
the record that triggers the prefetching.

This resulted in one query per record in `recs`, so if `recs` were a
1000 records recordset, at least 1000 queries would be necessary.

With this commit, the `mapped()` function correctly propagates the
`_prefetch_ids` of the larger recordset (`rec.line_ids`) so that the
prefetching works properly and the 1000 queries are brought down to 1.

This commit is a followup on #42611.

closes odoo/odoo#54565

X-original-commit: 0e97053fee36c0c76b70cb94be5340c3144b178b
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>

odoo/odoo#53938 improved the SQL linter and used psycopg2.sql to
silence the linter where that still made sense. However I forgot to
mark table names (pretty much exclusively) as `sql.Identifier` in a
few somewhat rare callsites, which consequently break when invoked as
a simple string is not a Composable and psycopg2 therefore rejects it
when composing the query.

closes odoo/odoo#54556

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

opw-2265631

closes odoo/odoo#54548

X-original-commit: c029bfeb3e04b5b314663db34db0a56b6165a6b7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

revert of 0f4ec369 and bf8a9af1

- Employees > Configuration > Planning Types and ensure the activity
    type "To Do" is set to scheduled date several days after previous
    activity (default should be 5 days);
- Check that onboarding Plan has at least 2 activities with activity
    type "To Do";
- Click launch plan.

The activity type configuration is ignored and all activities are due
tomorrow. The previous commit uses the function
_onchange_activity_type_id to fix this issue.

The problem with this commit, is that the _onchange_activity_type_id
function will also change the responsible, the notes and the summary to
set them to their default value.

Now, the activities are due taking into account the activity type
configuration without modifying the already set responsible, notes and
summary.

opw-2265631

X-original-commit: 81e4745a31567af7b58064bd8b4e9bae0756354f

Before this commit, only the users with timesheet 'Administrator' rights
can see the Timesheet button in the employees view.

Now, the users with timesheet 'See all Timesheet' rights can see the
Timesheet button in the employees view.

This is the behaviour in version 12.

opw-2285695

closes odoo/odoo#54543

X-original-commit: c839ecda
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

Once global "Accept" button is clicked, the accepted messages were not
unchecked causing the button to stay hidden until next page reload.

task-2285430

closes odoo/odoo#54549

X-original-commit: 5594de16f463507498e852c2d49d1cbe74ed7381
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

An onchange method can remove an existing line from a one2many field of
a new record with command 2, such as:

    move.line_ids = [(2, <NewId origin=42>), ...]

The processing of the command 2 above incorrectly tries to remove the
new line from the origin record, instead of the new record.

closes odoo/odoo#54545

X-original-commit: 7d138a44
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

The layout of the split bill screen is broken after the responsive pos ui.
This fixes the split bill screen and make it also responsive.

New classes are introduced because reusing proved to be very difficult.
One benefit of declaring a new classes (then styling them) is that we can
target the particular elements that we wanted to change without the concerns
that another elements are changed.

closes odoo/odoo#54529

X-original-commit: 51f0c6a1be912192d910d47b79ac2cb3c5b42784
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

-Purpose of this task is to make the unique model name constraint
 clearer by specifing name of the model needs to be unique.

-In this commit, change the constraint message from
 'Each model must be unique!' to
 'Each model must have a unique name.' to let the user know name
 of the model causes the issue.

task-2254964
Closes-#51513

closes odoo/odoo#51513

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

filtered(lambda c: c.channel_message_ids)
take more than 2 minutes to get executed with a regular user
due to access_right check for every single message.

Solution:
use the previous read_group with the domain channel_message_ids != False
which is equivalent

closes odoo/odoo#54318

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

task-2291887
task-2291893
task-2291898

closes odoo/odoo#54531

X-original-commit: 26170ad9ab09d75de2e0af98fb7daedc2ed57e50
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>