this commit https://github.com/odoo/odoo/pull/158788/commits/07e2fca9e39e9c32182f10bae6ba814a4241b6bf uses `qty_done` instead of `quantity` in test `test_valuation_with_backorder` Forward-Port-Of: odoo/odoo#159248

this commit https://github.com/odoo/odoo/pull/158788/commits/07e2fca9e39e9c32182f10bae6ba814a4241b6bf uses `qty_done` instead of `quantity` in test
`test_valuation_with_backorder`

Forward-Port-Of: odoo/odoo#159248

Example of steps: - Open any record with a chatter - Log a note - Edit it - Try to save Actually it is impossible to save it, because we can not perform a CTRL+ENTER in mobile and there is no button This commit adds a button to save editing, using `fa-paper-plane` icon similarly to send button. opw-3784145 Forward-Port-Of: odoo/odoo#159092

Example of steps:
- Open any record with a chatter
- Log a note
- Edit it
- Try to save

Actually it is impossible to save it, because we can not perform a CTRL+ENTER in mobile and there is no button

This commit adds a button to save editing, using `fa-paper-plane` icon similarly to send button.

opw-3784145

Forward-Port-Of: odoo/odoo#159092

This commit adapts `base_import`'s background that was too dark compared to other modules. This was caused by the use of a `bg-white` class that is not very "dark-mode friendly" as it will display as a pure black, which is not visually appealing and not wanted. This commit also adapts the background color of the sidebar to make it more consistent with other modules. We also add a `bg-view` class to the table, so it stands out more in light mode and stays the same in dark mode. task-3814

This commit adapts `base_import`'s background that was too dark compared to other modules. This was caused by the use of a `bg-white` class that is not very "dark-mode friendly" as it will display as a pure black, which is not visually appealing and not wanted.

This commit also adapts the background color of the sidebar to make it more consistent with other modules.

We also add a `bg-view` class to the table, so it stands out more in light mode and stays the same in dark mode.

task-3814508

| Before | After |
|--------|--------|
| <img width="1728" alt="Screenshot 2024-03-22 at 08 32 26" src="https://github.com/odoo/odoo/assets/110090660/85c0d0bf-19af-4a19-aa1b-cf990a6147d8"> | <img width="1728" alt="Screenshot 2024-03-22 at 08 34 08" src="https://github.com/odoo/odoo/assets/110090660/dfe7198a-c011-4ead-bf6f-cfba50db93a9"> |
| <img width="1726" alt="Screenshot 2024-03-22 at 08 32 42" src="https://github.com/odoo/odoo/assets/110090660/ed5914c2-bf1c-44ee-baa6-58fb5f537d9a"> | <img width="1725" alt="Screenshot 2024-03-22 at 08 34 19" src="https://github.com/odoo/odoo/assets/110090660/fb80a723-d1d0-4d44-aded-d603385cce70"> |
| <img width="1714" alt="Screenshot 2024-03-22 at 08 59 52" src="https://github.com/odoo/odoo/assets/110090660/98c543a0-05dd-4b71-b5bf-9d702f513fb4"> | <img width="1715" alt="Screenshot 2024-03-22 at 08 57 41" src="https://github.com/odoo/odoo/assets/110090660/4005b050-4a2a-4137-b6c0-47ecbdbe89a7"> | 
| <img width="1726" alt="Screenshot 2024-03-22 at 08 33 08" src="https://github.com/odoo/odoo/assets/110090660/fde063f8-48f5-4ae2-a5c1-b1973d94f0b3"> | <img width="1728" alt="Screenshot 2024-03-22 at 08 33 59" src="https://github.com/odoo/odoo/assets/110090660/b5875104-7d6f-4a36-8303-0cf7c14c113d"> | 
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#158822
Forward-Port-Of: odoo/odoo#158019

…ail_account: fix Send & Print only Clean the implementation + missing peppol, ubl and snailmail. Forward-Port-Of: odoo/odoo#157977

…ail_account: fix Send & Print only

Clean the implementation + missing peppol, ubl and snailmail.

Forward-Port-Of: odoo/odoo#157977

Refactored the restrict_parnter_id check in the stock_account module to make it more flexible for future updates.The The purpose of this refactoring is to prepare for a custom module that will value inventory based on specific ownership. Related: https://github.com/OCA/stock-logistics-workflow/pull/1548 @qrtl QT4334 Forward-Port-Of: odoo/odoo#158343

Refactored the restrict_parnter_id check in the stock_account module to make it more flexible for future updates.The The purpose of this refactoring is to prepare for a custom module that will value inventory based on specific ownership.
Related: https://github.com/OCA/stock-logistics-workflow/pull/1548

@qrtl QT4334

Forward-Port-Of: odoo/odoo#158343

Steps to reproduce: ------------------- - be in a UTC+08:00 (or more) timezone - go to Time Off dashboard - click on a day (to request a leave) Issue: ------ Default request dates are on 2 days instead of 1. Cause: ------ Default request dates are determined during an onchange. The datetimes (`default_date_from/to`) are set in the context in UTC calculated in relation to the client's timezone. Consequently, these datetimes can be set over several days. In the backend, we will use

Steps to reproduce:
-------------------
- be in a UTC+08:00 (or more) timezone
- go to Time Off dashboard
- click on a day (to request a leave)

Issue:
------
Default request dates are on 2 days instead of 1.

