Chrome iOS wraps some text nodes (like measures, email...) with a
`<chrome_annotation>` tag, which breaks OWL rendering.

This commit works around it by adding the (undocumented) `<meta
name="chrome" content="nointentdetection">` tag to disable this Chrome
behavior. The tag has to be set before the onDOMContentLoaded event to
be taken into account.

Note: Looks like this behavior was present in Chrome iOS 127 and
disabled afterward (because it already had issues) but it appeared again
in version 140-141.

References:
- https://issues.chromium.org/issues/353650041
- https://issues.chromium.org/issues/388718411
- https://stackoverflow.com/questions/78207646/how-do-i-disable-chrome-annotation-tags
- https://stackoverflow.com/questions/78575970/prevent-auto-detection-of-phone-numbers-in-chrome-mobile
- https://stackoverflow.com/questions/78725191/stop-chrome-ios-auto-detecting-numbers-followed-by-letter-m-as-metre-units-an
- https://github.com/solidjs/solid/issues/2235

opw-4969197

Forward-Port-Of: odoo/odoo#230081

The previous fix for `message/rfc822` attachments forced binary encoding (`cte='binary'`) to comply with RFC 2046. However it also introduced a new issue: emails containing `.eml` attachments with non-ASCII characters could not be serialized

### Steps to reproduce

1. Send an email via the chatter with a `.eml` file attached containing non-ASCII characters (e.g., "é") in its body.

The sending of that email will fail with a `UnicodeEncodeError` error

### Cause

Commit 6197233ef1611ddd974cfdb06ae2568e4af369de attempted to fix an issue where `.eml` (`message/rfc822`) attachments were not RFC-compliant. It did this by forcing the `Content-Transfer-Encoding` to `binary` for the raw byte content of the attachment.

While this worked for simple ASCII attachments, it failed for attachments containing non-ASCII characters. When Python's `email` library later tried to serialize the entire message, it treated the attachment's content as an opaque binary blob. It did not understand the character encoding within that blob, leading to a `UnicodeEncodeError` during the final serialization process.

### Fix

Instead of attaching the raw bytes, we now:
* Parse `.eml` contents using `email.parser.BytesParser`, producing a proper `Message` object.
* Attach the parsed message directly, letting the email library handle correct encoding and transfer settings automatically.

opw-4655868

Forward-Port-Of: odoo/odoo#230384
Forward-Port-Of: odoo/odoo#223790

**Problem:**
unbuilding a Manufactring order created through a subcontracting
process gives the wrong account move lines

**Steps to reproduce:**
- create a storable product (the comp) and set a cost
- create a storable product (the final product), set a cost
and set a vendor
- for the final product set the category as avco and automated
- for the final product create a bill of materials subcontracted
 and set the same vendor
- for the components add the comp for a quantity of 1
- create a Purchase order for the final product and the same vendor
and confirm
- validate the receipt
- From the receipt click on the valuation smart button and click on 
the book widget of the line of the final product
- notice how there is 3 journal items line including one 
crediting "stock interim (Received)"
- unarchive the operation type "subcontracting"
- open Manufacturing/Manufacturing Orders, delete the "to do" 
filter and search for a Manufacturing order with your final product
- unbuild it
- Open accounting/journal entries and select the journal entry for 
the unbuild

**Current behavior:**
There is only two account lines. 
There is no line balancing the "Stock Interim" line of the
manufacturing order.

**Cause of the issue:**
The override of _generate_valuation_lines_data in
mrp_subcontracted_account adds the stock interim line on the 
manufacturing order.
However when unbuilding, the qty is negative so we exit the function
https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/mrp_subcontracting_account/models/stock_move.py#L20

**fix**
Because subcontracted Manufacturing orders are not meant 
to be unbuilt, we prevent it

opw-4998137

Forward-Port-Of: odoo/odoo#230062

Serial number tracked product are marked as pass even when they fail a move_line type of check.

### Steps to reproduce:

* Create a product tracked by serial number
* For this product create a control point:
	- Control per quantity
	- Operations : Receipts
* Create a receipt for this product
* Mark the receipt as Todo
* Start the Quality check from the receipt, without using the smart button.
* Fail the Quality check
* The Quality check still passes

### Issue:

When validating a quality check and it fails:
https://github.com/odoo/enterprise/blob/d48228127c239e45938551d9bbac734afab8b31a/quality_control/wizard/quality_check_wizard.py#L84-L92 I will not go through the standard process with show_faillure_message where the user can select failed_qty, it directly goes to confirme_fail>_move_to_failure_location: https://github.com/odoo/enterprise/commit/49149580d34ec5583559fa0288356fec6cb2c514#diff-2ffdc2ffc25417076b580b772447514c7e9d8b3e2d2fff2d3100721eb5ccbaf4L455-R457 In our case since failed_qty is still at 0 this new condition transfer the quality check to pass. In the case of serial numbers, the quality check is done one by one, the failed_qty can be retrived from check.move_line_id.quantity

opw-5015266

Forward-Port-Of: odoo/enterprise#92966

### Steps to reproduce:
1. Install mrp + purchase
2. Create a new product (A)
   1. Add the Buy route on the product
   2. Add a vendor line on the Purchase tab
   3. Set the quantity on hands to 2000
3. Create a second product (B) with manufacturing route
4. Create a BoM for this product (B)
   1. Add the product (A) as the component with 1 quantity
   2. Create a new operation with a duration of 600:00
5. On the product B's page, click Replenish
   1. Put 10 quantities to replenish
   2. Select the manufacturing route and confirm
6. Go to the BoM and open the BoM overview
7. 'Impossible to plan. Please check the workcenter availabilities.'

https://github.com/user-attachments/assets/58697fd9-4e3e-4df6-98e1-5de7e8759715


### Before this commit:
When opening the BoM overview, if the producible quantity for this BoM exceed the quantity we can plan in the 700 following days, an error is displayed.

### After this commit:
If the quantity producible cannot be planned, we retry automatically with the requested quantity.

opw-5031724

Forward-Port-Of: odoo/odoo#229745
Forward-Port-Of: odoo/odoo#227433

**Steps to reproduce:**
- Install l10n_in and l10n_in_hr_holidays module
- Time off > configuration > Public holidays
- Create a public holiday for Independence Day (15/08/2025)
- Go to Time off > configuration > 'Time off Types',
- Create a Time off type with
   - 'Sandwich leave' ticked and `Take Time Off in` to half a day
- Go to Time off > Management > Time off
- Case 1: Create a paid time off leave for the employee from 13/08 to 17//08/2025 
- Case 2: Create a paid time off with any date and mark it as a half-day

**Observation:**
- Case 1: You will see Duration 3 days with the sandwich leave policy.
- Case 2: Half-day leave shows 1 day instead of 0.5

**Root Cause:**
- Case 1: For the sandwich leave rule, here we checked only one day after and before, leave start and leave end, respectively. It will cause an issue if an employee applies leave that starts or ends with 3 non-working days.
https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L39-L46
- Case 2: We forcefully added a 1-day leave, without checking if the leave is half day or not.
https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L19

**Solution:**
- Case 1: Extend the sandwich leave logic to check every day before and after until a working day is found.
- Case 2: Fixed duration calculation to add 0.5 for half-day leaves.

opw-5025766

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

Forward-Port-Of: odoo/odoo#226883

When users try to access a `slide ID` that is not included in `channel_slides_ids`, a traceback occurs.

