In portal chatter, user could be authenticated with `access_token` or `hash and pid`. The problem is that `portal_avatar()` only checks the access_token, so if it doesn't have the access token but the hash and pid, it misses the user's avatar ([PR odoo#141414](https://github.com/odoo/odoo/pull/141414)). This commit adds these two parameters to `portal_avatar` controller to cover all cases of authentication in portal chatter messages. Forward-Port-Of: odoo/odoo#150689 Forward-Port-Of: odoo/odoo

In portal chatter, user could be authenticated with `access_token` or `hash and pid`. The problem is that `portal_avatar()` only checks the access_token, so if it doesn't have the access token but the hash and pid, it misses the user's avatar ([PR odoo#141414](https://github.com/odoo/odoo/pull/141414)).
This commit adds these two parameters to `portal_avatar` controller to cover all cases of authentication in portal chatter messages.

Forward-Port-Of: odoo/odoo#150689
Forward-Port-Of: odoo/odoo#149897

In https://github.com/odoo/odoo/pull/105119, new accounts were added to represent employee-related expenses. Based on the non-official document https://swissdec.ch/document/share/295/4cc46aca-8b47-49e9-882a-03c37eb8dea3 we used account codes 2990 and 2999 for accounts 'Indemnities' and 'Company Car Correction'. However, these accounts have no place with the equity accounts in 29xx, since they are not equity but rather expense accounts. Examples of CoAs that include employee indemnity accounts

In https://github.com/odoo/odoo/pull/105119, new accounts were added to represent employee-related expenses. Based on the non-official document https://swissdec.ch/document/share/295/4cc46aca-8b47-49e9-882a-03c37eb8dea3 we used account codes 2990 and 2999 for accounts 'Indemnities' and 'Company Car Correction'.

However, these accounts have no place with the equity accounts in 29xx, since they are not equity but rather expense accounts. Examples of CoAs that include employee indemnity accounts place them under account group 5 with the other employee-related expenses.

(e.g. https://plancompta.com/plan-comptable-suisse-pcg-2021/)

As such, we move accounts 2990 Indemnities -> 5840 and 2999 Company Car Correction -> 5031.

Fixing this in stable will not cause any in-database corruption, since the updated code is only executed when the CoA is loaded/reloaded. However, users will need to reload the CoA in order to take advantage of the fix.

This also ensures that the Swiss Balance Sheet is balanced.

Enterprise PR: https://github.com/odoo/enterprise/pull/54941

taskid:3060790

Forward-Port-Of: odoo/odoo#150692

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#139295

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#139295

Since [1] when the legacy registry was replaced for website forms, model-based forms cannot be created anymore because the legacy registry getter returned a falsy value upon missing keys, while the new registry raises an error. This commit specifies a default values on the calls to the registry to avoid the error. [1]: https://github.com/odoo/odoo/commit/2d9f6fb32441b5db386e35200a5aab6b11b840dd#diff-59b3bc5742547152ea8d3248e1bd6606fbace25e572d7ca6c50c61e5847d184fL3-R3 opw-3677790 opw-3

Since [1] when the legacy registry was replaced for website forms, model-based forms cannot be created anymore because the legacy registry getter returned a falsy value upon missing keys, while the new registry raises an error.

This commit specifies a default values on the calls to the registry to avoid the error.

[1]: https://github.com/odoo/odoo/commit/2d9f6fb32441b5db386e35200a5aab6b11b840dd#diff-59b3bc5742547152ea8d3248e1bd6606fbace25e572d7ca6c50c61e5847d184fL3-R3

opw-3677790
opw-3683466

Forward-Port-Of: odoo/odoo#150659

…simulation Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150648

…simulation

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#150648

Before this commit, when no conversation was selected in the Discuss app, folding a category such as "Channels" results in a crash. This happens because `store.discuss.thread` is `undefined`, so it must be properly guarded in the template of discuss sidebar category. Forward-Port-Of: odoo/odoo#150828

Before this commit, when no conversation was selected in the Discuss app, folding a category such as "Channels" results in a crash.

This happens because `store.discuss.thread` is `undefined`, so it must be properly guarded in the template of discuss sidebar category.

Forward-Port-Of: odoo/odoo#150828

__Current behavior before commit:__ If `child` is not an `Element` (like a Text or a Comment node), the call to `querySelectorAll` at the following line will crash. __Description of the fix:__ End the current loop iteration if `child` is not an `Element` to avoid calling `querySelectorAll` on it. __Steps to reproduce the issue on runbot:__ In 15.0: - Open Email Marketing > Mailings > Create > Second template - Drag and drop a `Comparisons` block - Display source code - Write some

__Current behavior before commit:__
If `child` is not an `Element` (like a Text or a Comment node), the call
to `querySelectorAll` at the following line will crash.

__Description of the fix:__
End the current loop iteration if `child` is not an `Element` to avoid
calling `querySelectorAll` on it. 

__Steps to reproduce the issue on runbot:__
In 15.0:
- Open Email Marketing > Mailings > Create > Second template
- Drag and drop a `Comparisons` block
- Display source code
- Write some text under the `<div class="card ...">`
- Save --> Traceback

In 16.0+:
- Open Email Marketing > Mailings > New > `Start From Scratch`
- Drag and drop an `Event` block
- Replace one of the image (a comment node will be added [here][1])
- Save --> Traceback
 
opw-3682469
opw-3689181

[1]: https://github.com/odoo/odoo/blob/df1b43a6de5ad15a8fee3713de7d8ec926c61f12/addons/web_editor/static/src/js/backend/convert_inline.js#L715

Forward-Port-Of: odoo/odoo#150752
Forward-Port-Of: odoo/odoo#150096

Install mass_mailing with demo data, send a mailing using the "Thank you for joing us" template. Inside your mail client, click on the LOGIN button, this open your web browser on a link-tracker URL (`/r/xyz`) but the page fails to load because "The page isn’t redirecting properly". Inside the template of that "Thank you for joing us" mail, the logging button is basically defined as follow: `<a href="#">LOGIN</a>`, an URL with a fragment that is empty, a redirection to the current page.

Install mass_mailing with demo data, send a mailing using the "Thank
you for joing us" template. Inside your mail client, click on the LOGIN
button, this open your web browser on a link-tracker URL (`/r/xyz`) but
the page fails to load because "The page isn’t redirecting properly".

Inside the template of that "Thank you for joing us" mail, the logging
button is basically defined as follow: `<a href="#">LOGIN</a>`, an URL
with a fragment that is empty, a redirection to the current page.

Upon rendering that template and send it to the reciptients, all links
are wrapped inside a link-tracker for well tracking purpose, this
created a link `/r/xyz` targetting `#`. Upon accessing that `/r/xyz` URL
the client would be redirected to `#` which in that context is actually
`/r/xyz#`: the link-tracker itself. The browser detects that there is a
redirecting loop and show an error instead.

The problem is solved by saving an absolute link with the link-tracker
instead of a relative one.

[Task-3603607](https://www.odoo.com/web#id=3603607&cids=1&menu_id=4720&action=333&active_id=10888&model=project.task&view_type=form)

Forward-Port-Of: odoo/odoo#150678
Forward-Port-Of: odoo/odoo#147855

**Current behavior before PR:** Sometimes applying bulletlist does not produce the expected bullet list formatting .This issue arises when the selection is on an emptyTextNode(""), and the traversal of nodes using getTraverseNodes results in the same emptyTextNode(""). In the toggleList function, we typically remove the emptyTextNode(""), leaving no appropriate node for creating a bullet list. **Desired behavior after PR is merged:** Now it will create bullet list because we move the se

**Current behavior before PR:**

Sometimes applying bulletlist does not produce the expected bullet list formatting .This issue arises when the selection is on an emptyTextNode(""), and the traversal of nodes using getTraverseNodes results in the same emptyTextNode(""). In the toggleList function, we typically remove the emptyTextNode(""), leaving no appropriate node for creating a bullet list.

**Desired behavior after PR is merged:**

Now it will create bullet list because we move the selection to its parent when it is on an emptyTextNode(""), similar to what we have done with the "BR" element.

task-3547574

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#138999

Bug === The decimal property crash when added in a list view, if some records have False as a value. Technical ========= Since fe797a03285ec9c81d29ed631839c91e2b9957a4 , we use the wrong Formatter in the Float field. Task-3698415 Forward-Port-Of: odoo/odoo#150682

Bug
===
The decimal property crash when added in a list view, if some records
have False as a value.

Technical
=========
Since fe797a03285ec9c81d29ed631839c91e2b9957a4 , we use the wrong
Formatter in the Float field.

Task-3698415

Forward-Port-Of: odoo/odoo#150682

Steps to reproduce: - Setup easypost delivery - Create a service product and publish it on the website - Add that product alone to the cart and proceed to payment Bug: Error raised because total weight of the order is null Fix: no delivery will be created so we should skip the check if no deliverable product is present on the order note: on "_get_shop_payment_errors" switched the order to short circuit "_get_delivery_methods" opw-3647420 Forward-Port-Of: odoo/odoo#150475 Forward-

Steps to reproduce:
- Setup easypost delivery
- Create a service product and publish it on the website
- Add that product alone to the cart and proceed to payment

Bug:
Error raised because total weight of the order is null

Fix:
no delivery will be created so we should skip the check if no deliverable product is present on the order
note: on "_get_shop_payment_errors" switched the order to short circuit "_get_delivery_methods"

opw-3647420

Forward-Port-Of: odoo/odoo#150475
Forward-Port-Of: odoo/odoo#147765

Steps to reproduce ================== - Enable analytic accounting - Go to customer invoices - Open a record - Open studio - Click on the Invoice lines > Edit list view - Set the analytic field as required - Close studio - Create a new record - Add a new line - Click on the analytic field - Close the popup - Save the record => Even though we didn't set a value for the field, it is saved Cause of the issue ================== The actual field value is an empty object. The

Steps to reproduce
==================

- Enable analytic accounting
- Go to customer invoices
- Open a record
- Open studio
- Click on the Invoice lines > Edit list view
- Set the analytic field as required
- Close studio
- Create a new record
- Add a new line
- Click on the analytic field
- Close the popup
- Save the record

=> Even though we didn't set a value for the field, it is saved

Cause of the issue
==================

The actual field value is an empty object.
The validity of a field is checked here [0].
An empty object is considered a truthy value.

When setting the required attribute directly on the python field
declaration, an empty object does not pass the check

Solution
========

Add a specific check for json fields. When the value is either false
(not set) or an empty object, the field is considered invalid.

---

[0]: https://github.com/odoo/odoo/blob/23f01c533512cbfb33e90509e22cd3c3c4f99d40/addons/web/static/src/views/basic_relational_model.js#L284

opw-3659763

Forward-Port-Of: odoo/odoo#150677
Forward-Port-Of: odoo/odoo#149840

After https://github.com/odoo/odoo/commit/54a6f1688fb8d15b662848b03cecbe8236292d07, the `TestConfigureShops.test_should_not_affect_other_pos_config` and `TestConfigureShops.test_is_header_or_footer_to_false` started to fail randomly in runbot. This is because when res.config.settings form initializes, it may start with `pos_config_id` that contains pricelists that are not compatible to the currency of the pos_config that will be selected in the form. This commit makes sure that when the

After
https://github.com/odoo/odoo/commit/54a6f1688fb8d15b662848b03cecbe8236292d07, the `TestConfigureShops.test_should_not_affect_other_pos_config` and
`TestConfigureShops.test_is_header_or_footer_to_false` started to fail randomly
in runbot. This is because when res.config.settings form initializes, it may
start with `pos_config_id` that contains pricelists that are not compatible to
the currency of the pos_config that will be selected in the form.

This commit makes sure that when the `pos_config_id` is changed to something
that doesn't use pricelist, the `pos_available_pricelist_ids` field is updated
accordingly.

Runbot Errors: 31294, 31293

Forward-Port-Of: odoo/odoo#150220

Some logic of the `payment.provider` and `provider.method` models was not properly covered by unit tests. See also: - https://github.com/odoo/enterprise/pull/54930 Forward-Port-Of: odoo/odoo#149833

Some logic of the `payment.provider` and `provider.method` models was not properly covered by unit tests.

See also:
- https://github.com/odoo/enterprise/pull/54930

Forward-Port-Of: odoo/odoo#149833

**Current behavior before PR:** When a user edits an article and selects the restore button to revert to a previous version, the displayed time is incorrect because it shows universal time instead of the user's timezone. **Desired behavior after PR is merged:** When a user edits an article and utilizes the restore button to revert to a previous version, the timestamp will now reflect the time in the user's current timezone. task-3641579 --- I confirm I have signed the CLA and r

**Current behavior before PR:**

When a user edits an article and selects the restore button to revert to a previous version, the displayed time is incorrect because it shows universal time instead of the user's timezone.

**Desired behavior after PR is merged:**

When a user edits an article and utilizes the restore button to revert to a previous version, the timestamp will now reflect the time in the user's current timezone.

task-3641579


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#149177

Forward-Port-Of: odoo/odoo#149547 Forward-Port-Of: odoo/odoo#148372

Forward-Port-Of: odoo/odoo#149547
Forward-Port-Of: odoo/odoo#148372

When the IoT V23_11 checkout a Odoo DB 15.0, the newest module: urllib3 PyPDF2 Werkzeug Can't run this Odoo version. So we fix the version of these module to match to Odoo 15 / 16 / 17 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150708

When the IoT V23_11 checkout a Odoo DB 15.0, the newest module:

urllib3
PyPDF2
Werkzeug

Can't run this Odoo version.

So we fix the version of these module to match to Odoo 15 / 16 / 17

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#150708

To reproduce on runbot: - Log-in as admin - Enable debug mode - Go to Settings / General Settings and ensure that there is a alias domain configured for the current company - Go to recruitment app - on "Experienced Developer", open the option dropdown (meatball) and click on "Trackers" - observe there is no button "Generate Email" The `has_domain` field serve to check if the mail alias domain is correctly configured, before odoo/odoo@638e0f658, is was computed only from the `mail.ca

To reproduce on runbot:

- Log-in as admin
- Enable debug mode
- Go to Settings / General Settings and ensure that there is a alias domain configured for the current company

- Go to recruitment app
- on "Experienced Developer", open the option dropdown (meatball) and click on "Trackers"
- observe there is no button "Generate Email"

The `has_domain` field serve to check if the mail alias domain is correctly configured, before odoo/odoo@638e0f658, is was computed only from the `mail.catchall.domain` ICP, now we only consider the alias domain from the recruitment source alias.

  But for new record there is no alias, so `has_domain` is always
falsy which prevent the `Generate Email` button to be show.

This commit fallback to the job's or user's current company mail alias domain to check if mail alias is correctly configured when there is no alias on the recruitment source.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#150645

In one of the schematron rules for CIUS-RO, there is a rule for DocumentTypeCode element in the XML that failed the validity test. ```sch <rule context="cac:AdditionalDocumentReference"> <assert id="UBL-SR-43" flag="fatal" test="((cbc:DocumentTypeCode='130') or ((local-name(/*) = 'CreditNote') and (cbc:DocumentTypeCode='50')) or (not(cbc:ID/@scheme) and not(cbc:DocumentTypeCode)))"> [UBL-SR-43]-Scheme identifier shall only be used for invoiced object (document type code wi

In one of the schematron rules for CIUS-RO, there is a rule for DocumentTypeCode element in the XML that failed the validity test.

```sch
<rule context="cac:AdditionalDocumentReference">
  <assert id="UBL-SR-43" flag="fatal" test="((cbc:DocumentTypeCode='130') or
  ((local-name(/*) = 'CreditNote') and (cbc:DocumentTypeCode='50')) or
  (not(cbc:ID/@scheme) and not(cbc:DocumentTypeCode)))">
    [UBL-SR-43]-Scheme identifier shall only be used for invoiced object
    (document type code with value 130)
  </assert>
</rule>
```

This commit fixes the current behavior by applying this behavior:
- DocumentTypeCode won't show up when exporting Invoice XML
- DocumentTypeCode will show up with the value '50' when exporting CreditNote XML

task-id: 3649426

Forward-Port-Of: odoo/odoo#150613

Commit [1] (later refactored by [2]) hid the buttons which allow to edit the main website menu and custom website menus (as the ones in event pages), when using Odoo on a mobile device. Reading the code and related commits, this seemed to have been done for no apparent reason. After testing 16.0, it appears that menu edition from mobile devices was actually not working: the re-ordering UI was strangely hidden. After investigation, it appears that this was solved by chance, thanks to the

Commit [1] (later refactored by [2]) hid the buttons which allow to
edit the main website menu and custom website menus (as the ones in
event pages), when using Odoo on a mobile device. Reading the code and
related commits, this seemed to have been done for no apparent reason.
After testing 16.0, it appears that menu edition from mobile devices was
actually not working: the re-ordering UI was strangely hidden.

After investigation, it appears that this was solved by chance, thanks
to the unrelated commit [3] in 16.2. That commit indeed removes legacy
CSS which was hiding all jQuery.ui.sortable UI elements by mistake.

In 17.0, this was further improved anyway by not using jQuery.ui anymore
(with [4]) and thus editing website menus from a mobile device works now
perfectly... except that the buttons to open the menus edition dialogs
were still hidden. This commit enables them. It was chosen to do it in
17.0 and not 16.2 as it is more an improvement than a fix in the end.

[1]: https://github.com/odoo/odoo/commit/78c59afd133de8308f4eeb6e1a2a930d870878e7
[2]: https://github.com/odoo/odoo/commit/2dc82504e08cc370b67cdf1d580f26705870a085
[3]: https://github.com/odoo/odoo/commit/ee3e28987eb1ec23b8bacc7c4043d9690aada144
[4]: https://github.com/odoo/odoo/commit/a4b1c268131ed771dd68616a26a9f1ce50a189f0

Related to task-3645985

Forward-Port-Of: odoo/odoo#150530

This commit improves the user experience with pdf quote builder by - showing document for both product template and product variants - providing pdf example for headers/footers task-3543479 Forward-Port-Of: odoo/odoo#146183

This commit improves the user experience with pdf quote builder by
- showing document for both product template and product variants
- providing pdf example for headers/footers

task-3543479

Forward-Port-Of: odoo/odoo#146183

One of our customers is receiving emails with headers and attachments encoded using the "iso-8859-8-i" charset instead of "iso-8859-8" which is natively supported by Python. Both encoding are using the same character set[^1] and only differ in the way the text is rendered on screen[^2][^3] which is not relevant for Python. Add an alias for iso-8859-8-i so that the emails that this customer receive stop failing in Odoo. Note that there is a PR opened on CPython for exactly that, see [bpo18624]

One of our customers is receiving emails with headers and attachments encoded using the "iso-8859-8-i" charset instead of "iso-8859-8" which is natively supported by Python. Both encoding are using the same character set[^1] and only differ in the way the text is rendered on screen[^2][^3] which is not relevant for Python.

Add an alias for iso-8859-8-i so that the emails that this customer receive stop failing in Odoo. Note that there is a PR opened on CPython for exactly that, see [bpo18624](https://bugs.python.org/issue18624).

[opw-3653210](https://www.odoo.com/web#id=3653210&cids=1&model=project.task&view_type=form)
[^1]: https://encoding.spec.whatwg.org/#legacy-single-byte-encodings
[^2]: <data:text/html;charset=iso-8859-8,hello%20%E0%E1%E2%E3>
[^3]: <data:text/html;charset=iso-8859-8-i,hello%20%E0%E1%E2%E3>

Forward-Port-Of: odoo/odoo#150467
Forward-Port-Of: odoo/odoo#149827

Description of the issue/feature this PR addresses: In some places I think it is necessary to use sudo to avoid permission errors when creating actions or something else from a other model. For example, I have a stock picking created from PO attached to MO. When receiving inventory in a smaller quantity than actual quantity, will create activity schedule on MO. But if you don't have the rights, you will get an error Desired behavior after PR is merged: --- I confirm I hav

Description of the issue/feature this PR addresses:

In some places I think it is necessary to use sudo to avoid permission
errors when creating actions or something else from a other model.

For example, I have a  stock picking created from PO attached to MO. When
receiving inventory in a smaller quantity than actual quantity, will
create activity schedule on MO. But if you don't have the rights, you
will get an error

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#150348

In a previous commit we fixed Swiss localization's taxes data. We changed two children taxes that had wrong tax_type_use since it depends on their parents. This could raise the python constraint `_check_children_scope()` which is preventing some databases to correctly update their taxes. See https://github.com/odoo/odoo/commit/7b07df873535446f97abc1de9176b9332de5cb07 Forward-Port-Of: odoo/odoo#150669 Forward-Port-Of: odoo/odoo#148724

In a previous commit we fixed Swiss localization's taxes data. We changed two children taxes that had wrong tax_type_use since it depends on their parents.
This could raise the python constraint `_check_children_scope()` which is preventing some databases to correctly update their taxes.

See https://github.com/odoo/odoo/commit/7b07df873535446f97abc1de9176b9332de5cb07

Forward-Port-Of: odoo/odoo#150669
Forward-Port-Of: odoo/odoo#148724

This branch fixes two related issues: Issue 1:A traceback issue in `hasColor` Issue 2: When partially select the text and some blank spaces, and change the background color, the background color picker is blinking all the time and cannot choose a color. More details about reproduction and fix are in the commit message Task-3476494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150500 Forward-Port-Of: odoo/odo

This branch fixes two related issues:

Issue 1:A  traceback issue in `hasColor`
Issue 2: When partially select the text and some blank spaces, and change the background color, the background color picker is blinking all the time and cannot choose a color. 

More details about reproduction and fix are in the commit message

Task-3476494


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#150500
Forward-Port-Of: odoo/odoo#133577

Patch module to add missing fields to the factura-e xml. task-3673113 Forward-Port-Of: odoo/odoo#149362

Patch module to add missing fields to the factura-e xml.

task-3673113

Forward-Port-Of: odoo/odoo#149362

Log the job duration of the usual `INFO` level for easier monitoring. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149881

Log the job duration of the usual `INFO` level for easier monitoring.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#149881

[FIX] web_editor, *: correctly display the hierarchy between elements *website Steps to reproduce: - Drop a "Text-Image" snippet on the website. - Click on a column and hide it on desktop. - Click on the parent snippet and hide it on desktop. -> The column is not a child of the parent in the invisible entry. Since [1], invisible snippets are shown hierarchically in order to better visualize the "parent-children" relation that could exist between them. To do so, [1] based its log

[FIX] web_editor, *: correctly display the hierarchy between elements

*website

Steps to reproduce:
- Drop a "Text-Image" snippet on the website.
- Click on a column and hide it on desktop.
- Click on the parent snippet and hide it on desktop.

-> The column is not a child of the parent in the invisible entry.

Since [1], invisible snippets are shown hierarchically in order to
better visualize the "parent-children" relation that could exist between
them. To do so, [1] based its logic on the `.o_snippet_invisible` to
find the invisible elements. However, since [2], a distinction has been
made between elements that are hidden only on desktop, only on mobile or
on both depending on some conditions. The goal of this commit is to take
the new `o_snippet_mobile_invisible` and `o_snippet_desktop_invisible`
classes into account at the creation of the invisible entry.

[1]: https://github.com/odoo/odoo/commit/922d3e63b597b1ef7fbbb5ebb4641a3ad8bdf4ed
[2]: https://github.com/odoo/odoo/commit/3103e0553011b5c1f4078972d7a88fa3fd4068b2

task-3679823

Forward-Port-Of: odoo/odoo#150512
Forward-Port-Of: odoo/odoo#149222

Since [1] a margin is applied when another `o_we_user_value_widget` follows a color palette. Unfortunately this is also applied when the two elements are not on the same row. Because of this the "Slideout Effect" option below the "Colors" option of "Footer" looks like it is indented while it is unrelated to the color selection. This commit restricts that margin to elements that belong to the a `we-row`. [1]: https://github.com/odoo/odoo/commit/2f81c6ae68751d5f93c30aef822730ee04ead391 ta

Since [1] a margin is applied when another `o_we_user_value_widget` follows a color palette. Unfortunately this is also applied when the two elements are not on the same row. Because of this the "Slideout Effect" option below the "Colors" option of "Footer" looks like it is indented while it is unrelated to the color selection.

This commit restricts that margin to elements that belong to the a `we-row`.

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

task-3696870

Forward-Port-Of: odoo/odoo#150614

This reverts commit 652edc38527b14995f017d514053a57825091813. It creates a new issue with valuation change. Steps to reproduce: -Create a new product with a cost of 10 (std, manual) -Create an inventory adjustment to set the quantity to -3 -Change the product's category to real-time -Now the valuation for this product is -30€, but the accounting part has 30€, creating a difference of 60€." A better solution to fix both issues has been tried but it was far from optimal. Since it's an e

This reverts commit 652edc38527b14995f017d514053a57825091813.

It creates a new issue with valuation change.

Steps to reproduce:
-Create a new product with a cost of 10 (std, manual) -Create an inventory adjustment to set the quantity to -3 -Change the product's category to real-time
-Now the valuation for this product is -30€, but the accounting part has 30€, creating a difference of 60€."

A better solution to fix both issues has been tried but it was far from optimal. Since it's an edge usecase we will not support it until master

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#149053
Forward-Port-Of: odoo/odoo#147949

This deadline is about completion, not review Task-3680802 Forward-Port-Of: odoo/odoo#149100

This deadline is about completion, not review

Task-3680802

Forward-Port-Of: odoo/odoo#149100

Steps to reproduce: ------------------- - install helpdesk_fsm and sale_timesheet; - to be in a multi-company environment; - create a new helpdesk team with "Timesheets", "Time Billing"; - the newly created project has no company; - create a service product that creates a task with UoM in hours in the newly created project for the helpdesk team; - create a sale order with this product with a quantity of 100 hours and confirm it; - in the helpdesk app (in the new team), create a ticket li

Steps to reproduce:
-------------------
- install helpdesk_fsm and sale_timesheet;
- to be in a multi-company environment;
- create a new helpdesk team with "Timesheets", "Time Billing";
- the newly created project has no company;
- create a service product that creates a task with UoM in hours in the newly created project for the helpdesk team;
- create a sale order with this product with a quantity of 100 hours and confirm it;
- in the helpdesk app (in the new team), create a ticket linked to the sale order line of the product (the customer is necessary);
- on the ticket the "Remaining Hours on SO" is 100 hours;
- create a timesheet directly in the tree view;
- the remaining hours of the sale order are reduced;
- create a timesheet from the timer;
- the remaining hours of the sale order are not reduced;

Cause:
------
During the link between the newly created timesheet and the ticket, we write to the `helpdesk_ticket_id` field (during the flush) in the `account.analytic.line` record. As a result, we pass in the override of the `write` method, which calls `_timesheet_preprocess`. Without a company on the project (or on the analytic account if there is one), the value `{'product_uom_id': False}` will be added to the values to be written to the timesheet. Without a unit of measurement, the timesheet will not be used to calculate the remaining hours.

Solution:
---------
Add a fallback on the current company if no company is found.

opw-3651830

Forward-Port-Of: odoo/odoo#149917
Forward-Port-Of: odoo/odoo#149893

## Description Add missing index to speed up queries related to the P&L reports. As the report queries per `account_type` it's beneficial to have it indexed. The field is not write heavy, and has low count of distinct values ( since it's a selection field), so there is little downside of having it. It is meant to support the changes done in the related enterprise PR. ## Reference opw-3659497 Enterprise PR: https://github.com/odoo/enterprise/pull/53817 --- I confirm I have signed the CL

## Description
Add missing index to speed up queries related to the P&L reports. As the report queries per `account_type` it's beneficial to have it indexed. The field is not write heavy, and has low count of distinct values ( since it's a selection field), so there is little downside of having it. It is meant to support the changes done in the related enterprise PR.

## Reference
opw-3659497
Enterprise PR: https://github.com/odoo/enterprise/pull/53817

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#148490

**Description of the issue/feature this PR addresses:** The unit tests introduced in 4820be3c only work if pdfminer is installed. As it's an optional dependency, it may not be installed in some environments. This commit skips the tests if pdfminer is not installed. See also: 6fa4dbf2 ping @Xavier-Do --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147720

**Description of the issue/feature this PR addresses:**

The unit tests introduced in 4820be3c only work if pdfminer is installed. As it's an optional dependency, it may not be installed in some environments.

This commit skips the tests if pdfminer is not installed.

See also: 6fa4dbf2


ping @Xavier-Do 

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#147720

**Before this PR**: The label for the `sms_subject` field incorrectly displayed as 'Subject,' which was misleading as SMS messages do not have a subject like emails. **After this PR**: The label has been changed to 'Title' which is appropriate for SMS **Task**-3500573 Forward-Port-Of: odoo/odoo#149815 Forward-Port-Of: odoo/odoo#135794

**Before this PR**:
The label for the `sms_subject` field incorrectly displayed as 'Subject,' which was misleading as SMS messages do not have a subject like emails.

**After this PR**:
The label has been changed to 'Title' which is appropriate for SMS

**Task**-3500573

Forward-Port-Of: odoo/odoo#149815
Forward-Port-Of: odoo/odoo#135794

In https://github.com/odoo/odoo/pull/105119, new accounts were added to represent employee-related expenses. Based on the non-official document https://swissdec.ch/document/share/295/4cc46aca-8b47-49e9-882a-03c37eb8dea3 we used account codes 2990 and 2999 for accounts 'Indemnities' and 'Company Car Correction'. However, these accounts have no place with the equity accounts in 29xx, since they are not equity but rather expense accounts. Examples of CoAs that include employee indemnity accounts

In https://github.com/odoo/odoo/pull/105119, new accounts were added to represent employee-related expenses. Based on the non-official document https://swissdec.ch/document/share/295/4cc46aca-8b47-49e9-882a-03c37eb8dea3 we used account codes 2990 and 2999 for accounts 'Indemnities' and 'Company Car Correction'.

However, these accounts have no place with the equity accounts in 29xx, since they are not equity but rather expense accounts. Examples of CoAs that include employee indemnity accounts place them under account group 5 with the other employee-related expenses.

(e.g. https://plancompta.com/plan-comptable-suisse-pcg-2021/)

As such, we move accounts 2990 Indemnities -> 5840 and 2999 Company Car Correction -> 5031.

Fixing this in stable will not cause any in-database corruption, since the updated code is only executed when the CoA is loaded/reloaded. However, users will need to reload the CoA in order to take advantage of the fix.

This also ensures that the Swiss Balance Sheet is balanced.

Community PR: https://github.com/odoo/odoo/pull/150692

taskid:3060790

Forward-Port-Of: odoo/enterprise#54941

The fix proposed in 5d19c678 was not thorough as the pivot formula present in the demo sheet will call `name_get` on given record ids that are likely not existing without the demo data (see [1]). This revision adds a dedicated spreasheet file that goes around that problem and limits the name_get calls to actual data (in this case, rely on the country_ids). [1] https://runbot.odoo.com/runbot/build/54397846 Forward-Port-Of: odoo/enterprise#54973 Forward-Port-Of: odoo/enterprise#51734

The fix proposed in 5d19c678 was not thorough as the pivot formula present in the demo sheet will call `name_get` on given record ids that are likely not existing without the demo data (see [1]). This revision adds a dedicated spreasheet file that goes around that problem and limits the name_get calls to actual data (in this case, rely on the country_ids).

[1] https://runbot.odoo.com/runbot/build/54397846

Forward-Port-Of: odoo/enterprise#54973
Forward-Port-Of: odoo/enterprise#51734

Forward-Port-Of: odoo/enterprise#49300

Forward-Port-Of: odoo/enterprise#49300

…lation Forward-Port-Of: odoo/enterprise#54928

…lation

Forward-Port-Of: odoo/enterprise#54928

In the US it is necessary to show the Social Security number (SSN) and hide the first 5 numbers (ex: XXXXX1234). When we print the Payslip of an employee with or without an SSN in their record (hr.employee), an extra number chain is added to the printed Payslip. The mask XXX-XX should only be applied when there is a number and it should overwrite the 5 first characters, not be pasted before. Task link: http://www.odoo.com/web#id=3630674&model=project.task task-3630674 Forward-Port-Of: o

In the US it is necessary to show the Social Security number (SSN) and hide the first 5 numbers (ex: XXXXX1234). When we print the Payslip of an employee with or without an SSN in their record (hr.employee), an extra number chain is added to the printed Payslip.

The mask XXX-XX should only be applied when there is a number and it should overwrite the 5 first characters, not be pasted before. 

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

Forward-Port-Of: odoo/enterprise#52512

### Steps to reproduce * install `account_accountant` * create payments in the CASH and BANK journal * go to the accounting dashboard * click 'payments' for the BANK or CASH journal You should see that the newly opened list view displays all the unreconciled payments, from all journals. It should only display the payments from the journal you clicked. opw-3688740 Forward-Port-Of: odoo/enterprise#54936 Forward-Port-Of: odoo/enterprise#54524

### Steps to reproduce

* install `account_accountant`
* create payments in the CASH and BANK journal
* go to the accounting dashboard
* click 'payments' for the BANK or CASH journal

You should see that the newly opened list view displays all the unreconciled payments, from all journals. It should only display the payments from the journal you clicked.

opw-3688740

Forward-Port-Of: odoo/enterprise#54936
Forward-Port-Of: odoo/enterprise#54524

The field ´has_payment_method´ (approval_category.py) is not related to anything but is rendered in form view. Steps to reproduce: ------------------- * Open ´Approvals´ app * Select ´Configuration´ * Select ´Approval Types´ * Select any type Why the fix: ------------ The field is never used anywhere. opw-616042 Forward-Port-Of: odoo/enterprise#54237

The field ´has_payment_method´ (approval_category.py) is not related to anything but is rendered in form view.

Steps to reproduce:
-------------------
* Open ´Approvals´ app
* Select ´Configuration´
* Select ´Approval Types´
* Select any type

Why the fix:
------------
The field is never used anywhere.

opw-616042

Forward-Port-Of: odoo/enterprise#54237

Forward-Port-Of: odoo/enterprise#54799

Forward-Port-Of: odoo/enterprise#54799

This commit add the Lithuanian intrastat report. This comes with the possibility to export that report into an XML file and also adds the country region code. task-3248669 Forward-Port-Of: odoo/enterprise#54841 Forward-Port-Of: odoo/enterprise#46488

This commit add the Lithuanian intrastat report. This comes with the possibility to export that report into an XML file and also adds the country region code.

task-3248669

Forward-Port-Of: odoo/enterprise#54841
Forward-Port-Of: odoo/enterprise#46488

Sanitizes phone numbers before using them to build request URIs. This will prevent failure whenever a phone number contains spaces. Task-3689342. Forward-Port-Of: odoo/enterprise#54535

Sanitizes phone numbers before using them to build request URIs. This will prevent failure whenever a phone number contains spaces.

Task-3689342.

Forward-Port-Of: odoo/enterprise#54535

Before this fix, when the tax closing was posted, though the tax lock date was properly updated, the default external values (computed from _default expressions) of the tax report were not computed. It only worked when setting the tax lock date manually from the lock wizard. We take advantage of this commit to improve the test suite in order to check all possible cases for the creation of default external values. Forward-Port-Of: odoo/enterprise#54751 Forward-Port-Of: odoo/enterprise#54080

Before this fix, when the tax closing was posted, though the tax lock date was properly updated, the default external values (computed from _default expressions) of the tax report were not computed. It only worked when setting the tax lock date manually from the lock wizard.

We take advantage of this commit to improve the test suite in order to check all possible cases for the creation of default external values.

Forward-Port-Of: odoo/enterprise#54751
Forward-Port-Of: odoo/enterprise#54080

Many tests were giving the name `payment_method` to variables that are actually storing a payment token. This conflicted with the `payment_method` variable being added to `PaymentCommon`. See also: - https://github.com/odoo/odoo/pull/149833 Forward-Port-Of: odoo/enterprise#54930

Many tests were giving the name `payment_method` to variables that are actually storing a payment token. This conflicted with the `payment_method` variable being added to `PaymentCommon`.

See also:
- https://github.com/odoo/odoo/pull/149833

Forward-Port-Of: odoo/enterprise#54930

This context key isn't used anymore. It has been replaced by options['export_mode']. The former calls with the context key corresponded to the generation of pdf exports, and are all converted to 'print', except the one in integer rounding management, for which we rather wish to use the 'file' value. Indeed, when integer rounding is enabled, the pdf must keep the same content as what was shown in the UI, while a file export will always want the legal standard (hence, rounding) to be applied. For

This context key isn't used anymore. It has been replaced by options['export_mode']. The former calls with the context key corresponded to the generation of pdf exports, and are all converted to 'print', except the one in integer rounding management, for which we rather wish to use the 'file' value. Indeed, when integer rounding is enabled, the pdf must keep the same content as what was shown in the UI, while a file export will always want the legal standard (hence, rounding) to be applied.

Forward-Port-Of: odoo/enterprise#54561

`relativedelta`'s `year` is absolute whereas `years` is relative. In our case, we need to go back 2 years relatively to the current date, therefore we should use `years`. Forward-Port-Of: odoo/enterprise#54934

`relativedelta`'s `year` is absolute whereas `years` is relative. In our case, we need to go back 2 years relatively to the current date, therefore we should use `years`.

Forward-Port-Of: odoo/enterprise#54934

When you have to sign an offer and have a bike on your previous contract, the amount is correct, but the selected bike is not the good one. It is because you own bike is not availbale in the list. So we add it. Forward-Port-Of: odoo/enterprise#54905

When you have to sign an offer and have a bike on your previous contract, the amount is correct, but the selected bike is not the good one.

It is because you own bike is not availbale in the list. So we add it.

Forward-Port-Of: odoo/enterprise#54905

Objective --------- Add the Bulgarian National Bank (BNB) as a Currency Provider in Odoo. Solution --------- Rates are given against BGN in an XML file of format: ``` <ROWSET> <ROW> <GOLD>1</GOLD> <NAME_>Currency</NAME_> <CODE>Code</CODE> <RATIO>Per unit of currency/gold</RATIO> <REVERSERATE>Reverse rate for 1 BGN</REVERSERATE> <RATE>Levs (BGN)</RATE> <CURR_DATE>Date</CURR_DATE> <F_STAR>0</F_STAR> </ROW> </ROWSET> ``` Source: https://w

Objective
---------
Add the Bulgarian National Bank (BNB) as a Currency Provider in Odoo.

Solution
---------
Rates are given against BGN in an XML file of format:

```
<ROWSET>
  <ROW>
    <GOLD>1</GOLD>
    <NAME_>Currency</NAME_>
    <CODE>Code</CODE>
    <RATIO>Per unit of currency/gold</RATIO>
    <REVERSERATE>Reverse rate for 1 BGN</REVERSERATE>
    <RATE>Levs (BGN)</RATE>
    <CURR_DATE>Date</CURR_DATE>
    <F_STAR>0</F_STAR>
 </ROW>
</ROWSET>
```

Source: https://www.bnb.bg/AboutUs/AUFAQ/Contr_Exchange_Rates_FAQ?toLang=_EN

Currencies returned on the 8th of January 2024:
    AUD, BRL, CAD, CHF, CNY, CZK, DKK, GBP, HKD, HUF, IDR, ILS, INR,
    ISK, JPY, KRW, MXN, MYR, NOK, NZD, PHP, PLN, RON, RUB*, SEK, SGD,
    THB, TRY, USD, ZAR, XAU
* Due to the situation on the international financial markets, the Bulgarian National Bank (BNB) is not in a position to set a reference exchange rate for the Bulgarian Lev against the Russian Rouble that is representative of market conditions.

task-3672394

Forward-Port-Of: odoo/enterprise#54879
Forward-Port-Of: odoo/enterprise#53914

Impacted Version: - 16.0 and above This commit improve below features: - Simplify demo data and remove unnessary function call - Improve demo_payslip_2 date_to for leap year - Improve leaves to avoid overlapping weekend X-original-commit: 45321a2 Forward-Port-Of: odoo/enterprise#54836 Forward-Port-Of: odoo/enterprise#54283

Impacted Version:

- 16.0 and above

This commit improve below features:

- Simplify demo data and remove unnessary function call
- Improve demo_payslip_2 date_to for leap year
- Improve leaves to avoid overlapping weekend

X-original-commit: 45321a2

Forward-Port-Of: odoo/enterprise#54836
Forward-Port-Of: odoo/enterprise#54283

Before this commit, when a contract was reopened, the churn log was removed but it was not the last one. After this commit, we make sure to delete the last churn log after sorting by date. taskid: 3651477 Forward-Port-Of: odoo/enterprise#54730 Forward-Port-Of: odoo/enterprise#54056

Before this commit, when a contract was reopened, the churn log was removed but it was not the last one. After this commit, we make sure to delete the last churn log after sorting by date.

taskid: 3651477

Forward-Port-Of: odoo/enterprise#54730
Forward-Port-Of: odoo/enterprise#54056

A collection of small but urgent fixes for the shop floor app. Please refer to the individual feature commits for more details. Task: 3651433 Forward-Port-Of: odoo/enterprise#53516

A collection of small but urgent fixes for the shop floor app.
Please refer to the individual feature commits for more details.

Task: 3651433

Forward-Port-Of: odoo/enterprise#53516

## Description Opening a P&L report and doing some grouping by an analytic account or an analytic plan can be extremely slow. This is due to the fact that, in the goal of reusing the generic report engine, which is based on `account.move.line`, a temporary table is created that shadows said table, but overwrite the data with content from `account.analytic.line` instead. The temporary table has absolutely no indexes, therefor forcing a Seq.Scan for all queries done on the table. As the `accou

## Description
Opening a P&L report and doing some grouping by an analytic account or an analytic plan can be extremely slow.
This is due to the fact that, in the goal of reusing the generic report engine, which is based on `account.move.line`, a temporary table is created that shadows said table, but overwrite the data with content from `account.analytic.line` instead.
The temporary table has absolutely no indexes, therefor forcing a Seq.Scan for all queries done on the table. As
the `account.analytic.line` model can grow quite large in general, sequential scans on that table quickly becomes slow.

## Fix
We introduce 1 composite index on the temporary table to speed up the subsequent queries on it.
This slows down the initial creation of the temporary table, at the benefit of significantly speeding up all report sections queries, which are done for each `account_type`. Since the temporary table has no traffic on it, the exclusive lock on the table for the index creation is immediately acquired, so the time taken to build the index is proportional to the size of the table. The index is dropped when the temporary table is dropped.

## Benchmark
Durations of the request `get_report_informations` for a P&L report of the last fiscal year, all journals, and grouping by 1 analytic plan of a database with a bit above 200k AAL:

| AAL Volume | Before | After |
|------------|--------|-------|
| 50k        | 4.75s  | 1s    |
| 100k       | 9s     | 1.4s  |
| 200k       | 21s    | 2.1s  |

(in the last line, the 2.1s -> 1.2s is for the index creation + analyze) Scaling is also better when it comes to grouping by more analytic accounts or plans.

## Reference
opw-3659497
Community PR: https://github.com/odoo/odoo/pull/148490

Forward-Port-Of: odoo/enterprise#53817

Before this commit: while creating an activity, the label for the `subject` field is displayed as 'Subject' for both the Email template and SMS template which was misleading as the SMS does not have a subject like emails. After this commit: The label has been changed to 'Title' which is appropriate for SMS Task-3500573 Forward-Port-Of: odoo/enterprise#54553 Forward-Port-Of: odoo/enterprise#53484

Before this commit:
while creating an activity, the label for the `subject` field is displayed as 'Subject' for both the Email template and SMS template  which was misleading as the SMS does not have a subject like emails.

After this commit:
The label has been changed to 'Title' which is appropriate for SMS

Task-3500573

Forward-Port-Of: odoo/enterprise#54553
Forward-Port-Of: odoo/enterprise#53484

Before this, clicking the "Compute Taxes" button on a confirmed sale order does nothing. It was possible in previous versions to re-calculate taxes on confirmed sale orders and it's especially handy on subscriptions. Furthermore, it's possible to manually change the taxes on confirmed sale orders anyway, so there's no reason to prevent changing them through an external tax integration. opw-3694079 Forward-Port-Of: odoo/enterprise#54979

Before this, clicking the "Compute Taxes" button on a confirmed sale order does nothing. It was possible in previous versions to re-calculate taxes on confirmed sale orders and it's especially handy on subscriptions. Furthermore, it's possible to manually change the taxes on confirmed sale orders anyway, so there's no reason to prevent changing them through an external tax integration.

opw-3694079

Forward-Port-Of: odoo/enterprise#54979