Cause:
------
Default request dates are determined during an onchange. The datetimes (`default_date_from/to`) are set in the context in UTC calculated in relation to the client's timezone.
Consequently, these datetimes can be set over several days. In the backend, we will use these datetimes and take only the day (because the `request_date_from/to` fields are of type date).

Solution:
---------
Put the values back into the client's timezone before they are truncated.

opw-3789265

Forward-Port-Of: odoo/odoo#158042

opw-3709064 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157836

opw-3709064

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

Forward-Port-Of: odoo/odoo#157836

### Move common scss into web Prior to this PR, some of the main styles related to event elements in calendars were set in the `calendar` module. This created layout issues when we installed independent modules without installing `calendar` (eg. `planning` or `hr_payroll`). To fix that, this PR moves the necessary styles into `web` and manages duplicated styles in order to remove them. ### Adjust hatched events for planning Prior to this commit, the "hatched" event style in Planning was

### Move common scss into web
Prior to this PR, some of the main styles related to event elements in calendars were set in the `calendar` module.
This created layout issues when we installed independent modules without installing `calendar` (eg. `planning` or `hr_payroll`).

To fix that, this PR moves the necessary styles into `web` and manages duplicated styles in order to remove them.

### Adjust hatched events for planning
Prior to this commit, the "hatched" event style in Planning wasn't displayed in Day and Week views.
This commit adjusts the css selector to fix this issue.

---
task-3617329
Part of task-3575827

---
| Before | After |
|--------|--------|
| ![Capture d’écran 2024-02-22 à 08 30 37](https://github.com/odoo/odoo/assets/80679690/a6a33398-522e-471c-ab75-884f72c214cc) | ![Capture d’écran 2024-02-22 à 08 43 32](https://github.com/odoo/odoo/assets/80679690/e6c07aac-8273-4772-a759-64c03ee125e5) |
| ![Capture d’écran 2024-02-22 à 08 31 10](https://github.com/odoo/odoo/assets/80679690/0ac54c01-a39b-45dd-afeb-5bcc29c912ae) | ![Capture d’écran 2024-02-22 à 08 44 50](https://github.com/odoo/odoo/assets/80679690/d0a69d3f-e68f-4c7f-97d1-e33c14c6f8bd) | 

| Before | After |
|--------|--------|
| ![Capture d’écran 2024-03-25 à 11 00 46](https://github.com/odoo/odoo/assets/80679690/d866eadf-5c04-451c-a98e-4af7789f6d08) | ![Capture d’écran 2024-03-25 à 11 01 06](https://github.com/odoo/odoo/assets/80679690/216ddadb-8e02-4522-a7dc-cf3f6f71069e) |


---

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

Forward-Port-Of: odoo/odoo#154964

Currently, an analytic account is created when confirming a quotation for a product created as follow: 1. Enable `Can be Expensed` 2. Select `At cost` for Re-invoice expenses 3. Disable `Can be expensed` Steps to reproduce: ------------------- * Install **sale_management** and **hr_expense** * Go to **Settings** * Under `Customer Invoices`, enable `Intrastat` -> Save * Under `Analytics`, enable `Analytic Accounting` * Go to **Sales** * Create 3 products * Product 1: Default *

Currently, an analytic account is created when confirming a quotation for a product created as follow:
1. Enable `Can be Expensed`
2. Select `At cost` for Re-invoice expenses
3. Disable `Can be expensed`

Steps to reproduce:
-------------------
* Install **sale_management** and **hr_expense**
* Go to **Settings**
* Under `Customer Invoices`, enable `Intrastat` -> Save
* Under `Analytics`, enable `Analytic Accounting`
* Go to **Sales**
* Create 3 products
  * Product 1: Default
  * Product 2:
    * Enable `Can be Expensed`
    * Select `At cost` for Re-invoice expenses
  * Product 3: 
    * Enable `Can be Expensed` 
    * Select `At cost` for Re-invoice expenses 
    * Disable `Can be expensed`
* For each product, repeat:
  * Create a quotation, select a customer
  * Add the product
  * Confirm
  * Select tab `Other Info`
  * Check the analytic account

**Observations:**
* Product 1: No analytic account created
* Product 2: Analytic account created
* Product 3: Analytic account created

Why the fix:
------------
The creation of the analytic account depends on the value of `expense_policy`. When the value is `no`, no analytic account is created. Whereas when the value is `cost`, an analytic account is created.

https://github.com/odoo/odoo/blob/57ad9c05014ca0219d7892c1ff8a2e949fab3c49/addons/sale/models/sale_order.py#L853-L856

In this workflow, `expense_policy` is visible only when `Can be expensed` is enabled. If you select an `expense_policy` then disable `Can be expensed`, the value for the `expense_policy` stays as previously selected.

https://github.com/odoo/odoo/blob/3e320ffe0ff4d1c6bb7d0314f36dd13ad1cf23f4/addons/sale_expense/models/product_template.py#L33-L41

opw-3706305

Forward-Port-Of: odoo/odoo#159084
Forward-Port-Of: odoo/odoo#154153

Steps to reproduce: - Go to website in "Edit" mode (on a blog post page). - Select one of the default images in the blog content. - Click on the "Animation" option and select "On Hover" > Traceback! Starting from [1], the "On hover" image animation was implemented to be able to pick an animation that triggers when hovering an image. This feature is setting a default "Square" shape (required for the hover effects to work) on the target. Which means that an error can always occur if t

Steps to reproduce:

- Go to website in "Edit" mode (on a blog post page).
- Select one of the default images in the blog content.
- Click on the "Animation" option and select "On Hover" > Traceback!

Starting from [1], the "On hover" image animation was implemented to be able
to pick an animation that triggers when hovering an image.

This feature is setting a default "Square" shape (required for the hover effects
to work) on the target. Which means that an error can always occur if the
"On Hover" animation option is available while the targeted image is not linked
to an attachment and can't support image shapes (which is the case here).

The goal of this commit is to fix this issue by only allowing the "On Hover"
animations when it's possible to apply shapes to the image.

[1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85

opw-3795599

Forward-Port-Of: odoo/odoo#158433

Bug === 1. login as demo user 2. add a review on a course and upload an attachment 3. click on the attachment link => You get a 404 error For some reason, we do not return the access token if the user is internal. The generation is not a heavy process, and might be needed depending on the <ir.rule>. Task-3693072 Forward-Port-Of: odoo/odoo#159126 Forward-Port-Of: odoo/odoo#156659

Bug
===
1. login as demo user
2. add a review on a course and upload an attachment
3. click on the attachment link => You get a 404 error

For some reason, we do not return the access token if the user is internal. The generation is not a heavy process, and might be needed depending on the <ir.rule>.

Task-3693072

Forward-Port-Of: odoo/odoo#159126
Forward-Port-Of: odoo/odoo#156659

**Current behavior before PR:** When attempting to copy a button that is a direct child of a div tag, the div was unintentionally copied along with the button, leading to additional space upon pasting, along with the background color. **Desired behavior after PR is merged:** Now, only the button will be copied and pasted. task-3764652 Forward-Port-Of: odoo/odoo#158975 Forward-Port-Of: odoo/odoo#155212

**Current behavior before PR:**

When attempting to copy a button that is a direct child of a div tag, the div was unintentionally copied along with the button, leading to additional space upon pasting, along with the background color.

**Desired behavior after PR is merged:**

Now, only the button will be copied and pasted.

task-3764652

Forward-Port-Of: odoo/odoo#158975
Forward-Port-Of: odoo/odoo#155212

When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them. Example (formatted): ```sql SELECT "mrp_routing_workcenter".id FROM "mrp_routing_workcenter" LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id" ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id" WHERE "mrp_rou

When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them.

Example (formatted):
```sql
    SELECT "mrp_routing_workcenter".id
      FROM "mrp_routing_workcenter"
 LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
        ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
     WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
       AND (  ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE ("mrp_bom"."company_id" in (1))
                   )
              )
           OR ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE "mrp_bom"."company_id" IS NULL
                   )
              )
           )
  ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
           "mrp_routing_workcenter__bom_id"."id",
           "mrp_routing_workcenter"."sequence",
           "mrp_routing_workcenter"."id"
