*: pos_restaurant, pos_online_payment_self_order, pos_self_order

When self-ordering is enabled and in pay after each mode, the table
selection was handled via table_id fields, which caused issues when a
customer had an issue with its payment and wanted to pay later. It was
blocking the table with its order, so if another customer wanted to
scan the same QR code, it would not be able to add anything to the cart.

Now in pay after each mode, the table selection is handled via
floating_order_name, which allows the order to be processed without
blocking the table. This way, the table can be reused for another
customer, and the order can be paid later.

---

Regarding direct sale in `point_of_sale`, when a customer wanted to pay
by card the order was synced with the server when the waiter clicked on
the payment method, if the direct sale had no table and no floating
order name, when synching on other devices the order was blocking them.

Now if no table and no floating order name is set, when synching the
order, the pos_reference is set to the floating_order_name, which
prevents the order from blocking other devices.

---

Regarding self order cancellation from a PoS, when the waiter was
cancelling an order it was not synced with the self-order app, which
caused the self-order app to keep the order in the cart, preventing the
customer from starting a new order.

---

Regarding self order ticket printing, when an order arrives on the PoS
to be printed, we were trying to print the preparation ticket and
the customer ticket at the same time, which caused issues with the
printing. Now we printing them one after the other.

Forward-Port-Of: odoo/odoo#222180

[FIX] html_editor: prevent `o_editable_media` class to add `o_dirty`

Before this commit, when the `o_editable_media` class was added on an
element, its closest view was marked as dirty, because of the mutation
it was adding.

This commit fixes that by making this class a system class, so its
mutations are always filtered out.

Steps to reproduce:
- Go in edit mode with eCommerce installed.
- In the header, inspect the shopping cart button and see that its view
  does not have the `o_editable_media` and `o_dirty` classes.
- Change a header option and inspect the button again.
=> the `o_editable_media` class was added, as well as `o_dirty`, because
of that class addition.

task-4367641

---
[FIX] html_builder: prevent drag and drop to add unwanted `o_dirty`

Before this commit, drag and dropping elements from the sidebar or from
the page would add the `o_dirty` class on every views in which dropzones
appeared, creating many views in DB for no valid reason when saving.

This commit fixes this issue by:
- not observing the dropzones addition/removal anymore,
- preventing the drag mutations to mark elements as dirty until we
  finally drop the dragged element.

task-4367641

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Put your warehouse in manufacture in 3 steps
- Create a storable product P
- Create and confirm an MO for 1 unit of P
- Go to Inventory > Operations > Procurement > Replenishment
- Create a new one for P in WH/stock
#### > The forecasted quantity in stock is still 0 but should be at 1, just as if the the MO had been generated using the    replenishment for 1 unit

### Cause of the issue:

When an MO is created using a procurement, a `location_final_id` is set to WH/Stock on the MO and propagated on the move for the finished product:
https://github.com/odoo/odoo/blob/8d4e6df0c0ac5ebc6362f3578ae8cc8edf4a76f7/addons/mrp/models/stock_rule.py#L165 https://github.com/odoo/odoo/blob/8d4e6df0c0ac5ebc6362f3578ae8cc8edf4a76f7/addons/mrp/models/mrp_production.py#L1169-L1175 As such, even if the manufacturing is now handled in push, this move will contribute positively to the forecast in the `virtual_available` quantity of the product in WH/Stock bevause of the `location_final_id`. By contrast, if hte MO is created by hand, it does not bear a `location_final_id` so that the MO can only contribute to the stock forecast has been processed and the related internal transfer `WH/post-prod -> WH/Stock` is created.

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

Forward-Port-Of: odoo/odoo#221462
Forward-Port-Of: odoo/odoo#221003

Currently below error occurs while archive/unarchive company:
- Company list is not being updated.
- In `hr_timesheet` KeyError will be encountered on unarchiving a company.
- In `l10n_it_pos` module an AccessError will be encountered on unarchiving a company.

**Root Cause:**
Since https://github.com/odoo/odoo/commit/22e9d822e8cab08114c006eb8c4054c4de0c40f2, the `session_info` method relies on `user_companies` at [1], which fetches only
active company IDs via `_get_company_ids()`. However, `_get_company_ids` uses caching as
shown at [2]. When a company is archived or unarchived, 'write' method is called. Now, here
the cache is invalidated before writing to the company as shown at [3]. Due to which
'_get_company_ids' method doesn't receive the updated list of companies, causing this issue.

**Solution:**
This commit prevents error by ensuring companies are stored before invalidating
the cache.

[1]- https://github.com/odoo/odoo/blob/d3482e32f7dbe273125de84f1bbc434ac3c9ffc3/addons/web/models/ir_http.py#L146

[2]-
https://github.com/odoo/odoo/blob/7db62d6d65bd57f6ed43ce52a820cf03df19efdd/odoo/addons/base/models/res_users.py#L927-L931

[3]-
https://github.com/odoo/odoo/blob/3173a5f993a3ffa3d3a14d29713142e5b6b314d9/odoo/addons/base/models/res_company.py#L343-L367

Sentry-6251348500

Forward-Port-Of: odoo/odoo#222251
Forward-Port-Of: odoo/odoo#219044

Steps to Reproduce:
1. Go to the website.
2. Create a new menu (e.g., 'Test 1') using the 'Edit Menu' option and add it under another menu (e.g., 'Contact Us'), creating a sub-menu. 
3. Turn on the developer mode.
4. Go to Configuration -> Menus and add two menus (e.g., 'menu 1' and  'menu 2') under the new sub-menu (e.g., 'Test 1').
5. Notice that the two menus ('menu 1' and 'menu 2') are not visible on the website.

