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>

When the customer tries to move the video to the first position of the product
image. at that time, the error would be generated.

step to reproduce:
-Install the website_sale
-open Invoicing > vendors > Products > open any Product
-open sales Notepage
-click on add a Media
-past any video url > save it
-click on Go To website from the state button
-click on Edit button > again double click on the image
-then click on a right side position of re-order

error- Key Error:'video_url'

After applying our commit, if the customer got a validation error when
the customer attempted to swap the video into the product images at
 the first position. There is a controller named
`/shop/product/resequence-image` which called, when the customer
changes the position of the video.

https://github.com/odoo/odoo/blob/3ce90ddf33f59a80de34cbafd05679d0817d0076/addons/website_sale/controllers/main.py#L582-L587



The `image res_model` will then receive the `product.image` model when a
customer moves a video from the third to the second position, and that model
locates the field known as `video_url`. However, when a customer moves a
video from the second to the first position, `image res_model` will then
receive the `product.product`  model, and that model finds the same field but
does not have that field in it.

sentry-4393257638

closes odoo/odoo#132471

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

Quotes need to be escaped otherwise it raises "unescaped double quote
found".

closes odoo/odoo#133741

Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>

During 'l10n_eg_eta' server connection when the
'request_response' is not in proper json format then
while decoding 'request_response', the user will face the
'JSONDecodeError Expecting value: line 1 column 1 (char 0)'.
We are keeping the 'blocking_level' as 'error' because the
occurence of this error will prevent the succession of ongoing
operation.

Applying the changes will resolve the issue.

sentry-4220714667

closes odoo/odoo#133735

X-original-commit: a3bb6ece
Signed-off-by: Josse Colpaert <jco@odoo.com>

closes odoo/odoo#133462

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

Crop widget is implemented as div block that is supposed to be displayed on top
of other elements. However, it's not the case for dialogs, because they want to
be on top as well (z-index of dialog is 1050 bootstrap [1])

STEPS:
* Go to Sales Order
* SO
* Schedule an activity
* Use '/' command
* select image
* click image
* crop image

BEFORE: image crop toolbar is hidden behind 'Schedule activity' Pop-up

Fix it by increasing z-index for the crop widget

[1]: https://github.com/odoo/odoo/blob/9102df15cce455205a19fb7b9a0c36186cc51e3a/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L5524



opw-3391583

closes odoo/odoo#133316

X-original-commit: 36c9b2b7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>

Current behavior:
The currency used to create the report is the one of the company. But
if you use a different currency in the pos config, the report will still
be in the company currency.
To fix that we check if all report's config use the same currency and
use it if it's the case we use the pos config currency. And if it's not
possible we use the company currency.

Steps to reproduce:
- Create a second pos
- Change the sale journal and the pricelist to use a different currency
- Open a session and make a sale
- Close the session
- Generate the daily report for the second pos
- The currency is the one of the company

opw-3463280

closes odoo/odoo#132852

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

a translation issue that only appears on Odoo.sh. On the
other systems and locally, everything works fine.
The problem seems to have its source in odoo.tools.translate

Here is the problem:

On the basis of staging (brutus), in the LIMS application, menu Report / Test reports:
* take report 000022. The client is in French.
* click on the button "preview PDF"
-> the values of the "state" column are not translated.

Locally (same sources, same database), these values are well translated.

This field is defined as follows:
```py
state = fields.Selection('get_state_value', string='State', copy=True, required=True)

def get_state_value(self):
return [
    ('init', _('Init')), ('conform', _('Conform')), ('not_conform', _('Not Conform')),
    ('unconclusive', _('Inconclusive'))
]
```
Here's what happens:
When the '_' method is called, another method ("_get_translation") is called.

It tries to determine which module is used. To do so, it is based
on the path (path) and use the "get_resource_from_path" method:
https://github.com/odoo/odoo/blob/16.0/odoo/tools/translate.py#L474



This method iterates over all defined addon paths. On Odoo.sh, these are:

```
'/home/odoo/src/odoo/odoo/addons',
'/home/odoo/.local/share/Odoo/addons/16.0',
'/home/odoo/src/odoo/addons',
'/home/odoo/data/addons/16.0',
'/home/odoo/src/user',
'/home/odoo/src/user/Logicasoft/base',
'/home/odoo/src/user/Logicasoft/lims',
'/home/odoo/src/user/Logicasoft/mail',
'/home/odoo/src/user/Logicasoft/web',
'/home/odoo/src/enterprise',
'/home/odoo/src/themes',
```

The path variable is equivalent to "/home/odoo/src/user/Logicasoft/lims/lims_base/models/lims_analysis_result.py"

As soon as the 'path' variable has a common prefix with one of the paths in the
mentioned list, Odoo considers that it has succeeded in finding the path that contains the module in question.

Locally, the path is: "/home/oli/work/bwt/sh/modules/user/Logicasoft/lims/lims_base/models/lims_analysis_result.py"
And the found path is: "/home/oli/work/bwt/sh/modules/user/Logicasoft/lims/"

