A term was present twice in Italian, making the installation of
Italian crash for the Swich CoA
Introduced at a3029a8c

Remove some reference to company accounts (it is handled by
l10n_multilang, should not be set manually as working only for company
wiht id 1)

closes odoo/odoo#54658

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

This commits fixes the case where you click on
edit address in eCommerce payment flow and you
type a wrong coupon code.

Without this commit, you are redirected at
/shop/payment instead of /shop/checkout

OPW-2290188

closes odoo/odoo#54646

X-original-commit: 0d658349
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>

Improve tooltip style/design to get rid of black background and purple title,
instead design tooltip like popover design, to have tooltip with white
background and light grey title

task-2266829

closes odoo/odoo#53723

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Ipsita Borisagar <ibo@odoo.com>

Use small buttons and icons.

Part of https://github.com/odoo/odoo/pull/45096


task-2162952

closes odoo/odoo#45096

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Keep the selected image after moving it in the gallery. So that the
options for moving the current image are always displayed.

Part of https://github.com/odoo/odoo/pull/45096
task-2162952

Add the width option for each slides in the carousel snippet.
Remove share links from the third slide of the carousel.

Part of https://github.com/odoo/odoo/pull/45096
task-2162952

Add dots indicators in gallery snippet options.

Part of https://github.com/odoo/odoo/pull/45096
task-2162952

Snippet image gallery retains only the slideshow mode and a new snippet
called 'image wall' takes the 3 other modes.

Part of https://github.com/odoo/odoo/pull/45096
task-2162952

Review the gallery snippet. It has been improved in multiple ways.
Added new options, etc.

Part of https://github.com/odoo/odoo/pull/45096
task-2162952

In gallery snippet with slideshow mode, the right/left indicators have
now the same behavior in editor and outside. Before this commit, these
indicators were always visible in editable mode.

Part of https://github.com/odoo/odoo/pull/45096
task-2162952

The permission check in BaseModel:export_data was checking if the
current user was the administrator user, instead of checking if the
environment was administrator (i.e. it should also check if the sudo bit
is set on the environment).

This commit fixes this and allows to export_data with a simple `sudo()`
instead of needing a `with_user(SUPERUSER_ID)`.

closes odoo/odoo#54647

X-original-commit: f69f47b6ba5c6c462bf617f4876a39233f60034f
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>

In some complex cases, some snippet editors were destroyed but were
still referenced in memory.

E.g.

1) Reorder a snippet gallery image
2) The code is implemented in such a way that reordering create a new
   wrapping column for each image and moves the images in them.
3) This result in having the snippet editor linked to the old columns
   to be explicitely destroyed and removed from memory, but not the ones
   linked to the images as they are still in the DOM (just moved).
4) ... but the snippet editors linked to the images are children of
   the snippet editors linked to the columns. They are thus implicitely
   destroyed... but not removed from memory.

closes odoo/odoo#54643

X-original-commit: e4bf37c7fc892cdba57f0acac8e10f5698184e67
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

The bug was already solved with [1] but was reintroduced later for
another reason. [1] solved the problem by checking that the current
option is not destroyed before asking for an UI update thanks to a
trigger_up (the option was destroyed because of image reordering). The
bug is now reintroduced for the same basic reason: a new trigger_up was
added between the potential option destroy and the destroy check, so
if the option is destroyed, that trigger_up fails to be triggered and
the editor is locked.

This commit solves the problem once and for all, hopefully, with a
more robust solution: only destroy options when none is being
processed. That way we ensure that all trigger_up occuring during an
option activation / update can be properly done.

[1]: https://github.com/odoo/odoo/commit/9eeea4c4107dc15984c475582d5ee58a17cd2568

X-original-commit: 7770430f78ee9e122a732fa042226d362467158e

Commit [1] broke the background videos feature. This is because the
'we-imagepicker' widget is now a sub-widget of a new 'we-button-group'
widget, acting as a selection choice (same as we-button in a we-select).
When selecting a selection choice, the appropriate option method is
called, with the selection value and params... but the params were
actually the ones of the 'we-button-group' element and not the ones
of the chosen widget 'we-imagepicker'.

This has never been important for we-select widgets but it could have
been. The problem is only solved here in master, generically for all
selection widgets (currently only 'we-select' and 'we-button-group').
The params received are the ones of the active sub-widget combined with
the ones of the selection widget.

[1]: https://github.com/odoo/odoo/commit/bb0cd4d5c82a9c2311f8c45ced0e9fdc0397d292



closes odoo/odoo#54629

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Part of: https://github.com/odoo/odoo/pull/54283


task-2278147

closes odoo/odoo#54607

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

Bug
===
Register to an event with a public user.
Sometimes an ACL error will be raised.

Technical
=========
Before flushing the environment (after the creation of the event
registration in the endpoint `registration_confirm`), the ORM will
recompute all needed stored fields. As we didn't write on some of them
(`date_closed`, `utm_campaign_id`, `utm_source_id`, `utm_medium_id`)
they are in the list `Environment::all.tocompute`. So, the ORM will recompute
the fields even if the state didn't change (this behavior can be verify
in `BaseModel::recompute`). This is done after the "create" call of the
event registration and so without the SUDO flag.

Task-2299227

closes odoo/odoo#54624

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

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