Description:
As per functional specifications, creation of multi-level sub-menus should not be allowed.

Key Changes:
raises a `UserError` if a menu exceeds the two-level hierarchy by checking the parent and grandparent levels.
- Implements mega menu restrictions:
    - A mega menu cannot have a parent menu.
    - A mega menu cannot have child menus.
    - Any menu cannot be a child of a mega menu.
- Prevents menus with child menus from being added as submenus to existing menus.

This ensures that the website menu structure adheres to the defined functional specifications, providing a consistent and predictable user experience.

task-3901371

Forward-Port-Of: odoo/odoo#222254
Forward-Port-Of: odoo/odoo#168801

Steps:
-------------------------------------------------
- Set up a database without demo data.
- Open Cloth Shop POS.
- Click on load sample data.

Issue:
-------------------------------------------------
Data doesn't load.
(Traceback in terminal for not found external ID)

Cause:
-------------------------------------------------
Commit https://github.com/odoo/odoo/commit/ffb976c3ed5fbcff2e5d06a3183bab2fbe0307ff moved demo data from point_of_sale to product. The issue is that point_of_sale uses a custom 'scenario' flow where demo data gets loaded for a specific scenario. As a consequence, any reference to demo data from the product will cause an error.

Solution:
-------------------------------------------------
- Move the shoe size attribute back to the pos cloth scenario from product.
- Load attribute from the product when we click on Load Sample Data in the cloth shop.

task - 5002430


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

If the editing element has no `oeContactOptions`, the selector would compare against the string `"undefined"`. That selector is supposed to select the ones with a different option, but in that case, other fields without contact options would get selected. The selector was ported from the previous builder during the intial [website builder refactor]

This caused the editing element to be present twice in the loop if it had no contact options (in addition to contain extra elements). And setting twice the same text content triggers a bug in the history, which behaves incorrectly when it is undone. (the bug is known and described in the code by a comment `@todo: this removes mutation records that change the node reference. Fix this`)

Steps to reproduce:
- On `/blog`, open website builder
- Change a post's category (name next to the folder icon under summary)
- Undo
- Bug: the text content is the concatenation of both category

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-4367641

When tax integrations are sent from a credit note (of a vendor bill) they should have a negative value, as it is the reversal operation. However, currently the amounts are positive, so it appears to be a second Bill rather than its reverse.

**Steps to reproduce (with an IT Company)**

- Create a non-eu [PARTNER] with complete address and VAT
- Create a Vendor Bill with:
  - Partner: [PARTNER]
  - Electronic Invoicing > Document Type set to TD18
  - A line having Reverse charge tax (ie. 22% G RC)
- Confirm and send tax integration
- Reverse move
- Ensure the document type is set to TD18 as well
- Confirm and send tax integration
- Check the generated xml

**Issue**

Credit note tax integration will have a positive amounts, while being a credit note it should have negative amounts This occurs because when generating the xml, the document type is recomputed from the invoice features, even if the user set it manually

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4788529)
opw-4788529

Forward-Port-Of: odoo/odoo#221672
Forward-Port-Of: odoo/odoo#220878

Before this change, the VAT Content section in Argentinean Legal PDF was always shown as "VAT Content" although the user has Spanish as its language.

With this change will show the correct translation: "IVA Contenido" when printing the PDF report in Spanish.

### **Description of the issue/feature this PR addresses:**
Missing Spanish translation of "VAT Content" column in the Argentinean Legal PDF Report

1. Install Argentinean - Accounting module
2. Install Spanish language
3. Log into to one of the demo Argentinean Companies: (AR) Responsable Inscripto
4. Create a customer invoices of type "B"
5. Go to the partner and change the Language to Spanish
6. Return to the invoice and print the PDF
7. Check that the VAT Content section is not translated.

### **Current behavior before PR:**
<img width="572" height="407" alt="image" src="https://github.com/user-attachments/assets/e28e609e-2cd2-4ace-9509-f969692ec893" />

### **Desired behavior after PR is merged:**
The "VAT Content section should appear as "IVA Contenido" when printing the report in Spanish.


opw-4938520

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

Forward-Port-Of: odoo/odoo#221832
Forward-Port-Of: odoo/odoo#219912

Currently a below occurs or content is not receiving to odoo WhatsApp when the user uploads a large file (tried with > 35 MB).

Stack Trace:
```
MemoryError: null
  File "odoo/http.py", line 2383, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1913, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1976, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1943, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2187, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/controller/main.py", line 42, in webhookpost
    wa_account_id._process_messages(value)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/models/whatsapp_account.py", line 206, in _process_messages
    datas = wa_api._get_whatsapp_document(messages[message_type]['id'])
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/tools/whatsapp_api.py", line 236, in _get_whatsapp_document
    file_response = self.__api_requests("GET", file_url, auth_type="bearer", endpoint_include=True)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/tools/whatsapp_api.py", line 46, in __api_requests
    if 'error' in res.json():
  File "requests/models.py", line 971, in json
    return complexjson.loads(self.text, **kwargs)
  File "requests/models.py", line 928, in text
    encoding = self.apparent_encoding
  File "requests/models.py", line 793, in apparent_encoding
    return chardet.detect(self.content)["encoding"]
  File "__init__.py", line 49, in detect
    detector.feed(byte_str)
  File "chardet/universaldetector.py", line 274, in feed
    if prober.feed(byte_str) == ProbingState.FOUND_IT:
  File "chardet/charsetgroupprober.py", line 70, in feed
    state = prober.feed(byte_str)
  File "chardet/hebrewprober.py", line 240, in feed
    byte_str = self.filter_high_byte_only(byte_str)
  File "chardet/charsetprober.py", line 73, in filter_high_byte_only
    buf = re.sub(b"([\x00-\x7F])+", b" ", buf)
  File "__init__.py", line 186, in sub
    return _compile(pattern, flags).sub(repl, string, count)
```