But on Odoo.sh, the path found is: "/home/odoo/src/user/"
because Odoo finds that there is a common prefix. This is the case, but another path also has a common prefix: "/home/odoo/src/user/Logicasoft/lims" and this one is the correct one.

The result is that the module found is not the correct one:
- module='Logicasoft' on Odoo.sh
- module = 'lims_base' on other systems

Since the module is not the correct one on odoo.sh, the translation is not found.

Solution
========
when we have a module present in parent and child path we want to take the child path,
which is the long one, so we sort the list of paths by length which ensures that children
have priority on parents.

opw-3374757

closes odoo/odoo#132627

Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>

The condition to create is wrongly evaluated and does not take into account
the country code and the picking type code. This commit fixes this by
reordering the conditions.

closes odoo/odoo#133588

X-original-commit: 58c68c07f0fbb5a1a2bee410a7233904c1c66822
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>

Steps to reproduce:
-------------------
- create and pay with ewallet a cart with a ticket;
- create and pay with ewallet an other cart with a ticket;

Remark:
Don't clear element in the session like 'sale_order_id', etc.
For example, by moving the mouse over the cart or by making a payment process.

Issue:
------
An error is raised with the message:
"It is forbidden to modify a sales order which is not in draft status.".

Cause:
------
We apply an update to the cart on a sale order which is not in draft.

Solution:
---------
Make sure we are working on a sale order in draft
when applying a registration post.
If not, clear session elements.

opw-3465937

closes odoo/odoo#132832

Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>

Before this commit, if you added a domain to a loyalty reward with
one of many2one fields like [("categ_id", "ilike", "test")], it wasn't
possible to open the PoS.

This commit addresses this limitation by replacing the many2one fields
with their corresponding value. To do this the product's field type is
loaded to ensure that this improvement applies exclusively to many2one
fields.

However, it's important to note that this improvement currently handles
only "one-level" of related many2one fields. Any domain that appears
like ("categ_id.foo", "ilike", "foo-val") won't function as expected.

opw-3473103

closes odoo/odoo#132665

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

In Saudi Arabia, the InvoiceLine/ID should not be greater than 6 digits.
Using the move.line_id, this limit can be exceeded.

Simply count the invoice line ids starting from 1 instead.

In master, add a parameter `line_id` to `_get_invoice_line_vals`.

closes odoo/odoo#133675

X-original-commit: 94aac2ed
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>

Previously, when creating a new customer from the POS interface, if
the default language was not changed in the form, an empty string
would be sent to the backend. This resulted in the new customer not
having a language set.

This commit establishes the default language selection as the user's
selected language when creating a new customer within the POS system.

opw-3466525

closes odoo/odoo#133020

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

Issue:
In the project's portal view, if the user is previewing his tasks of a
project with a specific order that is not date or name, and then
goes back to the project list view via the breadcrumb, he is met
with an error 500.

Steps to reproduce:
- Install Project
- With the portal user, go to Project
- Click on a project and sort the task by 'project'
- Go back to the project view via the breadcrumbs.
- Error 500

Cause:
Due to the definition of the url of the breadcrumbs which is
set with `keep_query` which keeps the arguments of the url. The
issue with that is that for the project list view, some of the sort
arguments are not defined, as they are only present in the task view.
So if we sort based on 'project' there is a `KeyError` in the
controller of the project portal view.

Fix:
If the `sortby` is not one of the valid keys, we fallback on 'date'
sorting, which is the behaviour in case when there is no `sortby`
argument in the url. This will keep the `sortby` in the arguments of
the URL, but just ignoring it. This is better UX than having a hard
redirection, because if the user decides to click on a project, the
tasks will be sorted with his previous order specified, which is
usually the wanted behaviour.

Affected versions:
15.0 -> 16.0

opw-3425342

closes odoo/odoo#133642

X-original-commit: 00126875
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>

Versions:
---------
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- saas-16.4

Steps to reproduce:
-------------------
1. install the purchase and account_accountant modules
2. create a purchase order using a non-default currency;
3. create bill;
4. switch to a journal without set currency.

Issue:
------
Currency of bill automatically changes from the one used
by the order to the company default.

Cause:
------
The `account.move` model only looks at bank statements, journal,
and the company default when computing currency, ignoring any
value that might already be present in the invoice:
```
def _compute_currency_id(self):
    for invoice in self:
        currency = (
            invoice.statement_line_id.foreign_currency_id
            or invoice.journal_id.currency_id
            or invoice.journal_id.company_id.currency_id
        )
        invoice.currency_id = currency
```

Solution:
---------
Try to retrieve currency from `invoice.currency_id` before
falling back on the company default.

opw-3434518

closes odoo/odoo#131366

Signed-off-by: Levi Siuzdak (sile) <sile@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>

