Currently, an error occurs when submitting the 'Send Email' form.

Steps to Reproduce:

 - Install the `website` and `web_studio` modules.
 - Go to `website` > `Click on Edit` > `Drag and drop form`.
 - click the form and in actions select the `more models`, and select
   `outgoing mails(mail.mail)` model and `save`.
 - `Submit` the form, and the error appears in the `logs`.

**Error:**
`KeyError: 'website_form_signature'`

**Cause:**
This error occurs when submitting the "Send Email" form from the
 website. By default, the form action is `"Send an E-mail"`, and when 
the user `changes` the form’s model to outgoing mails (mail.mail), 
which also has the action "Send an E-mail," the system checks the 
existing model [1] and retrieves it. Since `shouldRerender` is set to 
false, [2] is not executed, and as a result, the `email_to(hidden field)` 
is not present in the form. And the website_form_signature is added 
from [3], but due to the condition at [4], the code at [3] is not executed. 
When it is accessed at [5], KeyError is raised.

**Fix:**
This commit ensures that when the user changes the model, 
`rerenderXml` is executed so that the `hidden field` is also added.

[1]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L155-L156

[2]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L174-L178

[3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252

[4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236

[5]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88

sentry-6746753251

Forward-Port-Of: odoo/enterprise#93287

Version:
- 18.0

Steps to reproduce:
- Open document which is send for signature.
- Refresh the browser.

Before:
- Refreshing the page was hiding the `sign now` and `cancel` button from control panel and also the name of document get replaced by 'unnamed' in breadcrumbs
- The `needToSign` value was loaded from the context and used later to show those button, which is only available when navigating from `go_to_document`. On refresh, the context was lost, leading to the error.
- Breadcrumbs were not getting set properly on reload.

After:
- Added `needToSign` to the URL query string.On page refresh, the data is retrieved from the URL as a fallback instead of relying on the context.
- Add name of document to URL query string and on page refresh use that name to get correct name of document and update name to breadcrumbs using `setDisplayName`.

Impact:
- Buttons remain visible after refresh.
- Correct document name is shown in breadcrumbs.
- Ensures a smoother and more stable user experience when viewing documents.

task-4805166

Forward-Port-Of: odoo/enterprise#97837
Forward-Port-Of: odoo/enterprise#93589

Currently, an error occurs when submitting the 'Send Email' form.

**Steps to Reproduce:**

 - Install the `website` module.
 - Go to `website` > `Click on Edit` > `Drag and drop form.`
 - Click the form and in actions select again `Send an E-mail` action 
   and `save`.
 - `Submit the form`, and the error appears in the logs.

**Error**:
KeyError: 'website_form_signature'

**Cause:**
This error occurs when submitting the "Send Email" form from the
website. When the user chooses the model Outgoing Mails (mail.mail),
the email_to hidden field is not added. This is because email_to is only
added when the recipient email value is changed from the sidebar via
apply [1]. As a result, the email_to hidden field is missing from the form.
And the website_form_signature is added from [2], but due to the
condition at [3], the code at [2] is not executed. When it is accessed
at [4], KeyError is raised.

**FIX:**
This commit ensures that when the user selects the action model,
if there are hidden field , it is added to the form with its
default value.

[1]: https://github.com/odoo/odoo/blob/3b16debc6d6557334082fdf841b20ef0e31fc9d2/addons/website/static/src/builder/plugins/form/form_option_plugin.js#L863

[2]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252

[3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236

[4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88

sentry-6746753251

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

Forward-Port-Of: odoo/odoo#226598

**Steps to reproduce:**

1. Install the modules: `accounting`, `l10n_ar`, and `l10n_latam_check`.
2. Create a third-party check journal:
   * Add payment methods: *New Third Party Checks* (inbound) and *Existing Third Party Checks* (outbound).
   * Configure outstanding accounts for both methods.
3. Create a vendor payment:
   * Use the third-party check journal.
   * Select the *Existing Third Party Checks* method.
   * Leave the check list empty.
   * Keep the payment in *Draft*.
4. Create a customer payment:
   * Use the same journal and select the *New Third Party Checks* method.
   * Add a new check under the *Checks* tab.
   * Post the payment.
5. Return to the draft vendor payment created in step 3:
   * Add the newly created check to it (via *Add a line*).
   * Post the payment.
6. Go to **Customers → Third Party Checks**.

**Observed behavior:**
- The check still shows a `current_journal_id` even though it has both inbound and outbound operations.
- As a result, the check incorrectly appears in the 'On Hand' filter.

**Root cause:**
- `_get_last_operation` was sorting operations by `date`.          
- In some scenarios or flows where multiple operations share the same `date`, the wrong operation could be selected as the "last one", leading `_compute_current_journal` to assign a journal incorrectly.

**Solution:**
- Sort operations by `write_date` to always pick the true last operation.
- This ensures `_compute_current_journal` correctly clears `current_journal_id` whenever both inbound and outbound operations exist.


opw-5012903

Forward-Port-Of: odoo/odoo#225556

If you have a company with a lock date set, and you connect a bank that has transactions dated to the day of the lock date, these transactions will be fetched, which do not make sense because nothing should be created in a period covered by a lock date.

As a result, these transactions would be created at a wrong date (if the current month is the first after the lock date or if the sequence has a monthly reset, then they would be appended to the current month, else if the sequence reset annually, then they would be created at the current date).

Additionally, the potential opening balance would be created at a wrong date too, since it would try to create it one day prior to the oldest transaction.

The date which the opening balance is created would not be the same as the transactions above, which adds a layer to the mess created.

To prevent this, at initialization, we set the last sync date one day after the lock date, not the same day.

As for the opening balance, we do not try to set it one day prior to the oldest transaction, but the same day. The `internal_index` computed will ensure it is displayed as the first transaction of that journal.

Finally, the test related to statement creation were adapted to this new behavior. Some ordering based on `date` in other tests were changed to `internal_index` to unify the test file with these changes.

opw-4890538

Forward-Port-Of: odoo/enterprise#95138
Forward-Port-Of: odoo/enterprise#93543

…ml internal dropship return

**Problem:**
when the subcontracting setting is active, the return of a dropshipped product (not necessarily subcontracted) to the internal subcontracting location will create an account move that credits "stock valuation" instead of debitting it

**Steps to reproduce:**
- enable the "Anglo-Saxon Accounting","Multi-steps routes" and "Subcontracting" settings
- create a storable product with dropshipping route and a vendor
- in 'general information' write a non null cost
- make sure the product category's inventory valuation' is 'automated'
- create a new quotation for this product, confirm it and confirm the linked purchase order
- click on the dropship smart button and validate the picking
- click on return and select 'Physical Locations/Subcontracting Location' as the return location
- validate and click on the valuation smart button
- on the only stock valuation layer for this move, click on the book shaped widget

**Current behavior:**
the account move credits Stock Valuation and debits stock interim (received)

**Expected behavior:**
As we are returning the product to stock it should increase the value of the stock valuation account.
Therefore, it should debit stock valuation and credit stock interim (received)

**Cause of the issue:**
If the mrp_subcontracting_dropshipping module is active, and if we call _is_dropshipped_return on a stock move which is the return (to the subcontracting location) of a dropshipped move : the method will return true. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/mrp_subcontracting_dropshipping/models/stock_move.py#L29-L35 Therefore, inside _account_entry_move, _is_in will be false (contrary to if mrp_subcontracting_dropshipping is not installed or if the destination is another internal location)
https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L580 The aml vals will be computed inside _prepare_anglosaxon_account_move_vals https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L596 Here the fact the destination location is internal does not change the fact that it should debit the stock valuation account (meaning it should used acc_valuation as the second parameter of _prepare_account_move_vals) if the cost is positive. https://github.com/odoo/odoo/blob/b34cebcf0c142d92affdb642525f066d431b7ca3/addons/stock_account/models/stock_move.py#L610-L614

opw-4894755

Forward-Port-Of: odoo/odoo#224871
Forward-Port-Of: odoo/odoo#221009

**Steps to reproduce:**
1. Install the CRM module.
2. Go to CRM → Sales → Teams(Team should more than one).
3. Open any Sales Team and create a new Stage.
4. Go to Settings of the created Stage → Edit.
5. Set the 'Sales Teams' same as the selected Team and save.
6. The newly created stage disappears from the list.

**Issue:**
- When editing a stage and assigning a 'Sales Teams', the stage no longer appears in 
the kanban or list view.

**Cause:**
Issue Occur from this [commit](https://github.com/odoo/odoo/commit/7345cbbff6ecb1dcbc508c320e807849167a4f1a)

- The `_read_group_stage_ids` method  overwrite the `search_domain` in the final `else` block, 
even when a valid `team_id` was present in the context. As a result, the search domain ignored 
the selected team and only fetched global stages (with no team assigned).

**Solution:**

Refactored `_read_group_stage_ids` to correctly handle conditional domain
 building:
- Respect `team_id` when present in the context.
- Include user team stages when `show_user_team_stages` is enabled.
- Avoid overwriting `search_domain` when a specific team context is active.

**opw - 5147315**

Prerequisites:
---------------
* Install the stock and accounting
* Configure Product Category:
   * Go to Inventory >Configuration > Categories
   * Create a new category (e.g.,Test)
   * Set Inventory Valuation to "Perpetual (at invoicing)"
* Create a new storable product and assign it to the new category
* Go to Inventory > Configuration > Warehouse Management > Locations
* Remove the `internal location` filter and select `Inventory adjustment`
* On `Inventory Variation`, select Stock Valuation
 
To reproduce:
--------------
1. Go to Inventory >Operations > Physical Inventory
2. Select Accounting date from the optional view button
3. Create a record with a past accounting date
4. Check the related journal entry date

Issue:
------
The journal entry is created with today’s date instead of the specified accounting date.

Cause of the issue:
--------------------
After this 08b62a4, `accounting_date` is not considered when creating the journal entry, causing this issue.
https://github.com/odoo/odoo/blob/db9053adcfb36d9d522079c4b3fd03ae2c7a6504/addons/stock_account/models/stock_move.py#L148-L151

Solution:
---------
Use `accounting_date` if available when creating the journal entry.

opw-5091817

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

The TableSizeComputer.compute() method can return cells with incorrect cell indexes. This can result in the _addColumn function only adding a column to some rows in the report editor.

TableSizeComputer.compute() does not handle cases where a conditional is used inside of a th element but the corresponding td element does not have a conditional.

Steps to reproduce
-----
1. Open the Delivery Slip in the report editor.
2. Click the header to show the dropdown and select elif: o.move_line_ids and o.state=='done'.
3. Hover over the last th element to select the column button.
4. Click Insert right and see that only the header row has an additional column.

Cause
-----
TableSizeComputer.compute() calculates how many possible cells can be in a row which can be more than the total number of columns you have if you have th or td elements with a conditional inside of them.

In the Delivery Slip report, a th element is present when using serial numbers and a different th element is present when not using serial numbers. The corresponding t-body has two different tr elements for these conditions. The compute method will have one less cell in these rows because the corresponding conditional is handled outside of the row.

Solution
-----
Only count mutually exclusive th or td elements once. This prevents the cellIndex from being larger than the total possible columns.

opw-ticket 5173345

Forward-Port-Of: odoo/enterprise#98207

## Short functional explanation of the error
When setting the 'DHLxw Package Type' of a DHL delivery method to 'DHL pallets' without changing default values, trying to validate an order delivery causes an error.

## Reproduction Steps
1. Type 'Delivery method' in the dashboard. Select DHL BE, set the region to Europe and the 'DHLxw Package Type' to 'DHL pallets'. Click on the arrow at the right of 'DHL pallets'. You should see the default values set to 1200, 1600 and 1200. These correspond to millimeters, while DHL expects centimeters.
2. Make sure you're using a company located in Belgium.
3. In the inventory settings, make sure that either 'multi-step route' is unchecked or that for your warehouse, the outgoing shipments are set to '1 step'.
3. Create a new quotation. Select a Customer with a Belgian address. Add a product for which there's at least 1 copy in stock.
4. Click on add shipping and select DHL BE. Then click add and ok.
5. Click on confirm. A smart button at the top of the page called "delivery" should appear. Click on it and set the scheduled date to a future day. Finally, click validate.

### Expected behavior
New labels should generate without issue.

### Unexpected behavior
An error occurs:
```Bad request Multiple problems found, see Additional Details
1001: The requested product(s) (N) not available based on your
search criteria.(687662d08999745d3df3783068fcca24)
410107: The piece height exceeds max, N/-
410304: No products available
```

## Origin of the issue
The default values for DHL are set to 1200, 1600 and 1200, which correspond to millimeters. However, DHL expects centimeters, for which the default value is thus too high.
Note: because the issue stems from default values, after implementing the fix, the module should be reinstalled.

__
opw-4804639

Forward-Port-Of: odoo/enterprise#90272

*mass_mailing

This commit fixes some issues in the RPC cache, when the fallback (i.e. the call to the server) failed. More specifically, if the same rpc was done multiple times before the first one returned, the returned promise might be pending forever:

1) if type="disk": only the promise of the first call was rejected,
    the promise of the other calls was left pending forever.
2) if type="ram": all calls got the same promise as response, which
    was left pending forever.

This commit fixes those issue and introduces new tests for the failing fallback scenario.

These issues have been highlighted when working on the offline UI, as in offline, rpcs always fail.

We also had to properly mock the route `/html_editor/get_image_info` in a mass_mailing test, as the call threw an "unimplemented route error" which was previously hidden by the issue 2) that this commit fixes.

task~5106517

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

_______________________________________
## Short functional explanation of the error
Let's say we have the scenario where a user has access to company_1 and company_2, but only has a corresponding employee in company_2. If the user selects company_1 and company_2 but keeps company_1 as his current company, and tries to assign himself a task that has been created for company_2, nothing happens.

## Reproduction Steps
1. As an admin, create a user with which you'll be able to log. Make sure that you have at least 2 companies created, and that the user has access to both. Create an employee for that user in company_2.
2. Select both companies. In planning, create a slot for company_2 and publish it.
3. Log in as the user you created. Make sure that the current company is company_1. Select company_2.
4. Go to planning and try to assign yourself to the slot you've just created as an admin

### Expected behavior
Either an error message shows, or the employee is assigned to the slot for company_2 (as company_2 is selected).

### Unexpected behavior
Nothing happens

## Origin of the issue
When the current company isn't the one corresponding to the one the employee is in, even if another company is selected and contains the employee,
self.env.user.employee_id is set at False

_________________________________________
opw-4963674

---

Forward-Port-Of: odoo/enterprise#95785
Forward-Port-Of: odoo/enterprise#91616

## Issue:
On Safari, the Apply and Dismiss buttons of the LinkPopover did not trigger their actions In some cases, it seemed to work only because a temporary link was not properly cleared
The Link Type Selection was also broken by the same bug

## Cause:
Safari triggers a `pointerdown` event through the `LinkPopover`, which changes the `selection` and calls the `handleSelectionChange()` method https://github.com/odoo/odoo/blob/e43135e94bf22bc2f7a115c37e8a082f96871ed0/addons/html_editor/static/src/main/link/link_plugin.js#L672-L678
At that point, `documentSelection` is `null`, causing the overlay to close before the `onClickApply()` on the Apply button
It's the same issue with the Dismiss button and the Link Type Selection

## Steps to reproduce:
- Install mail to get access to an html_editor
- Enable debug mode
- Go in Email Templates and open one of them
- Select a text and open link tools
- Add Odoo.com and click on Apply
- The link may seems to be created (if it's the case, there is no preview)
- You can confirm that with the link type selector that closed the popover before the fix

opw-5115887

Forward-Port-Of: odoo/odoo#233513
Forward-Port-Of: odoo/odoo#233241

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

When obtaining the previous order for pos.order records, all orders with l10n_fr_secure_sequence_number == NULL will be recognised as the previous order for those where l10n_fr_secure_sequence_number == 1, as if their sequence value was zero.

## Current behavior before PR:

Since there can be more than one orders without sequence number, this behaviour will trigger an UserError exception, as the ORM will mistakenly deduce that there are multiple previous orders for a single one, which is not necessarily correct.

### Examples:

upg-3170341

```sql
lare_3170341=> SELECT count(id) FROM pos_order WHERE l10n_fr_secure_sequence_number IS NULL;
 count
-------
 67281
(1 row)
```

```python
# Debugging standard codebase with a Python debugger
...
match = prev_map.get(order.l10n_fr_secure_sequence_number - 1, [])    # len(match) == 67281
if len(match) > 1:
    raise UserError(_('An error occurred when computing the inalterability...'))
...
```

upg-3170341

```sql
lare_3167621=> SELECT count(id) FROM pos_order WHERE l10n_fr_secure_sequence_number IS NULL;
 count
-------
   294
(1 row)
```

```python
# Debugging standard codebase with a Python debugger
...
match = prev_map.get(order.l10n_fr_secure_sequence_number - 1, [])    # len(match) == 294
if len(match) > 1:
    raise UserError(_('An error occurred when computing the inalterability...'))
...
```

---

Traceback group: https://upgrade.odoo.com/odoo/tbg/1869

```
2025-09-30 07:48:30,945 329 INFO db_3167621 odoo.modules.loading: Loading module l10n_fr_pos_cert (110/131) 
2025-09-30 07:48:31,375 329 INFO db_3167621 odoo.modules.registry: module l10n_fr_pos_cert: creating or updating database tables 
2025-09-30 07:48:31,432 329 INFO db_3167621 odoo.models: Prepare computation of pos.order.previous_order_id 
2025-09-30 07:48:31,597 329 WARNING db_3167621 odoo.modules.loading: Transient module states were reset 
2025-09-30 07:48:31,597 329 ERROR db_3167621 odoo.modules.registry: Failed to load registry 
2025-09-30 07:48:31,597 329 CRITICAL db_3167621 odoo.service.server: Failed to initialize database `db_3167621`. 
Traceback (most recent call last):
  File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1361, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-13>", line 2, in new
  File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 485, in load_modules
    processed_modules += load_marked_modules(env, graph,
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 365, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 206, in load_module_graph
    registry.init_models(env.cr, model_names, {'module': package.name}, new_install)
  File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 618, in init_models
    func()
  File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/ir_model.py", line 2007, in _reflect_relation
    self.env.invalidate_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 839, in invalidate_all
    self.flush_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 857, in flush_all
    self._recompute_all()
  File "/home/odoo/src/odoo/18.0/odoo/api.py", line 850, in _recompute_all
    self[field.model_name]._recompute_field(field)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7359, in _recompute_field
    field.recompute(records)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1463, in recompute
    apply_except_missing(self.compute_value, recs)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1436, in apply_except_missing
    func(records)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 427, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5296, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
  File "/home/odoo/src/odoo/18.0/addons/l10n_fr_pos_cert/models/pos.py", line 79, in _compute_previous_order
    raise UserError(_('An error occurred when computing the inalterability. Impossible to get the unique previous posted point of sale order.'))
odoo.exceptions.UserError: Une erreur s'est produite lors de la vérification de l'inaltérabilité. Impossible de récupérer la dernière commande de caisse unique et comptabilisée.
```

## Desired behavior after PR is merged:

The method `pos.order._compute_previous_order` already only checks orders with a sequence number != NULL, so to address this issue, we will use the same condition to retrieve only orders with a valid sequence. This will result in no more exceptions created by incorrect data.

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

Forward-Port-Of: odoo/odoo#229585