At line [1], the code `'error' in res.json()` is used, which reads all the json content of `res`, but at times users upload large files, it will cause the above error because the `json()` tries to read all bytes from res, which is a very large amount to handle in memory.

This commit will fix the above issue by returning a response if the response
contains content_length more than 10 MB.

[1] - https://github.com/odoo/enterprise/blob/aca7ae2a7cf4aad5427a60d5cad60d08774357d0/whatsapp/tools/whatsapp_api.py#L46

sentry-5810101850

Forward-Port-Of: odoo/enterprise#70001

This PR is divided in 2 commits:

A first commit is an implementation AU specific and will create the lines related to tax on
salary in the tax return closing entry. Before this commit, these lines
weren't taken into account in the closing entry.
The condition to select the account.move.line are the following:
- The journal item has a "W2", "W3" or "W4" (Withholding Tax) tax grid 
whose journal entry is linked to an hr.payslip.
- The journal item does not have an originating tax record (i.e.,
tax_line_id is empty).
- The journal item is posted to a tax provision account (i.e., a balance
sheet one) as defined on the salary rule.

A second commit fixes a bug: the manifest of the l10n_au_hr_payroll_account module was having a
'countries': ['au'] dependency, that was adding a condition to the
dependencies to auto install the module: we expect an existing AU
company in DB. But for example if the user installs l10n_au, the
condition is evaluated at the moment he clicks on install, and no AU
company exists at that time.

Task-4921992

Forward-Port-Of: odoo/enterprise#90422

Issue:
When the "Lock Confirmed Sales" setting is enabled, adding a product to a Field Service task would lock the associated sales order before its picking could be created. The confirmation process locks the order first , and the subsequent step to create stock moves (`_action_launch_stock_rule`) explicitly skips locked orders.