Since [this commit], it's now possible to edit a media when it's in a
parent that is not editable thanks to `o_editable_media` class.
Unfortunately, these changes make the new class bypass the potential
`data-exclude` defined in the XML option declaration. So if the target
looks like that:
```html
<img class="o_editable_media odoo"/>
```
and the XML option declaration has a `data-exclude=".odoo"`, the option
will still be displayed. This commit corrects the way the
`o_editable_media` class works, so that it only bypasses the
`.o_not_editable` but not the entire exclude.

[this commit]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904



task-3476644

closes odoo/odoo#133594

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

The inherited field of a custom field cannot be deleted

Steps to reproduce:
1. Install Contacts and Studio
2. Go to Contacts and open any contact
3. Toggle Studio
4. Add a field of any type in the view, remove it and close Studio
5. Go to Settings > Technical > Database Structure > Fields and search
   for `x_studio`

Solution:
Mark the inherited field as manual if its parent field is manual and
allow the deletion of inherited custom field if we also delete its
dependency

Problem:
The inherited field was not marked as custom so it was impossible to
delete it

opw-3093581

closes odoo/odoo#133562

X-original-commit: b700c3c6
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

Currently, the user has access to a "Switch into credit note/refund" but
not the reverse button to go from a credit note/refund to an
invoice/bill. This is now the case.

This is a partial backport of odoo#103427

task-id 3102251

closes odoo/odoo#133497

X-original-commit: 6f9593a
Related: odoo/enterprise#46492
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>

When we changed the display of the form in v16, we forgot to adapt the
python framework default form view layout (used when the form view of
the model isn't defined). This provided a weird layout in these case on
Odoo 16.+.

To fix this bad behavior, we adapt the algorithm used to build the
default view form.

Steps to reproduce:
Create a model without a form view and edit it (like we do when you
follow the rd training).

closes odoo/odoo#132228

Signed-off-by: Pierre Paridans (app) <app@odoo.com>

Add IRPF taxes to Spain 35% and 19%

closes odoo/odoo#130728

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

Steps to reproduce:
- Create a product in KIT
- The product and components must be AVCO rated.
- Sell product, confirm delivery and post the invoice

Bug:
the journal entries are not reconciled.
the lines are gouped by product but in this case the products don't match
on the stock side it's the components and on the invoice it's the kit

Fix:
match components stock moves of kits to the kit product

opw-3208169

closes odoo/odoo#133200

X-original-commit: bd082d90d00d62ed9c72b053dae3d9c1f2582088
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Since the website page preview is within an iframe, the selector used to
neutralize some events during edition of blog pages were not targetting
the elements anymore.

This commit makes the elements looked up within the iframe.

opw-3450880

closes odoo/odoo#133052

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

Steps to reproduce:
- Go to `/blog`.
- Enable "Show Sidebar" in the "Customize" menu.
- Edit the page.
- Click on an icon of the "Follow Us" section of the sidebar.
- Click on the "Link" icon of the editor toolbar.

=> An error popup appears.

In further versions, the link parameters can be edited - but they are
lost upon save.

The social media links sections of the blog and blog post pages is
generated and is not supposed to be editable.

This commits makes these social media links sections non editable.

If a user needs to configure such a content specifically, it can be done
inside the "About Us" section of the sidebar above.
E.g.:
- Deactivate the "Follow Us" section from the "Customize" menu.
- You can use copy/paste to duplicate the existing style of the
"About Us" section if you want.
- Click on the "File / Image" icon of the editor toolbar (or type
"/image" to use the Power Box as of 15.0).
- Select a pictogram.
- Click on the "Shape: Circle" icon of the editor toolbar.
- Select the "Font Color" from the editor toolbar.
- Click on the "Link" icon of the editor toolbar to specify an URL.

opw-3450880

X-original-commit: 27d8633c
Part-of: odoo/odoo#133052

closes odoo/odoo#127527

Signed-off-by: William André (wan) <wan@odoo.com>

Part-of: odoo/odoo#127527

Part-of: odoo/odoo#127527

With the latest iot 23_07 image update the wifi connection was unusable.
We correct the activation of the wifi hardware of the raspberry with rfkill unblock all

closes odoo/odoo#133566

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

Before this commit:

* A delete at the end of an empty block just before a table (unbreakable), nothing happened.

After this commit:

* A delete at the end of an empty block just before an unbreakable block, the empty paragraph should be removed and the selection put at the beginning of the unbreakable block.

task-3186679
task-3252775

closes odoo/odoo#125211

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

Before this commit:

* A backspace at the beginning of a List Item (LI), the indentation of the list item was reduced by 1 unit.
If not possible, the current LI was merge with the previous LI.
* A delete at the end of a LI, first we remove one unit of indentation from the next LI,
only when not possible anymore we merge next LI in the current LI.

After this commit:

* A backspace at the beginning toggle off the current LI ( the LI tag is remove and popped out of the List )
The parent List is splitted if needed.
* A delete at the end of a LI directly merge next element inside the current LI.

task-3186679

Part-of: odoo/odoo#125211
Co-authored-by: Aashish Thakur <aath@odoo.com>