**Current behavior before PR:**
The rating images have an unintended white background in dark mode.

**Steps to Reproduce:**
- Turn on Dark Mode
- Go to livechat
- Go to Report > Sessions History  

**Desired behavior after PR is merged:**
This PR fixes the issue by applying a transparent background to rating images through the `img_class` option in image widget.

The change is applied to:
- discuss.channel (kanban, list, form views)
- rating.rating (form, kanban views)

---
**Before:**
<img width="372" height="202" alt="image" src="https://github.com/user-attachments/assets/d573ab3e-62be-4ab2-9c7f-e39bf97cb542" />

**After:**
<img width="394" height="141" alt="image" src="https://github.com/user-attachments/assets/6133c231-c634-4afd-a99f-5440ecfe72be" />

task-[4689867](https://www.odoo.com/odoo/project/1519/tasks/4689867)


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

Forward-Port-Of: odoo/odoo#231919
Forward-Port-Of: odoo/odoo#215207

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

Step to reproduce:
- open projects
- go to -> configuration -> settings -> enable  "project stages"
- archive all projects
- go to home page and reopen project app
- open list view

Observation:
- we receive a traceback

Cause:
- when loading sample records for list view, `_mockFormattedReadGroup` is used which do not have record key.
- but for unfolded groups, we need records.
- this happens after this [commit](https://github.com/odoo/odoo/commit/26c37c9c070107f8bd753cb8a6d8343384fdd7bf), previously , load data for each group from here 
https://github.com/odoo/odoo/blob/7843db3c4576c80e48fc42bea86134212add3589/addons/web/static/src/model/relational_model/relational_model.js#L476-L483
- but this part is removed in above mentioned commit as part of revamp, and a corner case lived i.e list view, in which, group is unfolded, never gets any records.

Fix:
- we add records to list view based on if the group is folded or not

opw-5122678

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

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

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

Steps to reproduce:
===================
1- Add a Contact Us form.
2- Change the "Phone" field type to "Attachment" and save. → Traceback occurs.

Cause:
======
After changing the field type, the field still keeps its `fillWith` value. When saving or refreshing, the system tries to prefill it with a phone number. Since the type is now "file", it cannot be prefilled, causing a traceback.

Why it didn't happen before:
============================
In older versions, fields were fetched using `serializeArray()`:
https://github.com/odoo/odoo/blob/ad03751ef0a9e617c2b24a30b1c06aa4e25d48a1/addons/website/static/src/snippets/s_website_form/000.js#L167
That method automatically filtered out unsupported input types: 
https://github.com/odoo/odoo/blob/ad03751ef0a9e617c2b24a30b1c06aa4e25d48a1/addons/web/static/lib/jquery/jquery.js#L9001

Fix:
====
Exclude fields of file-like types from the prefill logic, similar to the behavior of `serializeArray()`.

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

Forward-Port-Of: odoo/odoo#231185

Description of the issue/feature this PR addresses:

This pull request addresses a bug in Odoo's analytic accounting module. Specifically, when updating analytic lines that have empty distributions, the vals_list[0] ends up being empty. This situation causes an error in the write method, which prevents the system from properly updating analytic lines without distributions.

Current behavior before PR:

Before this fix, attempting to update analytic lines with empty distributions triggers an error in the write method. As a result, operations that involve updating such lines fail, potentially interrupting normal accounting workflows.

Desired behavior after PR is merged:

After merging this PR, the system will first check whether an analytic line has a valid distribution before attempting to update it. Lines with empty distributions will be safely skipped, preventing errors and allowing the rest of the analytic updates to proceed smoothly. This ensures more robust handling of analytic lines and avoids runtime exceptions during updates.


Video: https://app.screencastify.com/watch/03zuCLh984kWun2Q71tK
Odoo Task: https://www.odoo.com/es_ES/my/tasks/5181171

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

Forward-Port-Of: odoo/odoo#232176

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

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

Steps to reproduce:
===================
1- Add a Contact Us form.
2- Change the "Phone" field type to "Attachment" and save. → Traceback occurs.

Cause:
======
After changing the field type, the field still keeps its `fillWith` value. When saving or refreshing, the system tries to prefill it with a phone number. Since the type is now "file", it cannot be prefilled, causing a traceback.

Why it didn't happen before:
============================
In older versions, fields were fetched using `serializeArray()`:
https://github.com/odoo/odoo/blob/ad03751ef0a9e617c2b24a30b1c06aa4e25d48a1/addons/website/static/src/snippets/s_website_form/000.js#L167
That method automatically filtered out unsupported input types: 
https://github.com/odoo/odoo/blob/ad03751ef0a9e617c2b24a30b1c06aa4e25d48a1/addons/web/static/lib/jquery/jquery.js#L9001

Fix:
====
Exclude fields of file-like types from the prefill logic, similar to the behavior of `serializeArray()`.

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

Forward-Port-Of: odoo/odoo#231185

## 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#233401
Forward-Port-Of: odoo/odoo#233241

Description of the issue/feature this PR addresses:

This pull request addresses a bug in Odoo's analytic accounting module. Specifically, when updating analytic lines that have empty distributions, the vals_list[0] ends up being empty. This situation causes an error in the write method, which prevents the system from properly updating analytic lines without distributions.

Current behavior before PR:

Before this fix, attempting to update analytic lines with empty distributions triggers an error in the write method. As a result, operations that involve updating such lines fail, potentially interrupting normal accounting workflows.

Desired behavior after PR is merged:

After merging this PR, the system will first check whether an analytic line has a valid distribution before attempting to update it. Lines with empty distributions will be safely skipped, preventing errors and allowing the rest of the analytic updates to proceed smoothly. This ensures more robust handling of analytic lines and avoids runtime exceptions during updates.


Video: https://app.screencastify.com/watch/03zuCLh984kWun2Q71tK
Odoo Task: https://www.odoo.com/es_ES/my/tasks/5181171

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

Forward-Port-Of: odoo/odoo#232176

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

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

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

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

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#98251
Forward-Port-Of: odoo/enterprise#93589

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

This commit adjusts dashboard element colors to enhance readability in dark mode.

task-5122380

Requires:
- https://github.com/odoo/enterprise/pull/95875

| Before | After |
|--------|--------|
| <img width="665" height="336" alt="image" src="https://github.com/user-attachments/assets/c3270f8d-bd3b-47a9-807f-ca4ca5c7e6c2" /> | <img width="632" height="317" alt="Capture d’écran 2025-09-30 à 14 48 22" src="https://github.com/user-attachments/assets/d0eb8ab1-6ff7-484f-aedb-b668ba337a43" /> |
| <img width="1914" height="967" alt="image" src="https://github.com/user-attachments/assets/4d7b9c00-41b7-46a3-addb-4ec09cbbca85" /> | <img width="1916" height="922" alt="Capture d’écran 2025-09-30 à 14 48 59" src="https://github.com/user-attachments/assets/711375aa-5b01-4c81-b7ab-ba462fdbb0b6" /> |
| <img width="1716" height="953" alt="image" src="https://github.com/user-attachments/assets/a023d555-3f92-433d-a07f-dc8bb1c2513c" /> | <img width="1640" height="803" alt="Capture d’écran 2025-09-30 à 14 50 07" src="https://github.com/user-attachments/assets/26ae7b94-222d-4527-87ad-68ed55b495d0" /> |







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

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

Description of the issue/feature this PR addresses:

This pull request addresses a bug in Odoo's analytic accounting module. Specifically, when updating analytic lines that have empty distributions, the vals_list[0] ends up being empty. This situation causes an error in the write method, which prevents the system from properly updating analytic lines without distributions.

Current behavior before PR:

Before this fix, attempting to update analytic lines with empty distributions triggers an error in the write method. As a result, operations that involve updating such lines fail, potentially interrupting normal accounting workflows.

Desired behavior after PR is merged:

After merging this PR, the system will first check whether an analytic line has a valid distribution before attempting to update it. Lines with empty distributions will be safely skipped, preventing errors and allowing the rest of the analytic updates to proceed smoothly. This ensures more robust handling of analytic lines and avoids runtime exceptions during updates.


Video: https://app.screencastify.com/watch/03zuCLh984kWun2Q71tK
Odoo Task: https://www.odoo.com/es_ES/my/tasks/5181171

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

Forward-Port-Of: odoo/odoo#232176

### Issue:

The test `test_mrp_backorder_operations` behaves non-deterministically. It may fail at this assertion:
https://github.com/odoo/odoo/blob/6e37542b53f9c9ec1baf8d58b1eeca376252186f/addons/mrp/tests/test_backorder.py#L986-L989

Because the `duration` of done workorder can vary.

### Cause:

The delta time between `button_start()` and `button_finish()` https://github.com/odoo/odoo/blob/6e37542b53f9c9ec1baf8d58b1eeca376252186f/addons/mrp/tests/test_backorder.py#L983-L985
`button_finish()` triggers `Productivity._close()`
https://github.com/odoo/odoo/blob/6e37542b53f9c9ec1baf8d58b1eeca376252186f/addons/mrp/models/mrp_workcenter.py#L572-L576
Which sets `Productivity.duration` to 0 if delta time is zero. Consequently, `workorder.duration` also becomes zero.
When `bo_2.button_mark_done()` is called, the duration is set to `duration_expected` (240 in this test), which the assertion only can pass in that case.

If delta time isn't zero, then duration will also be non-zero. So it will not set to `duration_expected`. As a result the assertion will fail.

runbot-233247