## How to Reproduce: - Create products P1 & P2, storable - Create receipt picking for 1 unit of P1 -> Confirm - Open receipt in 2 browser tabs. - In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save! - In Tab 2, validate the receipt. - In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned' ## Solution: When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it

## How to Reproduce:
- Create products P1 & P2, storable
- Create receipt picking for 1 unit of P1 -> Confirm
- Open receipt in 2 browser tabs.
- In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save!
- In Tab 2, validate the receipt.
- In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned'

## Solution:
When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it was added to a Done unlocked picking.

OPW-3919976

Forward-Port-Of: odoo/odoo#197034
Forward-Port-Of: odoo/odoo#196161

**Problem**: Wrapping links with `feff` chars allows placing the cursor at their inner or outer edge. However, if the parent is `contenteditable=false`, this behavior is unnecessary since navigation outside the link is already blocked. **Example**: `<div contenteditable=false>/ZWS/<a contenteditable=true>` `/ZWS/ab[]c</a></div>` Pressing the left arrow key repeatedly places the cursor at the start of `a`, before `feff`: `<div contenteditable=false>/ZWS/<a contenteditable=true>` `[]/

**Problem**:
Wrapping links with `feff` chars allows placing the cursor
at their inner or outer edge. However, if the parent is
`contenteditable=false`, this behavior is unnecessary since
navigation outside the link is already blocked.

**Example**:
`<div contenteditable=false>/ZWS/<a contenteditable=true>`
`/ZWS/ab[]c</a></div>`
Pressing the left arrow key repeatedly places the cursor
at the start of `a`, before `feff`:
`<div contenteditable=false>/ZWS/<a contenteditable=true>`
`[]/ZWS/abc</a></div>`
This forces an extra left-arrow press to move past `a`,
which is redundant since only the link itself is editable.

**Solution**:
Wrap links with `feff` only if their parent element is
`contenteditable=true`.

**Steps to Reproduce**:
1. Add a Form snippet.
2. Focus on the "Submit" button.
3. Press the "Home" button to move the cursor to the start.
4. Press the right arrow key twice.
   - **Expected**: Cursor moves after the first visible char.
   - **Issue**: Cursor stops prematurely before the character.

opw-4505962

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

Forward-Port-Of: odoo/odoo#195704

When creating nested BoMs that share some common component, the cost of the product was being calculated incorrectly Steps to reproduce: ------------------- * Set `All` category to use the costing method `AVCO` in the settings. * Create a product Comp1 and set its cost to 100. * Create Product P1 with a BoM that consumes 1 Comp1. * Create Product P2 with a BoM that consumes 1 Comp1. * Create Product P3 with a BoM that consumes 1 P1. * Create a POS order with 1 P2, and 1 P3. * Close t

When creating nested BoMs that share some common component, the cost of
the product was being calculated incorrectly

Steps to reproduce:
-------------------
* Set `All` category to use the costing method `AVCO` in the settings.
* Create a product Comp1 and set its cost to 100.
* Create Product P1 with a BoM that consumes 1 Comp1.
* Create Product P2 with a BoM that consumes 1 Comp1.
* Create Product P3 with a BoM that consumes 1 P1.
* Create a POS order with 1 P2, and 1 P3.
* Close the session and check the cost of the products in the order
> Observation: The cost for P3 is incorrect, it should be 100 but it is 200.

Why the fix:
------------
When selecting the stock moves line to consider for the cost of the PoS
order, we need to select the stock moves that are related to the
BoM lines of the original product. In the previous code we were only
relying on the product id, and this was causing the issue because some
products can have the same product id but used in different BoM lines.

opw-4201935

Forward-Port-Of: odoo/odoo#193717

It is possible to have a lead linked to registration from different events by using the merge method on the leads. Currently once they are merged it becomes impossible to update any field that is synced as syncing expects we will only encounter one event. We just default to the first event for the name. Additionally the test revealed that if the lead doesn't have a description and a partner is added, the update mechanism crashes. task-4531433 Forward-Port-Of: odoo/odoo#196848

It is possible to have a lead linked to registration from different events by using the merge method on the leads.

Currently once they are merged it becomes impossible to update any field that is synced as syncing expects we will only encounter one event.

We just default to the first event for the name.

Additionally the test revealed that if the lead doesn't have a description and a partner is added, the update mechanism crashes.

task-4531433

Forward-Port-Of: odoo/odoo#196848

Versions -------- - 17.0+ Steps ----- 1. Have a PNG image with a transparent background; - e.g. https://odoocdn.com/openerp_website/static/src/img/assets/png/odoo_logo.png 3. use it as main image for a product; 4. upload it again as extra image via the website editor; 5. enable click on zoom for the images; 6. click on the images. Issue ----- - The main image gets displayed with a black background. - The extra image gets displayed with a white background. Cause ----- -

Versions
--------
- 17.0+

Steps
-----
1. Have a PNG image with a transparent background;
    - e.g. https://odoocdn.com/openerp_website/static/src/img/assets/png/odoo_logo.png
3. use it as main image for a product;
4. upload it again as extra image via the website editor;
5. enable click on zoom for the images;
6. click on the images.

Issue
-----
- The main image gets displayed with a black background.
- The extra image gets displayed with a white background.

Cause
-----
- The `img` element of the main image has the `bg-black` class.
- PNG images uploaded via the `website_sale` editor get converted to WEBP, and then drawn on a white canvas before getting stored.

Solution
--------
- Remove the `bg-black` class from the `img` element.
- When converting to WEBP, use a transparent canvas.
  - Do the same for WEBP images uploaded via `ImageField`.

opw-3848324

Forward-Port-Of: odoo/odoo#197603

Currently, an exception is raised when evaluating multiple records, where some records are complete and correct while others contain errors. error: ```ValueError KeyError(account.move(43,)) while evaluating 'if records:\n action = records.action_l10n_my_edi_send_invoice()' ``` [1]- https://github.com/odoo/odoo/blob/8eacfdcc2b65c62848d7939121c64928b76a80ed/addons/l10n_my_edi_extended/models/account_move.py#L181 [2]- https://github.com/odoo/odoo/blob/8eacfdcc2b65c62848d79391

Currently, an exception is raised when evaluating multiple records, where some records are complete and correct while others contain errors.

error:
```ValueError
KeyError(account.move(43,)) while evaluating
'if records:\n           action = records.action_l10n_my_edi_send_invoice()'
```

[1]- https://github.com/odoo/odoo/blob/8eacfdcc2b65c62848d7939121c64928b76a80ed/addons/l10n_my_edi_extended/models/account_move.py#L181

[2]- https://github.com/odoo/odoo/blob/8eacfdcc2b65c62848d7939121c64928b76a80ed/addons/l10n_my_edi_extended/models/account_move.py#L153

This commit fixes the issue by filtering only those records that have errors during evaluation,  and I have added a test for this issue.

sentry - 6298401222

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

Forward-Port-Of: odoo/odoo#197860

Consider a recordset of new records, and a loop like ```py for record in records: for line in record.line_ids: line.value ``` The implementation of `record.line_ids` does not actually prefetch all `records`. It actually fetches the field on the records' origin (their corresponding real records), but only assigns the current new record in cache. As the prefetching relies on the cached values of `line_ids`, the prefetching mechanism is actually broken on `line`. The fix cons

Consider a recordset of new records, and a loop like
```py
for record in records:
    for line in record.line_ids:
        line.value
