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

**[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

Validating a stock picking for a POS order currently raises an error.

**Steps to Reproduce:**
1) Install Point of Sale(with Demo)
2) Navigate to POS>Configuration>Settings and enable **Allow Ship Later**. 
3) Create a Storable product(P1) with 0 quantity and make sure it has a productcategory with **Perpetual (at invoicing)** configured.
4) Open a session having this new product.
5) Select P1 and make payment with the shiplater option and close the session.
 6) Open Picking for this order. (POS>Orders>Orders open order and click on **picking** smart button)
7) Set the quantity for the product and click on **Validate**.

Error:
`KeyError: 'stock_output'`

Root Cause:
Since [this commit](https://github.com/odoo/odoo/commit/08b62a4bbcc6f9a391b2cc00a621ef4c76100229#diff-f7d6ecfdde1475832cb3ed0b2319dc38ecd1c43459363b4494ba16023041a72fL176), the code was refactored and `stock_output` was removed from `_get_product_accounts`. However, it is still accessed at [1], causing a `KeyError`.

Fix:
Remove `_action_done` method at [1] as it has no longer significance.

[1]- https://github.com/odoo/odoo/blob/b81d119fae5f5194334cee94bacffefeb1cd8c6e/addons/point_of_sale/models/stock_picking.py#L133

sentry-6914404210

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

The system will crash with error when user tries to Post Journal Entries of expense.

**Steps to produce:**
- Install `Accouting, Expense, Payment provider demo` module without demo data.
- Create new company (Do not set the country) and switch to that company.
- Set the demo payment provider state to `test`. (You may have to create `new journal` and in that `new `suspense account` also.)
- Go to `expense` and create new record.
- Set the `paid by` as `company` and also set `account` and `employee`.
- Click on `Submit` and then click on `Post Journal Entries`.

**Error:**
`TypeError: 'NoneType' object is not subscriptable`

**Cause:**
- When we create new company then there is no default chart accounting template is set until we set the country of the company.

**Solution:**
- If the Chart template is not set in the company, then we simply raise the `Usererror`.

**sentry-6920693674**

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

Before this commit:
-------------------------
When multiple Manufacturing Orders (MOs) were linked to a single Sales Order,
Clicking the Delivery smart button caused a traceback error.

Steps to reproduce:
-------------------------
1. Install the 'sale' and 'sale_mrp' module.
2. Create a Sales Order (SO) for 10 units of ProductA.
3. Enable Allocation Reports in Manufacturing.
4. Create a Manufacturing Order (MO) for ProductA with 5 units.
      - Produce all quantities.
      - Assign the produced quantity to the Sales Order.
5. Create a second MO for ProductA with 5 units.
      - Produce all quantities.
      - Assign the produced quantity to the Sales Order.
6. Return to the Sales Order and click the Delivery smart button, and a
   traceback occurs.(ValueError: Expected singleton: stock.reference(42, 43))

Cause of the issue:
--------------------------------------
- The expression self.stock_reference_ids[:-1].id assumed the presence of a
  single record.
- When multiple stock.reference records were linked, slicing the recordset
  (self.stock_reference_ids[:-1]) returned multiple values, causing a
  singleton error during evaluation.

After this commit:
-----------------------
- Removed unnecessary default value handling, as it always returned False,
  making it redundant.
- The Delivery smart button now correctly handles multiple MOs linked to the
  same SO without causing traceback errors.
- This change only refines the logic for safer multi-record handling without
  altering any existing functionality.

Opw-5148852

Currently an error occurs when user creates the helpdesk ticket.

Steps to Reproduce:

 - Install the `helpdesk` module.
 - Go to `Stages` and, in the `Kanban view`, open the `New Stage` record.
 - Set a value `greater than 0` in the `Days to rot` field.
 - Go to `Tickets` and click `New`.

`TypeError: unsupported operand type(s) for +: 'bool' and 'datetime.timedelta'`

This error occurs when a user sets the Days to rot value greater than zero in a new stage. When creating a helpdesk ticket, the compute method runs and filters the records[1] to check which records have stayed too long in their current stage based on the last stage update date or create date. For the current record, both of these fields are not set now, which raises the error[1].

This commit ensures that if the record does not have a last stage update or create date, the current date and time will be used instead.

[1]- https://github.com/odoo/odoo/blob/7748345e11b542b00656d3586767e064c2d1e2e8/addons/mail/models/mail_tracking_duration_mixin.py#L183

sentry-6927500374


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

When a user tries to print an invoice with section lines for Hungarian company, a traceback occurs.

Steps to reproduce the error:
- Install ``l10n_hu_edi`` module with demo data and switch to ``HU Company``
- Create an invoice > Add a seaction >Add a line under that section > Save
- Confirm > Print

Traceback:
```py
QWebError: Error while rendering the template:
TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'
```

https://github.com/odoo/odoo/blob/dc6dd927faea1f4501d6c50c586d5ea46bd1fc95/addons/l10n_hu_edi/views/report_invoice.xml#L84-L86
Here, ``current_subtotal`` is used instead of ``section_subtotal``.
So, It will lead to the above traceback.

``current_subtotal`` was changed to ``section_subtotal`` in the commit [1],
but the t-out attribute in the same block was not changed accordingly.

[1]: https://github.com/odoo/odoo/commit/af9bf2ac1939aa8d64c4ba5caa202b229debba3f

sentry-6933103730

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