```

If we use the single term version the generated query has only one sub-query:
```sql
    SELECT "mrp_routing_workcenter".id
      FROM "mrp_routing_workcenter"
 LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
        ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
     WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
       AND (  ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE (("mrp_bom"."company_id" in (1))
                        OR  ("mrp_bom"."company_id" IS NULL))
                   )
              )
           )
  ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
           "mrp_routing_workcenter__bom_id"."id",
           "mrp_routing_workcenter"."sequence",
           "mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in better execution times.

Also, the `company_id` field is required on some models, so the "= False" comparison is useless.

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#159123
Forward-Port-Of: odoo/odoo#157861

Before this PR: 1. When an empty heading from H4 to H6 is the only element in the editable area, the backspace key doesn't turn it into paragraphs. 2. When the cursor is at the start of a heading element with text content, and the user hits the backspace key, the element gets converted into a paragraph. After this PR: All heading elements are removed on backspace if they're empty. task-3456815 Forward-Port-Of: odoo/odoo#132778

Before this PR:

1. When an empty heading from  H4 to H6 is the only element in the editable 
     area, the backspace key doesn't turn it into paragraphs.
2. When the cursor is at the start of a heading element with text content, and the 
    user hits the backspace key, the element gets converted into a paragraph.

After this PR:

All heading elements are removed on backspace if they're empty.

task-3456815

Forward-Port-Of: odoo/odoo#132778

**Current behavior:** Trying to select the Algerian fiscal localization for a company after installing the respective module is impossible. **Expected behavior:** The localization package should be installable after the module has been installed. **Steps to reproduce:** 1. Install `l10n_dz` and create a new company without any fiscal localization 2. In the fresh company, select `Algeria` as the fiscal localization package, observe the error **Cause of the issue:** Two tax names i

**Current behavior:**
Trying to select the Algerian fiscal localization for a company after installing the respective module is impossible.

**Expected behavior:**
The localization package should be installable after the module has been installed.

**Steps to reproduce:**
1. Install `l10n_dz` and create a new company without any fiscal localization

2. In the fresh company, select `Algeria` as the fiscal localization package, observe the error

**Cause of the issue:**
Two tax names in the module's tax data file have the same values for a field that should be unique.

**Fix:**
Change the values in the identical fields.

opw-3787096

Forward-Port-Of: odoo/odoo#157198

