Commit 72a17baf force the PO `date_order` to be >= at ` today() to
ensure the select_seller method take the right seller price. This
introduces an error in the MPS module that may need to create PO in the
past.

Instead, this commit patch the call to `_select_seller` to take at least
`today()`

closes odoo/odoo#134130

Opw: 3167094
X-original-commit: b06b0a77
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

To reproduce
============

* referrals -> configuration -> rewards
* try creating a new reward keeping description empty
* here description is required html field
* traceback on clicking save

Problem
=======
in case of html field, `this.data[fieldName]` is an object `Markup{''}`,
so `!this.data[fieldName]` is always `false` as objects are considered
as true value in JS.

Solution
========
in case of html, check the length of the Markup object

opw-3469539

closes odoo/odoo#134119

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Niyas Raphy <https://github.com/niyasraphy>

Current behavior:
When settling an order, the manually_set_price field is set to true
when it shoudln't. This cause issues in the french localization, as it
was always showing the current price as the old price.

Steps to reproduce:
- Install the l10n_fr_pos_cert module, and pos_sale
- Create a new order, add a product and confirm the order
- Open the PoS
- Settle the order you created
- The current price is shown as the old price

opw-3440797

closes odoo/odoo#133382

Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>

It can be that the name field on the account_move_line is an empty
string (as opposed to NULL). This can happen, for instance, when
generating the payment term line for Switzerland without the appropriate
fields on the company.

Since there are instances when the payment term's name is an empty
string, we can retrieve these lines and automatically match them with
payments from  the bank reconciliation model. This can happen
automatically, with exact matches between a payment with a near-empty
reference (when the payment ref is just "/" or "?", this is sanitized
and ends up as an empty string for the purposes of comparison), and
these empty string payment term invoice lines.

The query that fetches the candidate lines for exact matches already
excludes those lines with a NULL move_line name, move ref, move name.
The natural extension of this behaviour is just to exclude the empty
string in these queries also.

closes odoo/odoo#133005

Signed-off-by: Laurent Smet (las) <las@odoo.com>

before this commit, on inheriting the function
_get_custom_rendering_context_values the argument values are not received
in the inherited function as it is not passed along with the super

scenario:
* consider that the payment link is shared to customer
* customer made the full payment
* once the sale or invoice is fully paid, the link has to
be shown as fully paid or expired
* for doing this, if we inherit the above function, the
arguments is not passed to the function

after this commit, the argument values are passed to
super and the value can be used re used in the further
inherit of this function

closes odoo/odoo#134088

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

- Install `website_sale`
- Go to settings
- Enable 'Comparison Price'
- Go to products
- Open a random product
- Put a random `Compare to Price` (example $400 with a sales Price to $295)
- Click on smart button `Go To Website`

With $ 1 = 0.5 €
Before:

With `Public Pricelist`: `$ 300.00 ($ 400.00)`
With `EUR` pricelist: `150.00 € ($ 400.00)`

After:

With `Public Pricelist`: `$ 300.00 ($ 400.00)`
With `EUR` pricelist: `150.00 € (200.00 €)`

backport of https://github.com/odoo/odoo/pull/87134



closes odoo/odoo#133484

Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>

With the build of the new iot image we need to fix the date synchronization

closes odoo/odoo#133986

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

When adding a view to the dashboard, we already save the domain.
We don't want to save the default filters as they can have an opposite
domain as the one selected, meaning no records will be matched when
going to the dashboard.

---

opw-3385248

closes odoo/odoo#132328

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

closes #112101

Signed-off-by: Rémy Voet <ryv@odoo.com>

Changes in default can be bothersome, embed a full baseline
configuration for reliability.

closes odoo/odoo#27926

Signed-off-by: Pierre Masereel <pim@odoo.com>

Bug:
When printing DDT documents for a delivery with a pricelist applied, the
total value shown comes from the product's original price and not the
modified pricelist price.

Setup:
- install `sale_management` and `l10n_it_stock_ddt`
- have a product P with a price A
- create a pricelist that where P has a price B

Steps to reproduce:
- activate DDT report printing
- create a quotation set the pricelist you created and the product P
- validate the quotation
- go to the associated delivery and validate it
- print the DDT report

You should see that the price mentioned on the DDT report does not
account for the pricelist. (price A is shown, instead of B)

opw-3171295

closes odoo/odoo#133676

X-original-commit: 9bdb0ed2
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>

Before this commit, when restarting a synchronization with Outlook or Google, a traceback error could be thrown due when accessing a variable possibly null. After this commit, the variable integrity is checked before its access.

Issue from: 3473180

closes odoo/odoo#133991

Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>

I missed a critical issue in #133708: various users had discovered
they could already fix description issues by adding an XML declaration
to their document which is very cool (though technically not really
valid).

What is a lot less cool is that lxml gets *extremely* unhappy when
asked to parse *strings* with an encoding declaration, raising a
ValueError, so the purported fix breaks on any module which does that,
which seems to include a lot of OCA modules.

Gate the encoding guessing by bailing if the document has an XML
declaration, in which case we just assume the author knows what
they're doing and we leave them alone. For extra safety, check the
encoding declaration in ascii and utf16. Could also have checked for
BOMs, but lxml seems to not care about them overly much (in fact it
seems to prefer them decoded which is odd).

closes odoo/odoo#133959

Reported-by: @rezak400
X-original-commit: fd353d7d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Accounting moved the logic of _get_reconciled_vals
into _compute_payments_widget_reconciled_info but did not made the
change in point_of_sale.
This commit resolve this by putting the logic of the previous
_get_reconciled_vals into an override of the
_compute_payments_widget_reconciled_info method.
This is done because this is a legal requirement in France to have and
maybe in other countries.

closes odoo/odoo#133655

Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>

Since [1] if the partner related to a visitor belongs to a company that
cannot be accessed by the current user, an error is raised when trying
to display the list of visitors.

This commit makes the name obtained through an additional sudo on the
`partner_id` record which might not be accessible to the current user.
This is equivalent to using the `name` field of visitor, except that
accessing the `partner_id` field will fail if `website.visitor` itself
cannot be accessed.

Steps to reproduce:
- Go to Settings / Companies
- Create a second company
- Go to Website / Reporting / Visitors
- Select "Edwin Hansen"
- Navigate to its linked partner in the contact field
"Gemini Furniture, Edwin Hansen"
- Navigate to its company "Gemini Furniture"
- In the "Sales & Purchase" tab, assign the second company as the
Company
- Save (this creates an error - but it is saved)
- Go to Website / Reporting / Visitors

=> The page was not displayed and an access error message was
displayed.

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



opw-3462104

closes odoo/odoo#133553

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

When the optional column "Product Variant" is enabled on
the sales order lines tree view, if the variant of a
configurable template is given, the configurator was triggered
and opened when it shouldn't have, since the variant is already
chosen.

Backport of de7a6f5f3d83356eb02f8fc25b4a0b8aabb946b3 in 16.0+
Fixed in 16.3+ by the forward-port, but not in the base commit.

task-3397870
opw-3450317

closes odoo/odoo#131574

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Steps to reproduce the problem:
- Go on the "Courses" application and select a course.
- Edit.
- Replace the main image of the course with one of your own.
- Save.

-> The function route `/web_editor/modify_image/` is called two times
leading to the creation of two attachments instead of one.

The `saveModifiedImages()` function iterates through editable elements
and calls `/web_editor/modify_image/` for each image with a
`o_modified_image_to_save` class inside those elements. In our case, the
image has an editable element parent that has itself an editable element
parent. Because since [1], the `o_modified_image_to_save` class is
removed after the `rpc` call, this class is not removed while the
`saveModifiedImages()` loops on the second editable element parent of
the image. As a result, `/web_editor/modify_image/` is called two times.
Note that before [1], the process was partially wrong as well.
`/web_editor/modify_image/` was indeed called only once but with the
wrong arguments. This is now fixed by ensuring that the function is
called with the arguments coming from the closest editable element.

[1]: https://github.com/odoo/odoo/commit/8872aab2d108ff3e2ec06ca4579479898c87738c



task-3451349

closes odoo/odoo#130472

Signed-off-by: Robin Lejeune (role) <role@odoo.com>

Updated the translations for 16.0

closes odoo/odoo#132026

Signed-off-by: Josse Colpaert <jco@odoo.com>

New module is created (`l10n_it_edi_pa`) to add fields that are required to handle Split Payment, and it will be merged in master.

- `l10n_it_origin_document_type`
- `l10n_it_origin_document_date`
- `l10n_it_origin_document_name`
- `l10n_it_cup`
- `l10n_it_cig`

These fields are required to track money used that comes from funding to the Public Administration business for purchases, be it ordinary or project based spending.
They also need to be exported in XML during the EDI phase, in different
XML nodes depending on the `l10n_it_origin_document_type` field

ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiOrdineAcquisto
Task link: https://www.odoo.com/web#id=2823645&model=project.task
task-2823645

Part-of: odoo/odoo#132026

When an Italian company bills a PA business (for example they're selling cleaning services for a public building) the PA business will send the VAT to the Tax Agency themselves, while generally the VAT is collected and sent to the Tax Agency by the buyer (the PA business). This is done to avoid VAT fraud as the PA doesn't trust the business will actually pay the VAT. That's very common in Italy.
A new module will be created (`l10n_it_edi_pa`) in the next commit to add fields that are required to handle Split Payment, and it will be merged in master.

- New Split Payment related accounts are created: 2607, 2608
- New tax report data to target the VE tax chart grid
- Split Payment account.taxes are Groups of Taxes whose children target VE38 tax grid
- account_tax's l10n_it_vat_due_date is no more, we base ourselves on the VE38 tax grid
- The Group of Taxes includes normal VAT and a reversed VAT entry (for sale)
- Tax checks on the invoice now also check group of taxes with flatten_taxes_hierarchy()
- New Split Payment tax group has been added to build the correct totals in the move form view
- account.taxes and account.fiscal.position has been added to change from VAT to VAT Split Payment automatically when you select a res.partner that features the fiscal position.
- The Fiscal Position also has the law-required note that has to be featured on invoices that use Split Payment
- A PA business demo partner is added to showcase the new fiscal position
- `l10n_it_stock_ddt` tests are minimally modified because the Form component didn't let you use 'like' in the move form view

Task link: https://www.odoo.com/web#id=2823645&model=project.task
task-2823645

Part-of: odoo/odoo#132026

Necessary changes to:
- CoA
- Taxes
- Fiscal Positions
- Account Tags
for supporting up-to-date Mongolian reports.

closes odoo/odoo#130511

Related: odoo/enterprise#45047
Signed-off-by: Josse Colpaert <jco@odoo.com>
Co-authored-by: Antoine Dupuis <andu@odoo.com>

Steps to reproduce:

- Install Attendances app and Employee app
- Setup an employee with a contract which work entry source is from
attendance
- Change the working schedule to different timezone, for example
Asia/Hong_Kong
- By default the working schedule should be start to work from 0800 to 1700
- Now create an attendance in the first day of the contract, i.e.
1st May 2023, check in time 0700, check out time 2000
- The total work hours should be 13
- However, in the work entry, the genearted work entry is 0800-2000, only
12 work hours.

Current behaviour:
The generated work entry mismatches the value of the attendance

Expected behaviour:
The work entry should match the attendance

Explanation:
This issue is casued by the timezone issue. When the system generate
the work entry, it will calculate the date_from datetime and date_to datetime.
Then it will compare between the attendance and the date_from datetime to choose
the larger datetime to put inside the work entry as start time.

However, the date_from datetime didn't consider the timezone of the working schedule.
In the above example, Asia/Hong Kong time is UTC+8 time. Therefore if we convert
the attendance time back to UTC time. It is check in time 30 April 2023, 2300 to
check out time 1 May 2023, 1200. In the mean time, if we compare between the date_from
datetime (1 May 2023, 0000) and the attendance check in time (30 April 2023, 2300).
The system will take the date_from time and therefore the generated work entry time
is incorrect.

task-3468012

closes odoo/odoo#133610

Related: odoo/enterprise#46574
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>

Issue:
======
- Display of monetary values in kanban views is wrong in rtl language
- Pivot display has multiple erros in rtl language: values are left
  aligned and they are supposed to be right aligned like in ltr lang,
  negative numbers has the sign in the wrong place, the (plus/minus)
  icon placement is wrong (it should be before the title and not after)

Steps to reproduce the error:
=============================
- Install accounting and rlt language (arabic for example)
- Go to accounting (display of monetary fields is wrong)
- Go to accounting/accounting/journal items/pivot view
- Choose residual amount in view (it has some negative values)

Solution:
=========
Kanban Solution:
- I fixed the direction of the display to be ltr always for monetary
  values and added the class to the appropriate tags.
Pivot Solution:
- I fixed the direction and text-align style for the values to always
  display the same like rtl.
- displaying the icon and then the title will always give the desired
  display since the direction will reverse their order itself when it's
  rtl

enterprise fix : https://github.com/odoo/enterprise/pull/46675



opw-3295573

closes odoo/odoo#132843

Related: odoo/enterprise#46675
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>

This commit allows you to change the title of the social media block
after the first save. If an element is in a parent that has the class
`o_not_editable` then it is only editable if it has the contenteditable
attribute set to true. We rightfully remove this attribute at saving but
without putting it back when we return to edit mode. This commit allows
to fix this case. Note that we have to improve this system in the future
(so we can get rid of this patch).

This part of the fix is very similar to [this other fix] for the team
block.

[this other fix]: https://github.com/odoo/odoo/commit/b7d53d2fcb20a447fd3098adf94ffb33bc49dda9

task-3073171

closes odoo/odoo#133860

Part-of: odoo/odoo#105964
X-original-commit: https://github.com/odoo/odoo/commit/ba485b12bf9bc02644e743c7f236ce6492f453bc


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

This commit allows you to change the icons of custom links of the social
media block after the first save. Thanks to [this other commit], there
is now a class that permits to inform the editor that a media is
editable even if it is a non-editable parent. This commit permits to use
the new class to fix the issue.

Steps to reproduce the bug:
- Drop a social media block on a page
- Add a custom social media
- Save
- Edit
- Try to change the icon of the custom social media with a double-click

=> The icon cannot be changed.

Note that [another commit] had already been made and fixed the problem
halfway (the icon change didn't work on double-click). This commit
reverts it and fixes the problem correctly with the new system.

[this other commit]: https://github.com/odoo/odoo/commit/6ead397f33512c918f51feb2b32fb3e15ffedf34
[another commit]: https://github.com/odoo/odoo/commit/bb291b35e46e42ca098aa3e04ac0b473f72be423

Fixes https://github.com/odoo/odoo/issues/104048
task-3073171

X-original-commit: https://github.com/odoo/odoo/commit/a46a8f45b65ca9ecfbb12ffb7980902085666e1a
Part-of: odoo/odoo#133860

Current behavior:
When a discount is applied to a product, the receipt shows the price
with the discount applied as the base price.

Steps to reproduce:
- Open PoS
- Add a product to the order
- Apply a discount to the product with the numpad
- Validate the order
- Check the receipt, the base price of the product is the price with the
  discount applied.

(https://github.com/odoo/odoo/assets/32939472/eb0998a7-70a1-432a-8909-868d9307c999

)
The price in red should be 70$ (the price without the 5% discount)

opw-3463745

closes odoo/odoo#133835

X-original-commit: 07b08a2d
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>

The commit f5ce6c59 introduced a regression that prevents closing
a POS session if the user does not have accounting and inventory
access rights.

opw-3487462

closes odoo/odoo#133899

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

Users sometime want to rename existing controllers URL, e.g. /shop as
french /magasin. The feature is possible within Odoo thanks to 308 type
redirections that can be configured via a hidden ?debug=1-only website
menu.

Upon generating the routing-map (the structure that links URLs to
controllers), when a URL is found inside of the `website.rewrite` model,
two links (called Rules in werkzeug jargon) are registered: the new,
translated, URL is linked to the controller and the original URL is
linked to a redirection to the new URL.

For the context of this PR, it is important to note that the redirection
only applies to the very URL saved inside the `website.rewrite` model:
if a controller has multiple routes, e.g. `/shop` and `/shop/shop`, only
`/shop` is redirected to `/magasin`, `/shop/shop` is left as-is.

Without 308 redirection:

	/shop -> def shop()
	/shop/shop -> def shop()

With 308 redirection:

	website.rewrite(from_url='/shop', to_url='/magasin')
	/shop -> /magasin
	/shop/shop -> def shop()
	/magasin -> def shop()

The redirection is set on the routing dictionnary of the endpoint, this
is the dictionnary that collect the informations set via the `@route`
decorator (auth=, method=, type=, ...).

Prior to [HTTPocalypse], that dictionnary was duplicated so that the
redirection was applied on the single route endpoint that matched
the `website.rewrite` record. With [HTTPocalypse] that duplication has
been wrongly removed: all original routes redirected to the new
translated one.

Bug introduced in [HTTPocalypse]:

	website.rewrite(from_url='/shop', to_url='/magasin')
	/shop -> /magasin
	/shop/shop -> /magasin          <-- wrong
	/magasin -> def shop()

This PR fixes the problem, it makes sure that the redirection is saved
*only* on the route that matched the website.rewrite record, not the
other routes.

[HTTPocalypse]: https://github.com/odoo/odoo/pull/78857



closes odoo/odoo#133371

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

This commit introduces a test in Odoo 15 about a broken behavior in Odoo
16 which was not covered by a test.
A fix will be shipped alongside this commit forward-port in Odoo 16.

The behavior involved here is about:
- Having a multi-url defined route
- One of those URL not having a model converter
- One of those URL having a model converter
- Creating a 308 redirect for the URL without model converter

Something like this route (real example from the code):
```py
@http.route([
    '''/shop''',
    '''/shop/page/<int:page>''',
    '''/shop/category/<model("product.public.category"):category>''',
    '''/shop/category/<model("product.public.category"):category>/page/<int:page>'''
], type='http', auth="public", website=True, sitemap=sitemap_shop)
```
And this redirect (real usual example from clients):
```py
self.env['website.rewrite'].create({
    'name': 'Test Multi URL 308',
    'redirect_type': '308',
    'url_from': '/shop',
    'url_to': '/magasin',
})
```

In Odoo 15, everything will work as expected:
1. Accessing /shop will redirect to /magasin
2. Accessing /shop/category/categ-1 will not redirect and user will be
   on /shop/category/categ-1 still

But in Odoo 16:
In the case described above, acessing the URL with model converter from
the route will fail and redirect to a non slugified URL in the form of
`/some-url?param=test.model%287%2C%29` which is basically the
stringified encoded version of the record `test.model(7,)`.

Note:
- It doesn't matter if the route is contained in the other, the error
  will still occur even if `'''/shop'''` was `'''/abc'''`.
- Even if all URL from the route have their own 308 redirect, the error
  will still occur.
- It won't have any issue if there is a 308 on the route with model
  converter: both the one without model converter and other url with
  model converter will work and won't be impacted.

This might be because of a concept of "merging URL" from httpocalypse,
see https://github.com/odoo/odoo/commit/347a3ccf763cc6958d5dc1df3168c9c65245736c

opw-3450054
opw-3466498
opw-3477380
opw-3475694

X-original-commit: 9230f7db60b10ca2a3e83d6beefb6cf72d09a804
Part-of: odoo/odoo#133371

Steps to reproduce:
 1. Create an SO with billable timesheet entries
 2. Create an invoice
 3. If using enterprise, first cancel the invoice and reset the timesheet
  entries back to draft, then set the invoice back to draft
 4. Remove the sale order items from the timesheet entries
 5. Remove the invoice line associated with the timesheet entries

Current behavior:
 - Throws an error since the so_line value from read_group is now
   False and is not subscriptable

Expected behavior:
 - Removes the invoice lines

Fix:
 - Check that the so_line is not False before continuing with the logic

closes odoo/odoo#133864

X-original-commit: dde30798
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Issue:
------
When adding a file to an employee's work permit ("Private Information tab"),
the file name is the "value" of the file.
This is not meaningful for the user who will download the file.

Solution:
---------
Use the `filename` attribute to determine the field of `hr.employee`
to be used to get the file name.
As the original file name doesn't exist in an existing field,
we can use a "generic" file name with a non-stored computed field.

opw-3458842

closes odoo/odoo#133569

Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>

When sending a mailing we make sure to preserve comments (in particular
so that MSO comments can be read by Outlook). However this was not the
case when testing a mailing using the Test button in the form view.

task-3488162
opw-3290548
opw-3479234

closes odoo/odoo#133874

X-original-commit: d6568e0b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

This commit fixes the issue of animations that got trigger by backspacing, pressing enter
and other causes

The cause of the issue was a custom historyRevert event that was only used to
trigger a widgets_start_request event which ended up restarting the options,
which lead to the animation option replaying the animation.

We were not able to pinpoint the use of this particular trigger_up as it does
not seem to serve any purpose anymore. Since its presence does create a bug, we
decided that the best course of action was to remove it. If this commit creates
a regression and the original bug comes back, we will reassess the situation.

Task-2752421

closes odoo/odoo#133806

X-original-commit: 16fc9e23
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Apparently `lxml.html.document_fromstring` (and possibly other
`lxml.html` loaders) parses byte-strings as latin1 regardless of their
actual encoding, maybe because python2, maybe because there's a super
legacy html4 parser underlying it.

Either way that means ever since loading
`static/description/index.html` files was added 10 years
ago (4bf6a7ea) `_get_desc` has been
loading these files in latin1 rather than the utf8 most people would
expect.

Add an explicit decoding phase to try and load html description files
in UTF8. Fall back to latin1 in case there are description files which
are genuinely in latin1, or even just some random-ass broken stuff
which very much isn't utf8 (the extended-ascii encodings -- of which
latin1 is one -- will happily accept and mangle any input as every
byte value is valid, utf8 is a lot more structured).

Closes #127846

closes odoo/odoo#133776

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

This reverts [this commit]. Indeed, [this commit] was too restrictive on
the visibility dependencies and blocked the creation of some conditions.

Example:
- Add a form on the website.
- Add two fields and rename them (by "test" for example).
- Change the visibility of the first one and set it to "Visible only if
Your Name is equal to Boule"
- Change the visibility of the second one and set it to "Visible only if
Your Name is equal to Bill"

-> The field "test" will be visible if "Your name" is "Boule" or "Bill".

[this commit]: https://github.com/odoo/odoo/commit/17c93a4ca14119c5bf94270546adaf86a4378d67



closes odoo/odoo#133709

Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

There were 2 errors fixed by this commit:
1. The form registry fields added in [1] and [2] in Odoo 13 had a
   `string` attribute translated with `_t()` while now it should be
   translated with `_lt()`. It was surely working in Odoo 13 but not
   anymore. It's not worth investigating to be sure.
2. The IMP done at [3] added a lot of fields but all of those forgot the
   `_t()`/`_lt()` translation.

Note that:
1. A fix to replace `_t` by `_lt` was done at [4] but it was badly done
   as it was not targetting the correct version... and only fixed one of
   many occurences.

[1]: https://github.com/odoo/odoo/pull/32565
[2]: https://github.com/odoo/enterprise/pull/4063
[3]: https://github.com/odoo/odoo/commit/617eba941785aa680edb826e14b0009637d60dee
[4]: https://github.com/odoo/odoo/commit/2be83cae7bcda369ed5bc7806aef845c6c76e687



opw-3471873

closes odoo/odoo#133692

Related: odoo/enterprise#46590
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Somehow, there is not .pot file for this module while there is a
translated term.

A proper investigation wasn't made, but here is the history:
- The "Project" translatable term was added in JS with commit [1] in
  April 2019 as an IMP in master so there was no addition in the `.pot`
  file, as expected.
- The `.pot` file was added by a `[I18N] export saas-12.4 terms` commit
  at [2] in Augustus 2019.
- The `.pot` file was removed by a `[I18N] export 15.0 source` commit at
  [3] in September 2021.
  This was probably an error as the "Project" term from this module was
  never removed and always existed since it was added in 2019.

[1]: https://github.com/odoo/odoo/commit/6df3ba8b22ff16e9fd8ad6d87ea55e7eaf13e67b#diff-529f47293f2a178209115a2bc74ce79c5a880e58497a5e9d86ad4d7fd29676baR17
[2]: https://github.com/odoo/odoo/commit/8be6470a826fc6e467a3bef1696d236249ca29f9#diff-29cc1f256a825ea298abd8b7780984bacca6b874c5d139412fed5fb164794cd2R1
[3]: https://github.com/odoo/odoo/commit/63e6807437295519a0f4705fb88644d6d557ca3a#diff-29cc1f256a825ea298abd8b7780984bacca6b874c5d139412fed5fb164794cd2L1

Part-of: odoo/odoo#133692

Steps to reproduce the bug.

- In website edit mode, add a form snippet to a page.
- Add a "number" field within this form.
- Modify the label of this field in the options and name it "Field 1".
- Add a "text" field to the form.
- In the options of the "Text" field, select "Visible only if" for the
"visibility" option.
- Then, choose "Field 1" and "Is greater than" in the two dropdowns that
follow.
- Enter "10" in the input below.
- Save the page.
- Enter "2" in the "Field 1" input.
- Bug: The text field is displayed, even though it should only be
visible if "Field 1" is greater than 10.

This bug exists since the "conditionally show form fields" feature was
added to Website (in this commit [1]). The bug happened because we were
comparing strings instead of numbers.

[1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce



opw-3449900

closes odoo/odoo#133689

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

Since a recent change at [1], a race condition seems to occur in the
gray colors palette test. Indeed, the change removed some delay in the
hackish code that is meant to wait for CSS reload.

Instead of restoring that otherwise-useless delay, this commit actually
fixes an extra_trigger that was incorrectly made in this test when it
was introduced at [2].

In any case, we should develop a more consistent and uniformed way to
wait for a CSS reload during edition test tours. It is currently done
different ways in different tests.

Note: this targets 16.0 to fix the wrong extra_trigger at the source,
even though [1] was only made in later versions.

[1]: https://github.com/odoo/odoo/commit/c6f8f781150902f585e16087f4a3868a855f3bd8#diff-795af7752739f5f510f74e5ee9b5b04d18a851062a1a6b7350cbe406e30a409dL18
[2]: https://github.com/odoo/odoo/commit/ddf2e74b4cf503ba651174bc7f280bf2f31a215e



runbot-24371

closes odoo/odoo#133345

Signed-off-by: Romain Derie (rde) <rde@odoo.com>