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>

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>