Reproducible on 17.0~master
[Task](https://www.odoo.com/odoo/action-4043/4633977)
Odoo 17:
https://drive.google.com/file/d/1qmAYhSu6gU91efuJEDF-Irn2cLGUQP0A/view?usp=drivesdk

Odoo 18:
https://drive.google.com/file/d/1x8IeXwT7ZFM7Av9Vp6GSvGIbOaEGfmVx/view?usp=drivesdk


Steps to reproduce:
1. In Sales > Configuration > Settings, enable "Lock Confirmed Sales".
2. Go to a Field Service task.
3. In the kanban view via the "Products" smart button, add a product.
4. Come back to the task, refresh the browser, open the linked Sales Order from the smart button.
5. **Before this fix:** The SO is locked, no picking is created, and SO lines will have delivered_qty set even though we haven't delivered anything.
6. **After this fix:** The SO is not locked, and a Delivery smart button is correctly displayed, linking to the generated picking.

This behavior left the sales order in an inconsistent state: it was locked, but had no corresponding delivery order. As a result, users were blocked from removing or modifying the products added to the task, as the system prevented edits on a locked order with no picking to cancel.

Let's step through what's going on here;

0. We enable "Lock Confirmed Sales" option.
1. Add a product to the Field Service(FS) task https://github.com/odoo/enterprise/blob/4256ea170c31209b83ff808e51145757571f8556/industry_fsm_sale/controllers/catalog.py#L19-L42
https://github.com/odoo/enterprise/blob/4256ea170c31209b83ff808e51145757571f8556/industry_fsm_sale/controllers/catalog.py#L38
2. set_fsm_quantity() is invoked, which will create a SO for the FS task https://github.com/odoo/enterprise/blob/35e1f47160d5840e8701fc0ad43ec42bbfaf9e36/industry_fsm_sale/models/product_product.py#L144
3. `_fsm_create_sale_order()` will immediately `action_confirm()` the new SO, because of the reasons in the function description. 
( Since we are immediately confirming newly created SO, I think we should consider not applying the "Lock Confirmed Orders" option to FSM SOs.)
https://github.com/odoo/enterprise/blob/2347dac2568dbcf83578f044f8fe41ab70a20f47/industry_fsm_stock/models/project_task.py#L124-L134 https://github.com/odoo/enterprise/blob/2347dac2568dbcf83578f044f8fe41ab70a20f47/industry_fsm_stock/models/project_task.py#L134
4. `odoo/addons/sale/models/sale_order.py/action_confirm()` will lock SO because we enabled 'Lock Confirmed Sales'
https://github.com/odoo/odoo/blob/863c064fd911cb4eeedad0abec82adb4690128f6/addons/sale/models/sale_order.py#L964
6. `_action_launch_stock_rule()` is invoked, is in charge of creating Pickings for SOs 
https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L303
https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L343-L344
7. But, since `line.order_id.locked` , the system do not create Pickings for the SOs. https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L315-L316
The line was introduced by
https://github.com/odoo/odoo/commit/17bece3e797913bcba8dd7e07fc8541c0a45e3f7

This commit resolves the issue by passing a context key `fsm_create_sale_order=True` when confirming a sales order that is being created from a Field Service task. The `_should_be_locked` method on the sale order is overridden to check for this context key. If the key is present, it prevents the order from being locked within that specific transaction, allowing the stock rules to execute correctly and create the necessary picking. The order will be locked for any subsequent operations as intended.

Tradeoff here;
We are sacrificing the universal application of one feature (automatic lock on confirmed sales order) to fix a critical bug that makes the entire FSM delivery process unusable.

---
EDIT: 
Without this change, all of [test_fsm_stock](https://github.com/odoo/enterprise/blob/17.0/industry_fsm_stock/tests/test_fsm_stock.py)'s test cases that use `_fsm_ensure_sale_order()` will fail if the setting is on. (around ~20 test cases). 

[In the past, similar issue occurred for Subscription Orders, and the PO confirmed that the "Lock Confirmed Order" setting should never affect the subscriptions. ](https://github.com/odoo/enterprise/commit/e4f9d76c0a58f3cc226a2372f3936cea4547312e). This commit takes the same approach to ignore the setting upon SO confirmation. 

opw-4633977
opw-4749653
opw-4880664

Forward-Port-Of: odoo/enterprise#91799
Forward-Port-Of: odoo/enterprise#88855

**Steps to reproduce**:
1. Install the `account` module.
2. Create a Invoice using this any product.
3. add long descripition (approx. 40-45 lines).
4. Print the PDF of Invoice (via gear icon).

**Observation**:
The long product description overlaps with the table header when the table spans multiple pages in the generated PDF.

**Issue**:
wkhtmltopdf does not handle multi-page table headers properly by default. causing header/content overlap when the table breaks across pages.

**Solution**:
Apply a known wkhtmltopdf workaround by explicitly setting:
  `<thead style='display: table-row-group;'>`
This ensures headers will not repeat same as this. [#53909](https://github.com/odoo/odoo/pull/53909)

before:
<img width="818" height="231" alt="image" src="https://github.com/user-attachments/assets/8bcc6ced-5911-4abd-b91e-97ffa8fb735e" />

after:
<img width="821" height="253" alt="image" src="https://github.com/user-attachments/assets/2ccc6995-c239-4beb-8f68-53d548b7f2f2" />

opw-4982735

Forward-Port-Of: odoo/odoo#222286
Forward-Port-Of: odoo/odoo#221681

Description of the issue/feature this PR addresses:
When a user updates the subject on a template used for a survey, it does not pull the subject from the template. It uses the default subject that is used when computing the subject for a survey email that is sent out. This bug came as a part of [this commit](https://github.com/odoo/odoo/commit/220e0271bf43e914950b8ae0d4a1cca5f3ea6d9c).

I've used an elif condition over here as opposed to calling super which was being done before so that the default of Participate to X survey still becomes the default subject. 

opw-4654411

Steps to reproduce on runbot:
1. Go to mail templates and search for Survey
2. Open the Survey: Invite template
3. Update the subject on this template
4. Open the Surveys app and select any survey
5. Click on Share and then enable send by email
6. The subject here will default to "Participate to {Survey Name}"

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

Forward-Port-Of: odoo/odoo#219122
Forward-Port-Of: odoo/odoo#211153

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Put your warehouse in manufacture in 3 steps
- Create a storable product P
- Create and confirm an MO for 1 unit of P
- Go to Inventory > Operations > Procurement > Replenishment
- Create a new one for P in WH/stock
#### > The forecasted quantity in stock is still 0 but should be at 1, just as if the the MO had been generated using the    replenishment for 1 unit

### Cause of the issue:

When an MO is created using a procurement, a `location_final_id` is set to WH/Stock on the MO and propagated on the move for the finished product:
https://github.com/odoo/odoo/blob/8d4e6df0c0ac5ebc6362f3578ae8cc8edf4a76f7/addons/mrp/models/stock_rule.py#L165 https://github.com/odoo/odoo/blob/8d4e6df0c0ac5ebc6362f3578ae8cc8edf4a76f7/addons/mrp/models/mrp_production.py#L1169-L1175 As such, even if the manufacturing is now handled in push, this move will contribute positively to the forecast in the `virtual_available` quantity of the product in WH/Stock bevause of the `location_final_id`. By contrast, if hte MO is created by hand, it does not bear a `location_final_id` so that the MO can only contribute to the stock forecast has been processed and the related internal transfer `WH/post-prod -> WH/Stock` is created.

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

Forward-Port-Of: odoo/odoo#221462
Forward-Port-Of: odoo/odoo#221003

*: pos_restaurant, pos_online_payment_self_order, pos_self_order

When self-ordering is enabled and in pay after each mode, the table
selection was handled via table_id fields, which caused issues when a
customer had an issue with its payment and wanted to pay later. It was
blocking the table with its order, so if another customer wanted to
scan the same QR code, it would not be able to add anything to the cart.

Now in pay after each mode, the table selection is handled via
floating_order_name, which allows the order to be processed without
blocking the table. This way, the table can be reused for another
customer, and the order can be paid later.

---

Regarding direct sale in `point_of_sale`, when a customer wanted to pay
by card the order was synced with the server when the waiter clicked on
the payment method, if the direct sale had no table and no floating
order name, when synching on other devices the order was blocking them.

Now if no table and no floating order name is set, when synching the
order, the pos_reference is set to the floating_order_name, which
prevents the order from blocking other devices.

---

Regarding self order cancellation from a PoS, when the waiter was
cancelling an order it was not synced with the self-order app, which
caused the self-order app to keep the order in the cart, preventing the
customer from starting a new order.

---

Regarding self order ticket printing, when an order arrives on the PoS
to be printed, we were trying to print the preparation ticket and
the customer ticket at the same time, which caused issues with the
printing. Now we printing them one after the other.

Steps to Reproduce:
1. Go to the website.
2. Create a new menu (e.g., 'Test 1') using the 'Edit Menu' option and add it under another menu (e.g., 'Contact Us'), creating a sub-menu. 
3. Turn on the developer mode.
4. Go to Configuration -> Menus and add two menus (e.g., 'menu 1' and  'menu 2') under the new sub-menu (e.g., 'Test 1').
5. Notice that the two menus ('menu 1' and 'menu 2') are not visible on the website.

Description:
As per functional specifications, creation of multi-level sub-menus should not be allowed.

Key Changes:
raises a `UserError` if a menu exceeds the two-level hierarchy by checking the parent and grandparent levels.
- Implements mega menu restrictions:
    - A mega menu cannot have a parent menu.
    - A mega menu cannot have child menus.
    - Any menu cannot be a child of a mega menu.
- Prevents menus with child menus from being added as submenus to existing menus.

This ensures that the website menu structure adheres to the defined functional specifications, providing a consistent and predictable user experience.

task-3901371

Forward-Port-Of: odoo/odoo#222254
Forward-Port-Of: odoo/odoo#168801

- Create a user and its related employee without any expense access rights but with  accounting admin rights.
- With that user create a new expense.
- On the employee field select a different employee and save. 
- The following error appears:

Validation Error

The operation cannot be completed: Missing required value for the field 'Description' (name).
Model: 'Expense' (hr.expense)
- create/update: a mandatory field is not set
- delete: another model requires the record being deleted, you can archive it instead

Since b1ac6f52d37cd59fdb973ce87f93d1d0a69dd204, the field employee_id is no longer invisible for users without hr_expense rights. However, in the method _search_filter_for_expense, users without hr_expense rights but with account rights are able to select every employee (commit 87cca4a9ee64c890ccbd24e2d6766f9f8799a0c0).

But in hr_expense, the method _compute_is_editable only considered hr_expense rights, which meant that users trying to create a new expense with only accounting rights would get an error if they were not the approver of the employee they tried to create the expense for.

After this commit: If the user has no hr_expense rights but has account rights, they will only be able to create expenses for themselves. 

opw-4780218


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

Forward-Port-Of: odoo/odoo#215452

Currently below error occurs while archive/unarchive company:
- Company list is not being updated.
- In `hr_timesheet` KeyError will be encountered on unarchiving a company.
- In `l10n_it_pos` module an AccessError will be encountered on unarchiving a company.

**Root Cause:**
Since https://github.com/odoo/odoo/commit/22e9d822e8cab08114c006eb8c4054c4de0c40f2, the `session_info` method relies on `user_companies` at [1], which fetches only
active company IDs via `_get_company_ids()`. However, `_get_company_ids` uses caching as
shown at [2]. When a company is archived or unarchived, 'write' method is called. Now, here
the cache is invalidated before writing to the company as shown at [3]. Due to which
'_get_company_ids' method doesn't receive the updated list of companies, causing this issue.

**Solution:**
This commit prevents error by ensuring companies are stored before invalidating
the cache.

[1]- https://github.com/odoo/odoo/blob/d3482e32f7dbe273125de84f1bbc434ac3c9ffc3/addons/web/models/ir_http.py#L146

[2]-
https://github.com/odoo/odoo/blob/7db62d6d65bd57f6ed43ce52a820cf03df19efdd/odoo/addons/base/models/res_users.py#L927-L931

[3]-
https://github.com/odoo/odoo/blob/3173a5f993a3ffa3d3a14d29713142e5b6b314d9/odoo/addons/base/models/res_company.py#L343-L367

Sentry-6251348500

Forward-Port-Of: odoo/odoo#219044

Currently a below occurs or content is not receiving to odoo WhatsApp when the user uploads a large file (tried with > 35 MB).

Stack Trace:
```
MemoryError: null
  File "odoo/http.py", line 2383, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1913, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1976, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1943, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2187, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/controller/main.py", line 42, in webhookpost
    wa_account_id._process_messages(value)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/models/whatsapp_account.py", line 206, in _process_messages
    datas = wa_api._get_whatsapp_document(messages[message_type]['id'])
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/tools/whatsapp_api.py", line 236, in _get_whatsapp_document
    file_response = self.__api_requests("GET", file_url, auth_type="bearer", endpoint_include=True)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/tools/whatsapp_api.py", line 46, in __api_requests
    if 'error' in res.json():
  File "requests/models.py", line 971, in json
    return complexjson.loads(self.text, **kwargs)
  File "requests/models.py", line 928, in text
    encoding = self.apparent_encoding
  File "requests/models.py", line 793, in apparent_encoding
    return chardet.detect(self.content)["encoding"]
  File "__init__.py", line 49, in detect
    detector.feed(byte_str)
  File "chardet/universaldetector.py", line 274, in feed
    if prober.feed(byte_str) == ProbingState.FOUND_IT:
  File "chardet/charsetgroupprober.py", line 70, in feed
    state = prober.feed(byte_str)
  File "chardet/hebrewprober.py", line 240, in feed
    byte_str = self.filter_high_byte_only(byte_str)
  File "chardet/charsetprober.py", line 73, in filter_high_byte_only
    buf = re.sub(b"([\x00-\x7F])+", b" ", buf)
  File "__init__.py", line 186, in sub
    return _compile(pattern, flags).sub(repl, string, count)
```

At line [1], the code `'error' in res.json()` is used, which reads all the json content of `res`, but at times users upload large files, it will cause the above error because the `json()` tries to read all bytes from res, which is a very large amount to handle in memory.

This commit will fix the above issue by returning a response if the response
contains content_length more than 10 MB.

[1] - https://github.com/odoo/enterprise/blob/aca7ae2a7cf4aad5427a60d5cad60d08774357d0/whatsapp/tools/whatsapp_api.py#L46

sentry-5810101850

Forward-Port-Of: odoo/enterprise#70001

**Before this commit:**
When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the transaction move is posted and the invoice payment status is updated to "In Payment." This results in the email incorrectly asking the customer to remit payment, even though the payment is already being processed.

**Steps to Reproduce:**
1. Enable "Automatic Invoicing" from Sales settings.
2. Enable and publish any payment provider (e.g., Demo) in test mode.
3. Create an invoice and generate a payment link. Open the link in a new incognito tab and pay using any dummy card number (ensure the "Save my payment details" checkbox is checked). This saves the payment token for the partner.
4. Create a new invoice with the same partner, then register payment. Select the payment method and the previously saved token, then confirm.
5. Observe that the payment status is "In Payment," but the email sent to the customer incorrectly asks them to remit payment.

**Fix:**
This change prevents payment notification emails from being sent automatically when the payment is manually created from the payment register wizard.

opw-4850293

Forward-Port-Of: odoo/enterprise#91761
Forward-Port-Of: odoo/enterprise#91570

Fix the following issue that could be triggered quite randomly.
To reproduce it, the easiest way is to set a timeout  between
the 2 await functions in the function runCurrentReturnChecks()
and switching quickly from the audit kanban view to a return view
a few times.

The issue occurs because the refresh_check function might take
a few seconds to compute, and if the user leaves the view before
it finishes, the second await function was triggered on a
destroyed component.

UncaughtPromiseError
Uncaught Promise > Component is destroyed
Error: Component is destroyed
    at Object.original (http://localhost:8069/web/assets/debug/web.assets_web.js:47514:31) (/web/static/src/core/utils/hooks.js:109)
    at Object.fn (http://localhost:8069/web/assets/debug/web.assets_web.js:47507:21) (/web/static/src/core/utils/hooks.js:102)
    at ORM.call (http://localhost:8069/web/assets/debug/web.assets_web.js:47524:52) (/web/static/src/core/utils/hooks.js:119)
    at ORM.webRead (http://localhost:8069/web/assets/debug/web.assets_web.js:33931:21) (/web/static/src/core/orm_service.js:307)
    at props.list.model.load (http://localhost:8069/web/assets/debug/web.assets_web.js:227868:55) (/account_reports/static/src/components/account_return/views/account_return_check_kanban_renderer.js:87)
    at async props.list.model.load (http://localhost:8069/web/assets/debug/web.assets_web.js:227866:36) (/account_reports/static/src/components/account_return/views/account_return_check_kanban_renderer.js:85)
    at async Object.onClose (http://localhost:8069/web/assets/debug/web.assets_web.js:102138:29) (/web/static/src/views/view_button/view_button_hook.js:95)
    at async Object.doActionButton (http://localhost:8069/web/assets/debug/web.assets_web.js:106405:9) (/web/static/src/webclient/actions/action_service.js:1579)
    at async execute (http://localhost:8069/web/assets/debug/web.assets_web.js:102144:21) (/web/static/src/views/view_button/view_button_hook.js:101)
    at async executeButtonCallback (http://localhost:8069/web/assets/debug/web.assets_web.js:102072:15) (/web/static/src/views/view_button/view_button_hook.js:29)

task-4991558

This commit fixes two issues related to project propagation from Sale Order to Purchase Order:

**1. Project not propagated when using MTO+Buy route**

**Steps to reproduce:**
- Install only `sale_project_stock` and `purchase`
- Enable multi-step routes and unarchive the "MTO" route
- Create a storable product "P1" with:
  - Routes: MTO + Buy
  - Vendor: any
- Create a Sale Order with:
  - 1 unit of P1
  - Any project set in "Other Info"
- Confirm the SO

**Issue:**
A Purchase Order is created but the project is not propagated to it. This propagation was previously ensured by `project_mrp_sale`, via:

https://github.com/odoo/odoo/blob/238a41e35280256382f6509182b9e900fb4f7aba/addons/project_mrp_sale/models/stock_move.py#L9

---

**2. Project not propagated when using drop-shipping**

**Steps to reproduce:**
- Enable drop-shipping
- Create a product "P2" with:
  - Route: Drop-Ship
- Create a Sale Order with:
  - 1 unit of P2
  - Any project set
- Confirm the SO

**Issue:**
A Purchase Order is created, but the project is again missing.

---

**Fix:**
- Move the `_prepare_procurement_values` override from `project_mrp_sale` to `sale_project_stock` to ensure project propagation regardless of the presence of `project_mrp_sale`
- Also adapt `sale_project` to ensure project is retrieved from the Sale Order if not set on the Sale Order Line.

opw-4976606

### Steps to reproduce:

- In the settings enable Multi-Steps routes
- Put your warehouse in delivery in 2 steps
- Create and confirm a sale order for 1 units of a storable product
#### > While the pick move was created and confirmed the forecast is still at 0 even tho it should be at -1 and the outgoing pick move should be matched with the SO line in the forecast report.

### Cause of the issue:

The issue has been introduced by commit 5b40fb086a0e5677678c312b42dc1f2c8991dc9e The issue being that since the `location_final_id` should not have been considered for the past forecast based on done move chains (because each done move of the chain will refer to the same external `final_dest_id`). The proposed fix was therefore to change the dest_loc_domain as such:
https://github.com/odoo/odoo/commit/5b40fb086a0e5677678c312b42dc1f2c8991dc9e#diff-1f24ce9f94c5795040749acca5924384d7d17c0ac39b1993cef3b484e4bd30afR324-R326 
However, the new domain:
https://github.com/odoo/odoo/blob/995a7072cb3315fc03544b281b1ed5ca4e81e901/addons/stock/models/product.py#L322-L326 ignores completely the part of the condition refering to `final_dest_id` for outgoing moves since the condition is negated here: https://github.com/odoo/odoo/blob/995a7072cb3315fc03544b281b1ed5ca4e81e901/addons/stock/models/product.py#L328-L333 The logical `OR` (`|`) becoming an `AND` (`&`) for the `domain_move_out_loc`.

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

**Steps to reproduce**:
- install the `accounting` module.
- Go to `Settings -> Technical -> Actions -> Reports -> Invoice or Invoice without payment`
- Change the printed report name
- Try to print the report via the print menu (gear icon -> print) -> The report is shown with the new updated name.
- Try sending the invoice the regular way -> the attached invoice has the default name, Odoo ignores the changes.

**Observation**:
When printing the invoice manually, the file name correctly reflects the custom name configured in the report action. However, when sending the invoice by email, the attachment file name does not match the updated name and remains hardcoded.

**Issue**:
The email attachment file name is hardcoded in the mail sending logic. in the method:
```python
def _get_invoice_report_filename(self, extension='pdf'):
        self.ensure_one()
        return f'{self.name.replace('/', '_')}.{extension}'
```
It does not dynamically fetch the updated report name from the configured report action.

**Solution**:
When a custom report template is configured on the customer on field `(invoice_template_pdf_report_id)`, the system now dynamically uses the corresponding name from the report action for the email attachment.

opw-4923035

### Steps to reproduce:

- Go to the To-Do app and type something in the editor.
- Select the typed text.
- Click on the Font Size Input and choose a value from the dropdown (e.g.,80).
- Try typing again in the editable area.
- Selection is still visible, the focus is no longer in the editable area.

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

- `focusEditable()` skipped restoring focus if the selection was inside the editor, even when the editor itself wasn’t focused.
- When the font size input (inside an iframe) is focused, editable loses focus.
- Selecting a value from the dropdown blurs the iframe input, but focus is not returned to the editable area.
- As a result, the selection is still visible but the user cannot type.

### Desired behavior after PR is merged:

- Does nothing if the editor or its descendants have focus.
- Focuses the editor if needed.
- Restores selection only when it's outside the editor.
- When the iframe input is blurred, focus is returned to the editable area.

task-4932364

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

**Steps to reproduce**:
1. Install the `account` module.
2. Create a Invoice using this any product.
3. add long descripition (approx. 40-45 lines).
4. Print the PDF of Invoice (via gear icon).

**Observation**:
The long product description overlaps with the table header when the table spans multiple pages in the generated PDF.

**Issue**:
wkhtmltopdf does not handle multi-page table headers properly by default. causing header/content overlap when the table breaks across pages.

**Solution**:
Apply a known wkhtmltopdf workaround by explicitly setting:
  `<thead style='display: table-row-group;'>`
This ensures headers will not repeat same as this. [#53909](https://github.com/odoo/odoo/pull/53909)

before:
<img width="818" height="231" alt="image" src="https://github.com/user-attachments/assets/8bcc6ced-5911-4abd-b91e-97ffa8fb735e" />

after:
<img width="821" height="253" alt="image" src="https://github.com/user-attachments/assets/2ccc6995-c239-4beb-8f68-53d548b7f2f2" />

opw-4982735

Forward-Port-Of: odoo/odoo#221681

### Steps to reproduce:

- Type some text and apply a large font-size.
- Select the text and apply the button style.
- Notice that the font-size is not reflected on the button.

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

- The `<a class=btn>` element was placed inside a font-size `<span>`.
- However, the `.btn` class defined its own font-size, causing the original styling to be overridden.

### Desired behavior after PR is merged:

- Improved the splitAroundUntil utility to correctly handle cases where the target node has no previous or next sibling. In such edge cases, the function now recursively splits up the inline ancestry until the specified limitAncestor, ensuring that the target node is fully isolated.
- The font-size `<span>` is moved inside `<a>` tag when applying a button style.
- This ensures the original font-size is preserved and correctly displayed.

task-4731416

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

If you made an order and tried to pay with a payment terminal (like Adyen) then canceled the payment on the terminal. Then leave the order and create a new order, add different products, and try to pay again, pay on the terminal, the payment will not be transmitted to the PoS and the order would still be waiting for payment.

Steps to reproduce:
------------------
* Create a pos payment method using adyen
* Open a PoS session
* Create an order with a product
* Pay with the adyen payment method
* Cancel the payment on the terminal
* Leave the order
* Create a new order with different products
* Try to pay with the adyen payment method
* Validate the payment on the terminal
> Observation: The payment will not be transmitted to the PoS and the
  order will still be waiting for payment.

Why the fix:
----------------
The issue occurs because the canceled payment line is still considered as a pending payment line. And when the payment will be receiven on the pos it would take the canceled payment line as the pending one.

opw-4805704

**Issue**
When creating a down payment invoice for a quotation that includes a reseller, an error is raised and the operation is aborted.

**Steps to Reproduce**
1. Install Accounting, Studio, and l10n_in_sale
2. Open the Quotation view in Studio
3. Set the "Referrer" field (i.e., l10n_in_reseller_partner_id) to be always visible and remove group restrictions
4. Create a new quotation and set a reseller in the Referrer field
5. Confirm the quotation
6. Click "Create Invoice"
7. Choose "Down Payment (percentage)" with 10%
8. Click "Create Draft"

**Root Cause**
The `_prepare_invoice_values()` method was assigning the full `res.partner` record to the `l10n_in_reseller_partner_id` field instead of its ID. Since the `account.move` model expects an integer ID for many2one fields, this caused a `psycopg2.ProgrammingError` due to the database adapter not being able to serialize a recordset.

**Fix**
Ensure the value passed to l10n_in_reseller_partner_id is the .id of the partner record, not the recordset itself.

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

**Description of the issue/feature this PR addresses**:
It is needed to ensure that the descriptions for the IIBB perceptions are consistent and correctly reflect the complete name of the jurisdictions they apply to.

**Steps to reproduce**:
1) Go to runbot odoo 18 instance, install l10n_ar module, take position on Argentinean company and activate "Spanish (Latin America)" language.
2) Go to "Accounting / Configuration / Accounting / Taxes", filter by "Sales" Tax Type (type_tax_use) and see that Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe don`t have the complete description. It is needed to show the complete description.

<img width="1825" height="307" alt="image" src="https://github.com/user-attachments/assets/f664e5ec-a4b5-4a8f-bbab-9ba3d824bd2b" />

**Current behavior before PR**:
Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe taxes don`t have the complete description.

**Desired behavior after PR is merged**:
Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe taxes have the complete description.
<img width="1828" height="425" alt="image" src="https://github.com/user-attachments/assets/dc8ee6dd-23c3-40c1-a973-943971e3cb78" />

**Task Adhoc side**: 53028
**Task latam side**: 1356

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

Steps to Reproduce:
1. Go to the website.
2. Create a new menu (e.g., 'Test 1') using the 'Edit Menu' option and add it under another menu (e.g., 'Contact Us'), creating a sub-menu. 
3. Turn on the developer mode.
4. Go to Configuration -> Menus and add two menus (e.g., 'menu 1' and  'menu 2') under the new sub-menu (e.g., 'Test 1').
5. Notice that the two menus ('menu 1' and 'menu 2') are not visible on the website.

Description:
As per functional specifications, creation of multi-level sub-menus should not be allowed.

Key Changes:
raises a `UserError` if a menu exceeds the two-level hierarchy by checking the parent and grandparent levels.
- Implements mega menu restrictions:
    - A mega menu cannot have a parent menu.
    - A mega menu cannot have child menus.
    - Any menu cannot be a child of a mega menu.
- Prevents menus with child menus from being added as submenus to existing menus.

This ensures that the website menu structure adheres to the defined functional specifications, providing a consistent and predictable user experience.

task-3901371

Forward-Port-Of: odoo/odoo#168801

Currently a below occurs or content is not receiving to odoo WhatsApp when the user uploads a large file (tried with > 35 MB).

Stack Trace:
```
MemoryError: null
  File "odoo/http.py", line 2383, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1913, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1976, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1943, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2187, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/controller/main.py", line 42, in webhookpost
    wa_account_id._process_messages(value)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/models/whatsapp_account.py", line 206, in _process_messages
    datas = wa_api._get_whatsapp_document(messages[message_type]['id'])
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/tools/whatsapp_api.py", line 236, in _get_whatsapp_document
    file_response = self.__api_requests("GET", file_url, auth_type="bearer", endpoint_include=True)
  File "home/odoo/src/enterprise/saas-17.4/whatsapp/tools/whatsapp_api.py", line 46, in __api_requests
    if 'error' in res.json():
  File "requests/models.py", line 971, in json
    return complexjson.loads(self.text, **kwargs)
  File "requests/models.py", line 928, in text
    encoding = self.apparent_encoding
  File "requests/models.py", line 793, in apparent_encoding
    return chardet.detect(self.content)["encoding"]
  File "__init__.py", line 49, in detect
    detector.feed(byte_str)
  File "chardet/universaldetector.py", line 274, in feed
    if prober.feed(byte_str) == ProbingState.FOUND_IT:
  File "chardet/charsetgroupprober.py", line 70, in feed
    state = prober.feed(byte_str)
  File "chardet/hebrewprober.py", line 240, in feed
    byte_str = self.filter_high_byte_only(byte_str)
  File "chardet/charsetprober.py", line 73, in filter_high_byte_only
    buf = re.sub(b"([\x00-\x7F])+", b" ", buf)
  File "__init__.py", line 186, in sub
    return _compile(pattern, flags).sub(repl, string, count)
```

At line [1], the code `'error' in res.json()` is used, which reads all the json content of `res`, but at times users upload large files, it will cause the above error because the `json()` tries to read all bytes from res, which is a very large amount to handle in memory.

This commit will fix the above issue by returning a response if the response
contains content_length more than 10 MB.

[1] - https://github.com/odoo/enterprise/blob/aca7ae2a7cf4aad5427a60d5cad60d08774357d0/whatsapp/tools/whatsapp_api.py#L46

sentry-5810101850

Forward-Port-Of: odoo/enterprise#70001

A non-deterministic error has been occurring across all versions starting from 18.0 when running the
`test_split_line_on_destination_scan`.

problem:
The issue lies in one of the steps of the tour, where the destination location of the remaining quantity is changed from WH/Stock to shelf1 (LOC-01-01-00). Right after this change, the test proceeds to assertLineDestinationLocation. However, the test step was previously waiting for the presence of the .o_validate_page.btn-primary element — an element that is already visible before the destination location update is actually applied. As a result, the tour sometimes skips to the next step prematurely, without ensuring the location change has occurred, leading to test failure.

Fix:
We replaced the trigger .o_validate_page.btn-primary with a more reliable condition: waiting for an element containing the destination text .../Section 1 (.o_line_destination_location:contains(".../Section 1")). This ensures that the step only proceeds once the destination update has been reflected in the UI.

Runbot-145458