This prevents a traceback\* which happens when the webrtc connection is under signaling stress and a local rollback is triggered when the state has been set back to stable. This seems to be caused by browser bugs (both in [Firefox](<https://bugzilla.mozilla.org/show_bug.cgi?id=1628139>) and in [Chromium](<https://issues.chromium.org/issues/40132342>) due to an [error](<https://github.com/w3c/webrtc-pc/issues/2508>) in the webrtc spec) that occur under stress. To prevent this sort of issue, a

This prevents a traceback\* which happens when the webrtc connection is under signaling stress and a local rollback is triggered when the state has been set back to stable.

This seems to be caused by browser bugs (both in [Firefox](<https://bugzilla.mozilla.org/show_bug.cgi?id=1628139>) and in [Chromium](<https://issues.chromium.org/issues/40132342>) due to an [error](<https://github.com/w3c/webrtc-pc/issues/2508>) in the webrtc spec) that occur under stress. To prevent this sort of issue, a solution was provided in the form of an [implicit rollback](<https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/setRemoteDescription#browser_compatibility>) on the remote description setter. This solution has recently become available everywhere (since Safari adopted it in [2022](<https://caniuse.com/mdn-api_rtcpeerconnection_setremotedescription_implicit_rollback>) for desktop and iOS).

This allows us to simply rely on the remote description setter to handle the rollback if needed.

\* Traceback: InvalidStateError: Cannot rollback local description in stable.

task-3823100

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

Forward-Port-Of: odoo/odoo#158861

Issue ----- The sale confirmation mail template is not rendered because a part of code is translated. Note: there's currently no Norwegian translation on Transifex for this version opw-3809578 Forward-Port-Of: odoo/odoo#158770

Issue
-----
The sale confirmation mail template is not rendered because a part of code is translated.

Note: there's currently no Norwegian translation on Transifex for this version

opw-3809578

Forward-Port-Of: odoo/odoo#158770

Reversing an invoice wizard provides an option to use the original entry date, but does not set the invoice_date to the same date. This behaviour is strange because the UI displays today's date, but the move is actually posted on a different date. This commit, keeps the dates in sync. Source: https://github.com/odoo/odoo/pull/93609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158640 Forward-Port-Of: odoo/odoo#1

Reversing an invoice wizard provides an option to use the original entry date, but does not set the invoice_date to the same date. This behaviour is strange because the UI displays today's date, but the move is actually posted on a different date.

This commit, keeps the dates in sync.
Source: https://github.com/odoo/odoo/pull/93609




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

Forward-Port-Of: odoo/odoo#158640
Forward-Port-Of: odoo/odoo#158530

Create a Loyalty program: - Program Type: Loyalty Cards - Rules: 0.01 per $ spent - Reward: 1.00 per point on cheapest product Make a SO with total 339 Loyalty Card will get 3.39 points Make a SO with line having - Unit Price 140 - Tax 15% - Total will be 161 Hit Promotions Issue: The system will add a discount line with unit price 5.0. With 15% taxes applied the total discount will be 5.75 While it should be 5 Order 1, Total with tax 339 => 3.39 loyalty points Order 2, Tot

Create a Loyalty program:
- Program Type: Loyalty Cards
- Rules: 0.01 per $ spent
- Reward: 1.00 per point on cheapest product

Make a SO with total 339
Loyalty Card will get 3.39 points
Make a SO with line having
- Unit Price 140
- Tax 15%
- Total will be 161

Hit Promotions

Issue:
The system will add a discount line with unit price 5.0.
With 15% taxes applied the total discount will be 5.75
While it should be 5
Order 1, Total with tax 339 => 3.39 loyalty points
Order 2, Total with tax 161 => 
  1.41 loyalty points from current order
  \+ 3.39 from past order
  = 5.00 total loyalty points

When applying the discount on Order 2 the system converts 5 points to 5$,
but considering 15% tax included, the price unit of the discount line
should be 4.35

opw-3642795

Forward-Port-Of: odoo/odoo#157125

36e6728b2cac87c7cd922001be0222688ad52abb fixed an issue where the volume and weight were incorrectly computed for carriers based on rules. But it was done by changing the method api, which seems to break some custom modules using/extending the modified methods. This commit reverts the API change, conveying the needed information through the context for now (the api change will be done in master only). opw-3826165 --- I confirm I have signed the CLA and read the PR guidelines at

36e6728b2cac87c7cd922001be0222688ad52abb fixed an issue where the volume and weight were incorrectly computed for carriers based on rules.

But it was done by changing the method api, which
seems to break some custom modules using/extending the modified methods.

This commit reverts the API change, conveying the
needed information through the context for now
(the api change will be done in master only).

opw-3826165


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

Forward-Port-Of: odoo/odoo#159181
Forward-Port-Of: odoo/odoo#159091

Since revision 81b5ef93a773b94a4e3770632469c692b0ff57fa, adding by default the filter `sale_order_id` which does: ```xml <field name="sale_order_id" string="Sale Order" filter_domain="['|', ('sale_order_id', 'ilike', self), ('sale_line_id', 'ilike', self)]" /> ``` becomes useless, because the final domain, with that `[('id', 'in', self.tasks_ids.ids)]` becomes: ```py [ "&", "&", "&", [ "project_id", "!=", false ], [ "display_in_project", "=", true ]

Since revision 81b5ef93a773b94a4e3770632469c692b0ff57fa, adding by default the filter `sale_order_id`
which does:
```xml
<field name="sale_order_id" string="Sale Order"
    filter_domain="['|', ('sale_order_id', 'ilike', self), ('sale_line_id', 'ilike', self)]"
/>
```

becomes useless, because the final domain, with that `[('id', 'in', self.tasks_ids.ids)]` becomes:
```py
[
	"&",
	"&",
	"&",
	[
		"project_id",
		"!=",
		false
	],
	[
		"display_in_project",
		"=",
		true
	],
	[
		"id",
		"in",
		[
			3341211,
			3526685,
			3692221
		]
	],
	"|",
	[
		"sale_order_id",
		"ilike",
		"SO2023/123456"
	],
	[
		"sale_line_id",
		"ilike",
		"SO2023/123456"
	]
]
```

which makes an "AND" connection between the task ids domain leaf and the sale order name ilike leaves, and all these task ids will come from these SO names, making the AND useless.

In addition to be useless, it downgrades the performance. On Odoo.com,
- with the filter `sale_order_id`: 15473 ms
- without the filter `sale_order_id`: 39ms

On the below screenshot: 
![image](https://github.com/odoo/odoo/assets/5822488/3f19da7a-aafb-43a7-a092-c242a3fd7318)
The first request is with the filter `sale_order_id`
The second request is without the filter `sale_order_id`


opw-3752003

Forward-Port-Of: odoo/odoo#159115
Forward-Port-Of: odoo/odoo#158898

When applying a format in an unbreakable inline (without a class), the format was immediately rolled back as we tried to remove split the unbreakable in order to remove its style. task-3768157 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159110 Forward-Port-Of: odoo/odoo#155510

When applying a format in an unbreakable inline (without a class), the format was immediately rolled back as we tried to remove split the unbreakable in order to remove its style.

task-3768157

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

Forward-Port-Of: odoo/odoo#159110
Forward-Port-Of: odoo/odoo#155510

**Current behavior:** In the jobs/ directory on the website, if a position has a location set in its configuration, the 'Location' label will display the name of the company rather than the city where it is located. **Expected behavior:** The city will be displayed under the 'Location' label. **Steps to reproduce:** 1. In the Recruitment app, give a job a location value 2. On the website, go to the jobs/ directory and navigate to the position from step 1 3. Click 'Apply Now!' and

**Current behavior:**
In the jobs/ directory on the website, if a position has a location set in its configuration, the 'Location' label will display the name of the company rather than the city where it is located.

**Expected behavior:**
The city will be displayed under the 'Location' label.

**Steps to reproduce:**
1. In the Recruitment app, give a job a location value

2. On the website, go to the jobs/ directory and navigate to the position from step 1

3. Click 'Apply Now!' and look at the location label on the right side of the page

**Cause of the issue:**
This field was missing the "contact" widget type in its t-options.

**Fix:**
Add the widget type and additionally display "Remote" for the location when there is no location set.

opw-3761348

Forward-Port-Of: odoo/odoo#159074
Forward-Port-Of: odoo/odoo#156239

In Inventory Settings activate packages and storage locations. Create a storable product [TEST] with tracking by lot Create a PO for [TEST] with a [QTY] larger than one. Receive the products (lot [A]) and put them in a package [PKG]. Create and process an internal transfer of the whole package [PKG] from the input location to any location. Unpack [PKG]. Go to Stock > Reporting > Locations Locate the received product, hit 'History' Issue: traceability is empty. This occurs because t

In Inventory Settings activate packages and storage locations.
Create a storable product [TEST] with tracking by lot
Create a PO for [TEST] with a [QTY] larger than one.
Receive the products (lot [A]) and put them in a package [PKG].
Create and process an internal transfer of the whole package [PKG]
  from the input location to any location.
Unpack [PKG].
Go to Stock > Reporting > Locations
Locate the received product, hit 'History'

Issue: traceability is empty.
This occurs because the 'unpack' operation clean the information
relative to the package from the stock quant.
When accessing the history, the system lookup for move lines having the
same package (none in this case), so nothing is found

opw-3769752

Forward-Port-Of: odoo/odoo#158949
Forward-Port-Of: odoo/odoo#158410

In some edge cases the invoice date will differ from the accounting date. This commit makes sure that when this is the case the accounting date is shown on a posted invoice or credit note. This way it stays clear that the accounting date differs from the invoice date. task: 3774329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156315

In some edge cases the invoice date will differ from the accounting date. This commit makes sure that when this is the case the accounting date is shown on a posted invoice or credit note. This way it stays clear that the accounting date differs from the invoice date.

task: 3774329

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

Forward-Port-Of: odoo/odoo#156315

The underlying `odoo.tools.email_send` was removed in 82de620424e22f9ca7cb9768db638c3a2b4f9318 (merged in 14.5) but this callsite was missed, this method has been broken ever since. Forward-Port-Of: odoo/odoo#159113

The underlying `odoo.tools.email_send` was removed in 82de620424e22f9ca7cb9768db638c3a2b4f9318 (merged in 14.5) but this callsite was missed, this method has been broken ever since.

Forward-Port-Of: odoo/odoo#159113

Before this commit, when creating a many2one field from an xml, with an impossible combination "`required=True` - `on_delete='set null'`", the column was not created in the database without any notice to the user. This commit adds a constraint checking that any attempt to create a field with this configuration would raise a ValidationError. This constraint replaces the previous onchange method. Forward-Port-Of: odoo/odoo#158778

Before this commit, when creating a many2one field from an xml, with an impossible combination "`required=True` - `on_delete='set null'`", the column was not created in the database without any notice to the user.

This commit adds a constraint checking that any attempt to create a field with this configuration would raise a ValidationError. This constraint replaces the previous onchange method.

Forward-Port-Of: odoo/odoo#158778

The fields in analytic have a group which is defined in account. It's okay to show them in analytic module only (for example from project) for people having the rights to see analytic. We also show balance now, even if you don't have the group 'readonly', because it's an information that is independent of credit/debit notion. Linked to runbot error 59222 (will need to remove the group in the test) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com

The fields in analytic have a group which is defined in account. 
It's okay to show them in analytic module only (for example from project) 
for people having the rights to see analytic. 

We also show balance now, even if you don't have the group 'readonly', 
because it's an information that is independent of credit/debit notion.

Linked to runbot error 59222 (will need to remove the group in the test)



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

Forward-Port-Of: odoo/odoo#158994
Forward-Port-Of: odoo/odoo#156349

**Steps to reproduce:** - Install Accounting and Purchase - Go to Purchase and create a PO: * Vendor: Vendor X * Product: Product X * Unit Price: 50.00 - Create an electronic bill in XML format with: * a reference to PO name * the same partner than the PO * the same line than the PO, except for the price - Go to "Accounting / Vendors / Bills" - Upload the XML bill **Issue:** The bill is generated and linked to the PO, but the price and subtotal on the bill line is the

**Steps to reproduce:**
- Install Accounting and Purchase
- Go to Purchase and create a PO:
  * Vendor: Vendor X
  * Product: Product X
  * Unit Price: 50.00
- Create an electronic bill in XML format with:
  * a reference to PO name
  * the same partner than the PO
  * the same line than the PO, except for the price
- Go to "Accounting / Vendors / Bills"
- Upload the XML bill

**Issue:**
The bill is generated and linked to the PO, but the price and subtotal on the bill line is the one coming from the PO instead of the one coming from the XML.
Values coming from an imported XML should not be overridden by values found in matching PO.

**Cause:**
"timeout" parameter is wrongly passed as "prefer_purchase_line" parameter in
a call to "_find_and_set_purchase_orders" method.

opw-3707731




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

Forward-Port-Of: odoo/odoo#158015

Description of the issue/feature this PR addresses: the autoreload does not work after modified python file(s), dev reload mode has been eanbled when start odoo on windows 11. i found the reason is: when a file modified, watchdog event has the property 'dest_path' but content is empty Current behavior before PR: odoo started with --dev=reload, the log show watchdog is watching addon folders but when i modified a python file, the odoo app did not restart, the log has no output. Desired

Description of the issue/feature this PR addresses:
the autoreload does not work after modified python file(s), dev reload mode has been eanbled when start odoo on windows 11.
i found the reason is: when a file modified, watchdog event has the property 'dest_path' but content is empty 

Current behavior before PR:
odoo started with --dev=reload, the log show watchdog is watching addon folders
but when i modified a python file, the odoo app did not restart, the log has no output.

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#157829

Commit [1] introduced new image settings for the product page. When those settings were introduced,the editor was reloaded after the RPC to properly reflect when the settings were changed. While this was done, a data-reload was also added in the XML template of the options. This was not necessary as the data-reload only works for some methods which are not used in the image settings. Therefore, the data-reload did nothing. However, with commit [2], the settings were moved and combined with pa

Commit [1] introduced new image settings for the product page. When those settings were introduced,the editor was reloaded after the RPC to properly reflect when the settings were changed. While this was done, a data-reload was also added in the XML template of the options. This was not necessary as the data-reload only works for some methods which are not used in the image settings. Therefore, the data-reload did nothing.

However, with commit [2], the settings were moved and combined with page options. So the image settings automatically inherited the page options behavior, which is to save and reload the page when a method with data-reload is called. This caused the editor to ask for a reload twice.

This did not cause a problem as somehow, the second reload was ignored. But with the conversion of the SnippetsMenu to OWL, it seems like the race condition introduces an error. This commit fixes the behavior by removing the reload request after applying image settings.

[1]: https://github.com/odoo/odoo/commit/54c6d36cfbea31fe60b888bbb903b0c6f22216b3
[2]: https://github.com/odoo/odoo/commit/b274cf2427951761e59eb357fb796b54be375507#diff-754f6c793d6a168d006d2a9da108142b889036031ac1a2e62060c225d060f858

Forward-Port-Of: odoo/odoo#158468
Forward-Port-Of: odoo/odoo#156658

Chilean ecommerce checkout flow was consistently breaking when automatic invoice was enabled (Sale settings), for customers choosing the 'Ticket' option (not the 'Invoice' one). Indeed, choosing the 'Ticket' options sets a generic 'Anonymous' customer as billing address, but since this address is incomplete, the customer is redirected to the page to complete it, even though they don't have the rights to update that address since it's not theirs. This commit makes sure to consider this 'ano

Chilean ecommerce checkout flow was consistently breaking when automatic invoice was enabled (Sale settings), for customers choosing the 'Ticket' option (not the 'Invoice' one).

Indeed, choosing the 'Ticket' options sets a generic 'Anonymous' customer as billing address, but since this address is incomplete, the customer is redirected to the page to complete it, even though they don't have the rights to update that address since it's not theirs.

This commit makes sure to consider this 'anonymous' billing address as being always complete, even if some fields are empty.

opw-3792844

Forward-Port-Of: odoo/enterprise#59351

### Context In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%. The existing system constraints prevent directly using the value of one tax as the base for another, leading to a workaround by setting it to -2.85 (representing 15% of 19%). ### Problem The electronic invoice requirements mandate the submission of base amounts and taxed values for each tax

### Context

In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%. The existing system constraints prevent directly using the value of one tax as the base for another, leading to a workaround by setting it to -2.85 (representing 15% of 19%).

### Problem

The electronic invoice requirements mandate the submission of base amounts and taxed values for each tax and invoice line. Due to our system's limitation in directly calculating the base for the withholding tax, our approach has been to reverse calculate the base using the tax amount divided by its rate. This method introduces inaccuracies because the tax amount is rounded, and those inaccuracies can in turn result in the electronic document being rejected.

### Solution

There's currently no way to properly fix this, so we have to rely on some dodgy programming. This commit changes the calculation method to focus on directly determining and computing the VAT amount subject to withholding. 


opw-3744872

Forward-Port-Of: odoo/enterprise#58894
Forward-Port-Of: odoo/enterprise#58377

Clean the implementation. Forward-Port-Of: odoo/enterprise#58819

Clean the implementation.

Forward-Port-Of: odoo/enterprise#58819

The account code 5003 is used for the salary advance account but in hr.salary.rule the account linked to it is 5004 Holidays payment after departure. see [here](https://github.com/odoo/enterprise/blob/17.0/l10n_ch_hr_payroll_account/models/account_chart_template.py#L15). But that should be Salary Advance. Although I am not very sure about this, I saw the code and it seems to be suspicious. Before fix:- ![Screenshot from 2024-03-20 17-48-13](https://github.com/odoo/enterprise/assets/100188260

The account code 5003 is used for the salary advance account but in hr.salary.rule the account linked to it is 5004 Holidays payment after departure. see [here](https://github.com/odoo/enterprise/blob/17.0/l10n_ch_hr_payroll_account/models/account_chart_template.py#L15). But that should be Salary Advance. Although I am not very sure about this, I saw the code and it seems to be suspicious.

Before fix:-
![Screenshot from 2024-03-20 17-48-13](https://github.com/odoo/enterprise/assets/100188260/2e3ea1e6-3d79-4d0c-bdaf-2b26f358fc58)
After fix:-
![Screenshot from 2024-03-20 17-48-01](https://github.com/odoo/enterprise/assets/100188260/1eb45990-5f00-407e-ba96-36b3323c3cdf)

Forward-Port-Of: odoo/enterprise#59002

Before this commit, scanning a source location then update a product's line by pressing the +1 qty button will update the quant's location. The issue is: we can't edit source of an existing quant. How to reproduce: - Activate storage locations settings; - Oo to Inventory > Opterations > Physical Inventory; - Select all lines and press "Request a count" assigned to mitchel admin; - Go to Barcode in Inventory Adjustments; - Scan shelf1 (barcode is 2601892); - Click on existing line from

Before this commit, scanning a source location then update a product's line by pressing the +1 qty button will update the quant's location. The issue is: we can't edit source of an existing quant.

How to reproduce:

- Activate storage locations settings;
- Oo to Inventory > Opterations > Physical Inventory;
- Select all lines and press "Request a count" assigned to mitchel admin;
- Go to Barcode in Inventory Adjustments;
- Scan shelf1 (barcode is 2601892);
- Click on existing line from WH/Stock then press +1 :arrow_right:  The line's location is updated to Shelf 1, it shouldn't happen.

OPW-3792605

Forward-Port-Of: odoo/enterprise#58991
Forward-Port-Of: odoo/enterprise#58427

There were a few issues with the new version 3.0 of the Delivery Guide (Carta Porte): - TipoMateria should only be visible when it's an external trade. - NumRegIdTrib should only be visible when the customer's country is not MX. - Visibility of customs related fields (that were added in version 3.0) should not depend on the state of the picking. task-3755473 Forward-Port-Of: odoo/enterprise#59107 Forward-Port-Of: odoo/enterprise#57822

There were a few issues with the new version 3.0 of the Delivery Guide (Carta Porte):
- TipoMateria should only be visible when it's an external trade.
- NumRegIdTrib should only be visible when the customer's country is not MX.
- Visibility of customs related fields (that were added in version 3.0) should not depend on the state of the picking.

task-3755473

Forward-Port-Of: odoo/enterprise#59107
Forward-Port-Of: odoo/enterprise#57822

When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them. Example (formatted): ```sql SELECT "mrp_routing_workcenter".id FROM "mrp_routing_workcenter" LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id" ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id" WHERE "mrp_rou

When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them.

Example (formatted):
```sql
    SELECT "mrp_routing_workcenter".id
      FROM "mrp_routing_workcenter"
 LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
        ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
     WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
       AND (  ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE ("mrp_bom"."company_id" in (1))
                   )
              )
           OR ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE "mrp_bom"."company_id" IS NULL
                   )
              )
           )
  ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
           "mrp_routing_workcenter__bom_id"."id",
           "mrp_routing_workcenter"."sequence",
           "mrp_routing_workcenter"."id"
```

If we use the single term version the generated query has only one sub-query:
```sql
    SELECT "mrp_routing_workcenter".id
      FROM "mrp_routing_workcenter"
 LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
        ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
     WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
       AND (  ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE (("mrp_bom"."company_id" in (1))
                        OR  ("mrp_bom"."company_id" IS NULL))
                   )
              )
           )
  ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
           "mrp_routing_workcenter__bom_id"."id",
           "mrp_routing_workcenter"."sequence",
           "mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in better execution times.

Also, the `company_id` field is required on some models, so the "= False" comparison is useless.

Forward-Port-Of: odoo/enterprise#59378
Forward-Port-Of: odoo/enterprise#58756

**Current behavior:** If a company belongs to a VAT Unit and a report is generated with that Unit selected, the PDF output will display the company VAT number instead of the VAT Unit number. **Expected behavior:** The VAT Unit number will be written to the PDF if a report is being generated with that option selected. **Steps to reproduce:** 1. Install l10n_be and in the company config for the default Belgian company, add a new VAT Unit and make the Belgian company part of it 2. In th

**Current behavior:**
If a company belongs to a VAT Unit and a report is generated with that Unit selected, the PDF output will display the company VAT number instead of the VAT Unit number.

**Expected behavior:**
The VAT Unit number will be written to the PDF if a report is being generated with that option selected.

**Steps to reproduce:**
1. Install l10n_be and in the company config for the default Belgian company, add a new VAT Unit and make the Belgian company part of it

2. In the Accounting app, go to the `Tax Report` view under the `Reporting` menu

3. Select the newly created VAT Unit for the `Tax Unit` option in the top right of the view

4. Select the `PDF` button to print the report, observe that the `VAT:` label on the report shows the Company VAT number instead of the Unit's

**Cause of the issue:**
The XML template for the PDF report is only setup to show the company VAT number here.

**Fix:**
Use the selection for the `Tax Unit:` configuration to inform the VAT number that is shown on the final report.

opw-3747319

Forward-Port-Of: odoo/enterprise#59240
Forward-Port-Of: odoo/enterprise#58361

Before this commit, some archived sign.requests were triggering reminders by the cron when they shouldn't, because they weren't active anymore. After this commit, archived sign.requests no longer trigger reminders by the cron, they are skipped in the SQL query. task-3806013 Forward-Port-Of: odoo/enterprise#58649

Before this commit, some archived sign.requests were triggering reminders by the cron when they shouldn't, because they weren't active anymore.

After this commit, archived sign.requests no longer trigger reminders by the cron, they are skipped in the SQL query.

task-3806013

Forward-Port-Of: odoo/enterprise#58649

The issue: In the accounting report, in the process of creating the temporary table analytic_temp_account_move_line, that should match the account_move_line schema, we opt for NULL values, casting them to match the column type to match account_move_line table columns type. Now, if you have a field of any type that is not standard in PSQL (like HTML) in the account.move.line model, the query will try to cast a NULL to this type (which is HTML in this case), therefore will throw a traceback

The issue:
In the accounting report, in the process of creating the temporary table analytic_temp_account_move_line,
that should match the account_move_line schema, we opt for NULL values, casting them to match the column type to match account_move_line table columns type.
Now, if you have a field of any type that is not standard in PSQL (like HTML) in the account.move.line model, the query will try to cast a NULL to this type (which is HTML in this case), therefore will throw a traceback

The fix:
Instead of casting NULL to Odoo type, which is in some cases not a valid type for PSQL (Like HTML type), this PR aims to cast any of these fields to the appropriate PSQL type

opw-3782724

Forward-Port-Of: odoo/enterprise#58617

Before this commit, if setting a condition on a column in studio, it was on the 'column_invisible'. In result, the column was not invisible because it was conditional on the lines. So you cannot make the column dissapear on some line and not other in a list view. After this commit, the property selected when setting a condition is 'invisible'. Like that the cell is invisible and not the column. opw-ticket: 3667210 Forward-Port-Of: odoo/enterprise#58283 Forward-Port-Of: odoo/enterprise#545

Before this commit, if setting a condition on a column in studio, it was on the 'column_invisible'. In result, the column was not invisible because it was conditional on the lines. So you cannot make the column dissapear on some line and not other in a list view.

After this commit, the property selected when setting a condition is 'invisible'. Like that the cell is invisible and not the column.

opw-ticket: 3667210

Forward-Port-Of: odoo/enterprise#58283
Forward-Port-Of: odoo/enterprise#54527

Before this commit on the sign request when leaving the validity field empty and clicking on a different place, the following error occurs: """ .... if self.validity < fields.Date.today(): TypeError: '<' not supported between instances of 'bool' and 'datetime.date' """ This commit aims to fix this issue by adding an additional condition before comparing the validity. Task: 3750526 Forward-Port-Of: odoo/enterprise#57196

Before this commit on the sign request when leaving the validity field empty and clicking on a different place, the following error occurs: """
....

if self.validity < fields.Date.today():
TypeError: '<' not supported between instances of 'bool' and 'datetime.date' """
This commit aims to fix this issue by adding an additional condition before comparing the validity.

Task: 3750526

Forward-Port-Of: odoo/enterprise#57196

Change adds inputs and rules used for calculating salary in UAE. task-3634461 Forward-Port-Of: odoo/enterprise#53553

Change adds inputs and rules used for calculating salary in UAE.

task-3634461

Forward-Port-Of: odoo/enterprise#53553

Before: Spreadsheet can be renamed to blank spaces. After: If a spreadsheet is renamed to blank spaces, the placeholder value will auto reset back to original name or default untitled name. Task: 3559704 Forward-Port-Of: odoo/enterprise#59145 Forward-Port-Of: odoo/enterprise#51550

Before:
Spreadsheet can be renamed to blank spaces.

After:
If a spreadsheet is renamed to blank spaces, the placeholder value will auto reset back to original name or default untitled name.

Task: 3559704

Forward-Port-Of: odoo/enterprise#59145
Forward-Port-Of: odoo/enterprise#51550