Steps to reproduce:
---
- Install `website_slides` module
- Go to the Website and click on the `Courses` menu.
- Then go to `/slides/embed/<int:slide_id>` route. (http://localhost:8069/slides/embed/7)
- The error will occur.

Traceback:
---
`ValueError: 7 is not in list`

At [1], `slide_content_ids` contains the IDs of `channel content`. However, we are trying to access a slide from the `channel category` in URL. As a result, at [2], when attempting to find the index of the slide in `slide_content_ids`, an error occurs because the slide ID actually belongs to `slide_category_ids` and is not present in `slide_content_ids`.

Solution:
---
Added a special case for category slides — if the slide is a category, redirect to the channel homepage.

[1]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L120 [2]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L121

sentry-6572999628

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

Forward-Port-Of: odoo/odoo#225374

**Steps to reproduce:**
- Install l10n_in and l10n_in_hr_holidays module
- Time off > configuration > Public holidays
- Create a public holiday for Independence Day (15/08/2025)
- Go to Time off > configuration > 'Time off Types',
- Create a Time off type with
   - 'Sandwich leave' ticked and `Take Time Off in` to half a day
- Go to Time off > Management > Time off
- Case 1: Create a paid time off leave for the employee from 13/08 to 17//08/2025 
- Case 2: Create a paid time off with any date and mark it as a half-day

**Observation:**
- Case 1: You will see Duration 3 days with the sandwich leave policy.
- Case 2: Half-day leave shows 1 day instead of 0.5

**Root Cause:**
- Case 1: For the sandwich leave rule, here we checked only one day after and before, leave start and leave end, respectively. It will cause an issue if an employee applies leave that starts or ends with 3 non-working days.
https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L39-L46
- Case 2: We forcefully added a 1-day leave, without checking if the leave is half day or not.
https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L19

**Solution:**
- Case 1: Extend the sandwich leave logic to check every day before and after until a working day is found.
- Case 2: Fixed duration calculation to add 0.5 for half-day leaves.

opw-5025766

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

Forward-Port-Of: odoo/odoo#226883

When users try to access a `slide ID` that is not included in `channel_slides_ids`, a traceback occurs.

Steps to reproduce:
---
- Install `website_slides` module
- Go to the Website and click on the `Courses` menu.
- Then go to `/slides/embed/<int:slide_id>` route. (http://localhost:8069/slides/embed/7)
- The error will occur.

Traceback:
---
`ValueError: 7 is not in list`

At [1], `slide_content_ids` contains the IDs of `channel content`. However, we are trying to access a slide from the `channel category` in URL. As a result, at [2], when attempting to find the index of the slide in `slide_content_ids`, an error occurs because the slide ID actually belongs to `slide_category_ids` and is not present in `slide_content_ids`.

Solution:
---
Added a special case for category slides — if the slide is a category, redirect to the channel homepage.

[1]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L120 [2]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L121

sentry-6572999628

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

Forward-Port-Of: odoo/odoo#225374

Sometime, the test `test_scrap_change_source_location` could fail randomly. The issue happens in last few steps of the tour. What we do is:
- We edit a move line lot in the form view;
- We save it;
- We validate the operation.

The validation is done by a barcode scan (`OBTVALI`) but since [1](https://github.com/odoo-dev/enterprise/commit/b3a855a870d1861515abaff8683081a39f95558f), barcodes scanned when the user is somewhere else than in the barcode lines view are skipped.
With a little bit of bad luck, the tour scans `OBTVALI` while the save from the form view is not finished yet and thus, the scanned barcode is ignored.

To reproduce that, run the test `test_scrap_change_source_location` locally in debug mode and add a throttling (eg.: Fast 4G) before to run the tour.

To solve the issue, finetune the `validateBarcodeOperation` default trigger, so the error won't happen in this tour and other similar contexts.

Runbot build error: [232331](https://runbot.odoo.com/odoo/runbot.build.error/232331)

Forward-Port-Of: odoo/enterprise#96542

Sometime, the test `test_scrap_change_source_location` could fail randomly. The issue happens in last few steps of the tour. What we do is:
- We edit a move line lot in the form view;
- We save it;
- We validate the operation.

The validation is done by a barcode scan (`OBTVALI`) but since [1](https://github.com/odoo-dev/enterprise/commit/b3a855a870d1861515abaff8683081a39f95558f), barcodes scanned when the user is somewhere else than in the barcode lines view are skipped.
With a little bit of bad luck, the tour scans `OBTVALI` while the save from the form view is not finished yet and thus, the scanned barcode is ignored.

To reproduce that, run the test `test_scrap_change_source_location` locally in debug mode and add a throttling (eg.: Fast 4G) before to run the tour.

To solve the issue, finetune the `validateBarcodeOperation` default trigger, so the error won't happen in this tour and other similar contexts.

Runbot build error: [232331](https://runbot.odoo.com/odoo/runbot.build.error/232331)

Forward-Port-Of: odoo/enterprise#96542

### Steps to reproduce
1. Install `l10n_mx_edi` with demo data
2. Switch to the ESCUELA KEMPER URGATE demo company
3. Create an invoice to the INMOBILARIA CVA demo partner
4. Send the invoice CFDI
5. Request cancellation of the CFDI
6. The cancellation fails with the error 'invalid passphrase'.

### Analysis
When calling `_finkok_cancel`, `_solfact_cancel`, or `_sw_cancel`, one of the API call parameters is the `pem_key` of the certificate given by the SAT.

Before 19.0, the PEM key was in an unencrypted format.

Since f88f8258ead, `env['certificate.key'].pem_key` is encrypted.

According to Finkok's API documentation, the private key should be encrypted using DES when given as a SOAP parameter.
https://wiki.finkok.com/home/webservices/ws_cancelacion/cancel

However, in testing, encrypting the private key using DES seems to be rejected by Finkok.

Solucion Factible and SwSapien don't indicate in their documentation whether and how the private key should be encrypted.

### Solution
We send the private key unencrypted, as was already the case before 19.0.

opw-5137549

Forward-Port-Of: odoo/enterprise#96562

Sometime, the test `test_scrap_change_source_location` could fail randomly. The issue happens in last few steps of the tour. What we do is:
- We edit a move line lot in the form view;
- We save it;
- We validate the operation.

The validation is done by a barcode scan (`OBTVALI`) but since [1](https://github.com/odoo-dev/enterprise/commit/b3a855a870d1861515abaff8683081a39f95558f), barcodes scanned when the user is somewhere else than in the barcode lines view are skipped.
With a little bit of bad luck, the tour scans `OBTVALI` while the save from the form view is not finished yet and thus, the scanned barcode is ignored.

To reproduce that, run the test `test_scrap_change_source_location` locally in debug mode and add a throttling (eg.: Fast 4G) before to run the tour.

To solve the issue, finetune the `validateBarcodeOperation` default trigger, so the error won't happen in this tour and other similar contexts.

Runbot build error: [232331](https://runbot.odoo.com/odoo/runbot.build.error/232331)

Forward-Port-Of: odoo/enterprise#96542

This PR fixes two related bugs happening when printing a receipt with the Italian Fiscal printer
First, before this PR, if the option to skip the receipt screen
was ticked, then the receipt would never print.
This was caused by the printing logic being implemented on
the receipt screen instead of on the pos itself.

steps to reproduce:
1. install l10n_it_pos
2. configure one pos
3. configure the IT printer
4. select to skip the receipt screen (print automatically)
5. open the pos
6. make a sale
=> no ticket printed and the chrome console shows a printer error

With this new verison the printing logic was moved to the pos
so that printing of fiscal receipts with the italian fiscal printer
works, even when receipt screen is skipped.

This put to light another potential bug related to how the `order` variable was treated.
Before this PR, the printReceipt logic in the module would not
pass the order to be printed.
This can become a problem upon context changes, where `pos.get_order()`
does not return the completed order, but a newly created one.
This can for example happen when skipping the receipt screen with
the option to "print automatically" (iface_print_auto).

After this PR, we keep order as an argument, so we always print
the last completed order and not a newly created one.

opw-4882480

Forward-Port-Of: odoo/enterprise#96346
Forward-Port-Of: odoo/enterprise#91412

The waiting list capacity used to be set indirectly via the `total_capacity_reserved` field

In [1] it was removed as it was not otherwise used. Meaning we should have set the default wishlist capacity instead.
While doing that we also noticed a logical issue with only using the wishlist capacity, it does not allow adding or removing resources that don't correspond to the capacity that was originally set.

Instead we now actually use total_capacity_reserved when the appointment type manages capacities. And let users use the wishlist capacity otherwise. Which allows them to again select resources freely in both contexts.

--------------------------

Additionally we fix the missing placeholder in point-of-sale caused by the placeholder
html editor plugin being missing from the minimal html editor used there.

As well as an incorrect access to a record name in kanban popover.

task-5103532

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

Forward-Port-Of: odoo/enterprise#95539

The system will crash with error when user tries to create new bank statement line.

**Steps to produce:**
- Install `Invoicing` module without demo data.
- Go to `Configuration > Journals` and duplicate the default Bank journal to create Bank (Copy).
- Go to `Dashboard` and Click on 3 dots of Bank(Copy) and click on `Transactions`.
- Create a new transaction and set the Statement also(Create new and assign it).
- Go to that statements and Add a line and set the foreign currency as `USD`.

**Error:**
```py
ValueError: Wrong value for account.bank.statement.journal_id: account.journal(7, 6)
```

**Cause:**
- When there are two Bank journals and the user is not in the default one, creating a new transaction in the statement sets the journal for that transaction to the default Bank journal. However, during computation, this causes an error from [here] because `statement.line_ids.journal_id` contains two different journals..

**Solution:**
- Added `default_journal_id` to the context to ensure the correct journal is used when creating new transactions.

[here]: https://github.com/odoo/odoo/blob/34409128de0bb84cdee309b031b307c46d8b07c7/addons/account/models/account_bank_statement.py#L178

**sentry-6928858335**

Scenario:

- enable second language on website
- go to /shop/1 and try to translate description_ecommerce

Result: this is not translatable

Cause:

Since at least https://github.com/odoo/odoo/commit/b455ea85853dfc19ed01e33986ad270cf80ee5d6 the
contenteditable attribute in ContentEditablePlugin is not set on an
element if it has a contenteditable ancestor.

TranslationPlugin disable all editable nodes containing editable nodes.

So with this combination, if we had a node for example:

```
<div class="oe_editable" data-oe-model="product.template" data-oe-id="1"
  data-oe-field="description_ecommerce" data-oe-type="html">
    <div>
        <span class="oe_editable" data-oe-model="product.template"
            data-oe-id="1" data-oe-field="description_ecommerce">
            test
        </span>
    </div>
</div>
```

the contenteditable was added to the parent div.oe_editable, but was
removed by TranslationPlugin so the "test" text was not translatable.

Fix: move the code that adds data-oe-readonly class in the
after_setup_editor_handlers so it is run before contenteditable
attributes are set.

opw-5128618

Forward-Port-Of: odoo/odoo#230169

When users try to access a `slide ID` that is not included in `channel_slides_ids`, a traceback occurs.

Steps to reproduce:
---
- Install `website_slides` module
- Go to the Website and click on the `Courses` menu.
- Then go to `/slides/embed/<int:slide_id>` route. (http://localhost:8069/slides/embed/7)
- The error will occur.

Traceback:
---
`ValueError: 7 is not in list`

At [1], `slide_content_ids` contains the IDs of `channel content`. However, we are trying to access a slide from the `channel category` in URL. As a result, at [2], when attempting to find the index of the slide in `slide_content_ids`, an error occurs because the slide ID actually belongs to `slide_category_ids` and is not present in `slide_content_ids`.

Solution:
---
Added a special case for category slides — if the slide is a category, redirect to the channel homepage.

[1]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L120 [2]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L121

sentry-6572999628

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

Forward-Port-Of: odoo/odoo#225374

**[FIX] website: properly restart AnnouncementScroll interaction**
    
Commit [e1cc670] introduced the `s_announcement_scroll` snippet, with an
interaction and some options. The way the interaction was restarted
after each option change was hacky, which is what this commit intends to
fix.

We also make sure the preview is working both on hover and when focusing
with Tab.

**[FIX] website: use a dialog for AnnouncementScroll translation**
    
Commit [e1cc670] added the `s_announcement_scroll` snippet, using a
browser prompt to update the translation of its text. We would rather
use an Odoo dialog.

In the same time, we introduce a resource `mark_translatable_nodes`
called in the `TranslationPlugin`. This will allow a better separation
of concerns between what is the core translation setup and what is
specific to some snippets or elements on the page.

**[FIX] website: use `.preview.scss` pattern in add dialog bundle**
    
Commit [ad6e2d3] extracted preview-specific CSS styles from `.edit.scss`
files, in order to load the strict minimum with the bundle. We will use
the same kind of pattern for the preview styles, by suffixing files with
`.preview.scss`, like what is already the case with `.preview.js`
interactions.
    
[ad6e2d3]: https://github.com/odoo/odoo/commit/ad6e2d3857a87a0dfec93c2bcc597328ef21ba00
[e1cc670]: https://github.com/odoo/odoo/commit/e1cc6702a4416204e446d51fdfe047d4ebfd402c

task-5069849

This PR fixes two related bugs happening when printing a receipt with the Italian Fiscal printer
First, before this PR, if the option to skip the receipt screen
was ticked, then the receipt would never print.
This was caused by the printing logic being implemented on
the receipt screen instead of on the pos itself.

steps to reproduce:
1. install l10n_it_pos
2. configure one pos
3. configure the IT printer
4. select to skip the receipt screen (print automatically)
5. open the pos
6. make a sale
=> no ticket printed and the chrome console shows a printer error

With this new verison the printing logic was moved to the pos
so that printing of fiscal receipts with the italian fiscal printer
works, even when receipt screen is skipped.

This put to light another potential bug related to how the `order` variable was treated.
Before this PR, the printReceipt logic in the module would not
pass the order to be printed.
This can become a problem upon context changes, where `pos.get_order()`
does not return the completed order, but a newly created one.
This can for example happen when skipping the receipt screen with
the option to "print automatically" (iface_print_auto).

After this PR, we keep order as an argument, so we always print
the last completed order and not a newly created one.

opw-4882480

Forward-Port-Of: odoo/enterprise#96346
Forward-Port-Of: odoo/enterprise#91412

The previous fix for `message/rfc822` attachments forced binary encoding (`cte='binary'`) to comply with RFC 2046. However it also introduced a new issue: emails containing `.eml` attachments with non-ASCII characters could not be serialized

### Steps to reproduce

1. Send an email via the chatter with a `.eml` file attached containing non-ASCII characters (e.g., "é") in its body.

The sending of that email will fail with a `UnicodeEncodeError` error

### Cause

Commit 6197233ef1611ddd974cfdb06ae2568e4af369de attempted to fix an issue where `.eml` (`message/rfc822`) attachments were not RFC-compliant. It did this by forcing the `Content-Transfer-Encoding` to `binary` for the raw byte content of the attachment.

While this worked for simple ASCII attachments, it failed for attachments containing non-ASCII characters. When Python's `email` library later tried to serialize the entire message, it treated the attachment's content as an opaque binary blob. It did not understand the character encoding within that blob, leading to a `UnicodeEncodeError` during the final serialization process.

### Fix

Instead of attaching the raw bytes, we now:
* Parse `.eml` contents using `email.parser.BytesParser`, producing a proper `Message` object.
* Attach the parsed message directly, letting the email library handle correct encoding and transfer settings automatically.

opw-4655868

Forward-Port-Of: odoo/odoo#230384
Forward-Port-Of: odoo/odoo#223790

Sometime, the test `test_scrap_change_source_location` could fail randomly. The issue happens in last few steps of the tour. What we do is:
- We edit a move line lot in the form view;
- We save it;
- We validate the operation.

The validation is done by a barcode scan (`OBTVALI`) but since [1](https://github.com/odoo-dev/enterprise/commit/b3a855a870d1861515abaff8683081a39f95558f), barcodes scanned when the user is somewhere else than in the barcode lines view are skipped.
With a little bit of bad luck, the tour scans `OBTVALI` while the save from the form view is not finished yet and thus, the scanned barcode is ignored.

To reproduce that, run the test `test_scrap_change_source_location` locally in debug mode and add a throttling (eg.: Fast 4G) before to run the tour.

To solve the issue, finetune the `validateBarcodeOperation` default trigger, so the error won't happen in this tour and other similar contexts.

Runbot build error: [232331](https://runbot.odoo.com/odoo/runbot.build.error/232331)

Forward-Port-Of: odoo/enterprise#96542

This module adds support for "codaclean" integration.
CODA files can be periodically (or on demand) fetched from codaclean
and imported into bank journals.
The module only connects to the IAP server.
The IAP side does the actual calls to codaclean (with a secret API key).

To use the module you have to create a connection to IAP / codaclean
and set up a bank journal:
- To manage the connection to IAP / codaclean go to
  Settings -> Accounting -> Codaclean -> Manage Connection
- To set up the bank journal you need to configure the following
  in the "Journal Entries" tab on the journal:
  - Put the IBAN in the "Bank Account Number" field
  - Select "Codaclean Synchronization" for the "Bank Feeds" field

Coda files will be automatically fetched 2 times per day via the
scheduled action called "Accounting: Sync Coda Files from Codaclean".
They can also be manually fetched by clicking "Fetch from Codaclean"
below the journal on the accounting dashboard (only available
when the journal and connection are setup correctly).

On an empty journal we start fetching from 1 year ago.
When the journal is not empty we start fetching after the last bank statement
/ bank statement line in the journal.

task-4844423

backport of commit 518ab9e

Forward-Port-Of: odoo/enterprise#95747

When users try to access a `slide ID` that is not included in `channel_slides_ids`, a traceback occurs.

Steps to reproduce:
---
- Install `website_slides` module
- Go to the Website and click on the `Courses` menu.
- Then go to `/slides/embed/<int:slide_id>` route. (http://localhost:8069/slides/embed/7)
- The error will occur.

Traceback:
---
`ValueError: 7 is not in list`

At [1], `slide_content_ids` contains the IDs of `channel content`. However, we are trying to access a slide from the `channel category` in URL. As a result, at [2], when attempting to find the index of the slide in `slide_content_ids`, an error occurs because the slide ID actually belongs to `slide_category_ids` and is not present in `slide_content_ids`.

Solution:
---
Added a special case for category slides — if the slide is a category, redirect to the channel homepage.

[1]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L120 [2]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L121

sentry-6572999628

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

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

Steps
-----
1. Have a coupon program;
2. add a 10% discount on order reward for 1 point;
3. add a 50% discount on order reward for 5 points;
4. generate a coupon with 10 points;
5. use coupon code on a confirmed order;
6. select 10% discount reward;
7. change to a 50% discount reward;
8. check coupon point total.

Issue
-----
Even though the 5 point reward was used, only 4 out of 10 points remain.

Cause
-----
When updating the reward line of a confirmed order, it keeps track of point cost changes before & after a write. Its purpose is to restore back the point difference on the coupon record.

The issue is that while point changes are stored, coupon changes are not. When updating reward lines, `_reset_loyalty` is used, which removes the `coupon_id` from the lines. As a consequence, attempting to restore the point difference on `line.coupon_id` after an update, it writes to an empty record.

Solution
--------
Store both coupons & their used points before write. After write, restore the previous points to the previous coupon, and subtract the current point cost from the current coupon.

This way, any combination of coupon/point changes should have the points updated as expected.

opw-4910922

Forward-Port-Of: odoo/odoo#222054

## Issue 1: "Allow Extra Products" option ignored for packages

### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehouse Management > Operation Types
- Disable "Allow Extra Products" on the "Delivery" operation type
- Create two storable product P1, P2 and add on hand quantities
    - 10 x P1 in a package PACK01
    - 10 x P2 in a package PACK02
- Create and confirm a delivery for 10 unit of P1
- Open your delivery from the barcode app
- Scan PACK02
#### > The content of PACK02 is added to the delivery even thought it contains extra products.

### Cause of the issue:

The check for extra products is only applied when scanning individual products but is bypassed by package scan. To be more precise, the `barcode_allow_extra_product` option is checked in the public method `createNewLine`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L59-L80
While this method is called at new line creation when a product is scanned, scanning a package will add new lines during the  `_processPackage` adn bypasses the rest of the `_processBarcode`:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_model.js#L1261-L1267
The issue being that the `__processPackage` does not check the  `barcode_allow_extra_product` option and creates its new lines via the  private `_createNewLine` call:
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1564-L1565
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1655-L1667
https://github.com/odoo/enterprise/blob/331442fd9cbd59d542432b2237299df9497ce241/stock_barcode/static/src/models/barcode_picking_model.js#L1671

### Fix:

Since scanning a package is expected to add all its content to the  picking, and since a package can not be split among two locations, it is necessary to check in advance if any product of its content is extra and avoid any update in this case.

## Issue 2: impossibility of package line removal

### State of the art:

There is currently no option to remove a package line from the barcode. In particular, once the option `show_entire_packs`(Move Entire Packages) is enabled on a picking type, you can not remove the package line once generated by a scan.

#### Steps to reproduce:

- In the settings enable "Packages"
- Go to Inventory > Configuration > Warehoue Management > Operation Types
- Enable "Move Entire Packages" on the "Delivery" operation type
- Create a storable product and add on hand quanties:
    - 10 units in package PACK01
    - 10 units in package PACK02
- Create and confirm a delivery for PACK01 (in the package lines)
- Open your delivery from the barcode app
- Scan PACK02
#### > The new line associated to PACK02 can not be removed by any mean

opw-4863621
opw-5080637

This is the backport of https://github.com/odoo/odoo/pull/225558/commits/2373808e9768afa5a1a56dbd1491ebd13da3f88a

Issue:
In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name.

Steps to reproduce:
- Activate Cash Basis in the accounting settings
- Create a tax with "Tax Exigibility" set "Based on Payment"
- Set the "Cash Basis Transition Account" to "Current Assets"
- Activate reconciliation on "Current Assets"
- Create an invoice with this tax, confirm
- In the dashboard, click on Bank and new
- Set the name of the invoice as the label, and the amount of the invoice as amount
- Save & Close
- Go in Accounting > Transactions > Journal Items
- The lines created for the cah basis entry display '/' in the column "Journal Entry"

Cause:
This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned.

When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`. The callstack is something like this:
- `_set_next_sequence()` calls `_locked_increment()` to compute the sequence
- `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields
- `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()`
- `_compute_needed_terms()` needs `invoice_line_ids`
- the fetch on `account.move.line` is ordered by `move_name`
- So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute` Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`.

This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache.

Solution:
Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards.

It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`.

Enterprise PR - https://github.com/odoo/enterprise/pull/96721

opw-4747878

This is the backport of https://github.com/odoo/enterprise/pull/94111/commits/e379cf04cc1aa97d28d73566daadad193310ae9a

Issue:
In the list view of Journal Items, cash basis lines show a `move_name` of '/' event if the move is posted and has a name.

Steps to reproduce:
- Activate Cash Basis in the accounting settings
- Create a tax with "Tax Exigibility" set "Based on Payment"
- Set the "Cash Basis Transition Account" to "Current Assets"
- Activate reconciliation on "Current Assets"
- Create an invoice with this tax, confirm
- In the dashboard, click on Bank and new
- Set the name of the invoice as the label, and the amount of the invoice as amount
- Save & Close
- Go in Accounting > Transactions > Journal Items
- The lines created for the cah basis entry display '/' in the column "Journal Entry"

Cause:
This issue is linked to the order in which things are done in `_set_next_sequence`: the fields triggered by the sequence field are added in `self.env.transaction.tocompute` then the sequence is computed and assigned.

When `_set_next_sequence()` is called from [`_create_tax_cash_basis_moves()`](https://github.com/odoo/odoo/blob/849e4a87178d8c8588b75e3f7d9073d6a78326f9/addons/account/models/account_partial_reconcile.py#L649-L654) this order is problematic as `account.move.line.move_name` will be computed and removed from `self.env.transaction.tocompute`. So it will not be updated when the sequence is assigned in `account.move.name`. The callstack is something like this:
- `_set_next_sequence()` calls `_locked_increment()` to compute the sequence
- `_locked_increment()` calls `flush_recordset()` which will call `_recompute_recordset()` to recompute all fields
- `_compute_invoice_date_due()` needs the field `needed_terms` triggering `_compute_needed_terms()`
- `_compute_needed_terms()` needs `invoice_line_ids`
- the fetch on `account.move.line` is ordered by `move_name`
- So `_compute_related()` is triggered for `move_name` and `account.move.line.move_name` is removed from `self.env.transaction.tocompute` Then `_locked_increment()` returns the sequence, it gets assigned as the move name and `move_name` is never updated because it's not in `self.env.transaction.tocompute`.

This doesn't occur in other flows (like calling `action_post()`) because the value of `needed_terms` is read from the cache.

Solution:
Swap the order in which things are done in `_set_next_sequence()`: first compute and assign the sequence and then add the triggered fields in `self.env.transaction.tocompute` so that they are computed afterwards.

It seems more logic that way: we change the `_sequence_field` then mark all fields that will be impacted in `tocompute`.

Community PR - https://github.com/odoo/odoo/pull/230751

opw-4747878

**PROBLEM**
When hiding a HtmlField field from a view with pending images in it, there is a traceback.

**STEP TO REPRODUCE**
1. Using studio, create a HtmlField on the view of your choice.
2. Add a checkbox next to it, and link the HtmlField visibility to the button.
3. Add a image to the HtmlField (don't save the record !)
4. Hide the HtmlField using the checkbox, there should be a traceback. (if not, try with a bigger image).

**CAUSE**
commitChanges() will try to retrieve the field value to commit by looking at the related element in the DOM. Before retrieving this value, we call savePendingImages() to save the new images added to the HtmlField. https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/html_editor/static/src/fields/html_field.js#L159-L162 This introduces a delay, during which the DOM element could be destroyed.

**FIX**
We don't call commitChanges() in OnBlur(). Instead, we cache the new value in a property of HtmlField called `newValue` when `OnChanges()` is called. Inside OnBlur(), we save the pending images by directly calling `savePendingImages()` and we commit the new value by calling `updateValue(this.newValue)`

opw-5061820

Chrome iOS wraps some text nodes (like measures, email...) with a
`<chrome_annotation>` tag, which breaks OWL rendering.

This commit works around it by adding the (undocumented) `<meta
name="chrome" content="nointentdetection">` tag to disable this Chrome
behavior. The tag has to be set before the onDOMContentLoaded event to
be taken into account.

Note: Looks like this behavior was present in Chrome iOS 127 and
disabled afterward (because it already had issues) but it appeared again
in version 140-141.

References:
- https://issues.chromium.org/issues/353650041
- https://issues.chromium.org/issues/388718411
- https://stackoverflow.com/questions/78207646/how-do-i-disable-chrome-annotation-tags
- https://stackoverflow.com/questions/78575970/prevent-auto-detection-of-phone-numbers-in-chrome-mobile
- https://stackoverflow.com/questions/78725191/stop-chrome-ios-auto-detecting-numbers-followed-by-letter-m-as-metre-units-an
- https://github.com/solidjs/solid/issues/2235

opw-4969197

Forward-Port-Of: odoo/odoo#230081

Using standard Odoo, `maintenance.request.close_date` should never be `False` when its `stage_id == 'done'`, but customizations/manual overrides allow users to force it to be `False` and block them from opening equipment views that displayed fields that depended on it.

Steps to reproduce:
- Create new maintenance request for an equipment
- Put maintenance request into a `maintenance.stage` where `done=True` (e.g. "Repaired")
- Force `close_date` to not be `readonly` in form view + set it to `False`
- Try to open the assigned equipment's form view

Expected result:
Form view opens without issue

Actual result:
`unsupported operand type(s) for -: 'bool' and 'datetime.date'`

Issue was due to `mttr` calculation in `_compute_maintenance_request` not expecting `close_date` to be `False`. Since we want the request to still be considered for the rest of the compute, we count its "Time to Repair" as 0 in this case since we cannot use infinity in this case. Additionally, we also gracefully fail in the same way in case `request_date` is also forced to be `False` since it is not a mandatory field and can cause the same issue.

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