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

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

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

**Issue**
A work order that is blocked by another work order can still be started.

**Steps to reproduce**
1. Go to Settings > Activate Work Order Dependencies.
2. Create a Bill of Material for a product:
   - In the Miscellaneous tab, activate Work Order Dependency.
   - Create two work orders in different work centers where the second depends on the first.
3. Create a manufacturing order for the same product.
4. In the 'Operations' tab, observe that the start button is active for the blocked work order.
5. Click the Shop Floor smart button and observe that the blocked work order can still be started.

**Cause**
The [`state` of the work order](https://github.com/odoo/odoo/blob/dae9b0a906e86a9e26cd1b37bd9b9385804c8e55/addons/mrp/models/mrp_workorder.py#L65C1-L72C49) was not consistently checked before allowing a work order to start.

**Solution**
Follow the existing behaviour for blocked work centers:
- Hide the start button on the manufacturing order if the work order is blocked.
- Trigger an error message if the start button on the Shop Floor is clicked for a blocked work order.

opw-5167644

Scenario:

- install second language on website
- add mega menu item to menu
- translate full span (from first to last letter)
- save

Result: nothing is saved

Cause:

The mega menu is in a node with [data-oe-model] attribute that receives
the o_editable class from SetupEditorPlugin. Its content is in a
`section > .container` that receives contenteditable="true" from
BuilderContentEditablePlugin.

Because the container zone is contenteditable, the editor allows to
select outside of <span data-oe-translation-…/> elements and when we
replace the whole content, the node is removed because it is an empty
SPAN and we lose the translation reference, so the translation are lost
when saved.

Fix:

There is already a code that disable wrapping editable since
d4f8aebea8cc7eba1517575302e072e0d5e2e406. This was not taking this case
where the content is not in '.o_editable' but in '.o_editable section >
.container'.

With this fix, we only add o_editable class to nodes that matches
[data-oe-model][data-oe-translation-source-sha].

opw-5045798
opw-5159026

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

Forward-Port-Of: odoo/odoo#231650

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