```
The implementation of `record.line_ids` does not actually prefetch all `records`.  It actually fetches the field on the records' origin (their corresponding real records), but only assigns the current new record in cache.  As the prefetching relies on the cached values of `line_ids`, the prefetching mechanism is actually broken on `line`.

The fix consists in assigning all the records to prefetch in this case. This does not add unexpected prefetching, since the origin records are prefetched as one batch anyway.

Forward-Port-Of: odoo/odoo#198202
Forward-Port-Of: odoo/odoo#198124

**Current behavior:** It's possible to end up with a negative valuation for a product with zero product qty. **Expected behavior:** No negative valuation for 0 product qty. **Steps to reproduce:** 1. Create a FIFO, real-time product; create a BOM for fifo-product with some component (tracked by qty, costing method doesn't matter, `standard_price=1`) 2. Purchase 2 units of component @ $1 3. Create and fully process an MO for fifo-prod 4. Change the standard price of component fr

**Current behavior:**
It's possible to end up with a negative valuation for a product with zero product qty.

**Expected behavior:**
No negative valuation for 0 product qty.

**Steps to reproduce:**
1. Create a FIFO, real-time product; create a BOM for fifo-product with some component (tracked by qty, costing method doesn't matter, `standard_price=1`)

2. Purchase 2 units of component @ $1

3. Create and fully process an MO for fifo-prod

4. Change the standard price of component from $1 -> $2

5. Create and fully process a second MO for fifo-prod

6. Unbuild the second MO (from step 5)

7. Sell 1 unit of fifo-prod

8. Check the valuation, see that both the unbuild and out move (sale) use a `unit_cost=$2` despite there having been only 1 qty valued at $2 in the valuation history

**Cause of the issue:**
SVL creation for fifo costing in an unbuild context does not limit the candidate layer search to moves linked to the actual manufacturing order specified on the unbuild form.

So despite us unbuilding the second MO in step 6, the valuation from the first MO's SVL is used.

The reason we get the correct `unit_cost` despite using the wrong layer is due to commit: 84dda96
Prior to which, the valuation would have correctly zeroed out but there would have still been this valuation mis-match behind the scenes.

**Fix:**
Constrain the fifo candidate layer search to finished moves from the unbuilt production (if actuallywhen `_action_confirm`ing unbuild moves.

opw-4416350

Forward-Port-Of: odoo/odoo#197190

Following this commit [1] introduced in Chrome 133.0.6836.0, this QUnit test for ImageField was failing as it reused twice the same DataTransfer instance. The Chrome's fix now properly updates the reference to its `files` property which results into an "empty" DataTransfer object once it has been consumed. This commit ensures a new DataTransfer instance created for each transfer (as "in real life") instead of reusing it. [1]: https://chromium.googlesource.com/chromium/src/+/ed04b9d9336db2e

Following this commit [1] introduced in Chrome 133.0.6836.0, this QUnit test for ImageField was failing as it reused twice the same DataTransfer instance. The Chrome's fix now properly updates the reference to its `files` property which results into an "empty" DataTransfer object once it has been consumed.

This commit ensures a new DataTransfer instance created for each transfer (as "in real life") instead of reusing it.

[1]: https://chromium.googlesource.com/chromium/src/+/ed04b9d9336db2e4f667fe0cfcda8f2156553fd2

Forward-Port-Of: odoo/odoo#198269

During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called, `quality.check` records are created one at the time. This can become slow wh en a lot of checks are created at once (ex: Bill of Material defined with steps "manual consumption" and used in a manufacturing order). Script used for tests: https://gist.github.com/emi-odoo/d4c6271363dfc3f2e4b7c5efa

During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed

When method `_create_checks` is called, `quality.check` records are created one at the time. This can become slow wh
en a lot of checks are created at once (ex: Bill of Material defined with steps "manual consumption" and used in a manufacturing order).

Script used for tests:
https://gist.github.com/emi-odoo/d4c6271363dfc3f2e4b7c5efabfed5c1

Before: 3.51s (`_create_checks`) - 17493 queries (total queries of the script, not for the single operation)
![image](https://github.com/odoo/enterprise/assets/70145331/3e484a2a-009b-4328-8ecc-3613e74b3378)


After: 2.08s (`_create_checks`)  - 16103 queries (total queries of the script, not for the single operation)
![image](https://github.com/odoo/enterprise/assets/70145331/c7714bf6-a655-4e83-ad25-dd90276ed1a2)

Comparison of the time taken by Confirming the MRP Order (using `time.process_time()`)

| n_components | before (s) | after (s) | ratio |
| --- | --- | --- | --- |
| 1 | 0.074 | 0.073 | 0.988 |
| 5 | 0.134 | 0.140 | 1.042 |
| 10 | 0.216 | 0.187 | 0.862 |
| 20 | 0.334 | 0.304 | 0.908 |
| 50 | 0.736 | 0.600 | 0.816 |
| 100 | 1.378 | 1.172 | 0.851 |
| 200 | 2.739 | 2.374 | 0.867 |

Forward-Port-Of: odoo/enterprise#66224
Forward-Port-Of: odoo/enterprise#65725

After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold. Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all. In this commit, we improv

After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold.

Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all.

In this commit, we improve the styling rules to always disable bold on the deepest line level. That way we can never have a XLSX file with all lines in bold, and it is much easier to read the file.

Meanwhile, the style management was refactored a bit to make it simpler.

[opw-4501822](https://www.odoo.com/odoo/project.task/4501822)
[opw-4458752](https://www.odoo.com/odoo/project.task/4458752)

[indentation fix]: https://github.com/odoo/enterprise/commit/9246a864f91e7facd06fa630fa0d23a0323ce497

Forward-Port-Of: odoo/enterprise#79131
Forward-Port-Of: odoo/enterprise#77510

before this commit: Shipping methods are missing default vlaue of shipping functionalities, which leads to some methods getting filtered out incorrectly. After this commit: Default value of the shipping functionalities are fetched and checked to select the correct shipping method based on user filters. opw-4167675 Forward-Port-Of: odoo/enterprise#79518

before this commit:

Shipping methods are missing default vlaue of shipping functionalities, which leads to some methods getting filtered out incorrectly.

After this commit:

Default value of the shipping functionalities are fetched and checked to select the correct shipping method based on user filters.

opw-4167675

Forward-Port-Of: odoo/enterprise#79518

Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them. How to reproduce: Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter. On the phone, the line break will

Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them.

How to reproduce:

Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter.
On the phone, the line break will not be present anymore because the tag <br> is removed with the other tags.

After this commit: the line break is there and the words are not join together anymore.

OPW-4079729

Forward-Port-Of: odoo/enterprise#73727

When showing or hiding optional columns in the "lines" tree on the account report form view, the view is not updated and the changes only take effect after reloading the page. This is due to changes made in https://github.com/odoo/odoo/commit/1519148eca480e92867ae17d7637867128a84736 This commit adds the recomputing of columns in onWillRender to mimic the changes in above commit. Task: 4536595 Forward-Port-Of: odoo/enterprise#78377

When showing or hiding optional columns in the "lines" tree on the account report form view, the view is not updated and the changes only take effect after reloading the page.

This is due to changes made in https://github.com/odoo/odoo/commit/1519148eca480e92867ae17d7637867128a84736 This commit adds the recomputing of columns in onWillRender to mimic the changes in above commit.

Task: 4536595

Forward-Port-Of: odoo/enterprise#78377

Backport of https://github.com/odoo/enterprise/commit/7abc8f574cdad53f702478f6100bce49ab31756f The aim of this commit is trying to connect an existing journal to a new connection if this journal has no online connection and corresponds to different criteria (like the bank account number, the currency_id, etc). task-4526916 Forward-Port-Of: odoo/enterprise#78221

Backport of https://github.com/odoo/enterprise/commit/7abc8f574cdad53f702478f6100bce49ab31756f

The aim of this commit is trying to connect an existing journal to a new connection if this journal has no online connection and corresponds to different criteria (like the bank account number, the currency_id, etc).

task-4526916

Forward-Port-Of: odoo/enterprise#78221

We use a couple manual SELECT queries in marketing_automation. However these do not flush before querying, meaning the result is potentially wrong if there was a change to the queried tables since the last flush. This is not too noticeable under regular use as only non-store computed fields hold statistics. However it does make the method innacurate in some cases. Notably tests need to flush manually. We now flush properly, as should have been done. As is done for the whatsapp ove

We use a couple manual SELECT queries in marketing_automation.

However these do not flush before querying, meaning the result is potentially wrong
if there was a change to the queried tables since the last flush.

This is not too noticeable under regular use as only non-store computed fields hold statistics.
However it does make the method innacurate in some cases.

Notably tests need to flush manually.

We now flush properly, as should have been done.
As is done for the whatsapp override from 18.0 onwards.

task-4589525

Forward-Port-Of: odoo/enterprise#79673

An issue may occur where moves are unbalanced when FEC file lines contain a device with an imprecise rounding factor. Steps to reproduce: - Create or use a currency with rounding = 1. - Add rounding to debit or credit in a FEC file, ensuring the rounded unit amount is not equal; for example, two debit lines at 100.5 and one credit line at 201 (see example in test). - In the Idevise column of the file, use the name of the created device. - Attempt to import the file. An error will occur

An issue may occur where moves are unbalanced when FEC file lines contain a device with an imprecise rounding factor.

Steps to reproduce:
- Create or use a currency with rounding = 1.
- Add rounding to debit or credit in a FEC file, ensuring the rounded unit amount is not equal; for example, two debit lines at 100.5 and one credit line at 201 (see example in test).
- In the Idevise column of the file, use the name of the created device.
- Attempt to import the file.

An error will occur:
Moves report incorrect balances: Move with name '<name>' has a balance of 1.00.

The issue arises because the created device is used to round the amount instead of the company's device, resulting in 100.5 being rounded to 100, hence the two line of 100 no longer balances with 201.

opw-4397836

Forward-Port-Of: odoo/enterprise#79698
Forward-Port-Of: odoo/enterprise#76932

before this PR: - The income account was solely derived from the product's configuration. After this PR: - If the product’s income account is not set, we fall back to the default account defined on the POS journal. This ensures the Sales Account used in GSTR-1 computations is properly set. See: https://github.com/odoo/odoo/pull/149816 Forward-Port-Of: odoo/enterprise#79661

before this PR:
- The income account was solely derived from the product's configuration.

After this PR:
- If the product’s income account is not set, we fall back to the default account defined on the POS journal.

This ensures the Sales Account used in GSTR-1 computations is properly set.

See: https://github.com/odoo/odoo/pull/149816

Forward-Port-Of: odoo/enterprise#79661