When finishing a repair order a stock valuation entry is created for the
product used. If you then make a quotation and invoice it another
stock valuation entry would be created for the same product.

Steps to reproduce:
-------------------
* Create a category using FIFO and real time valuation
* Create a product using this category and set it's cost to 5€
* Set some on hand quantity for the product
* Create a repair order and add the product with the "Add" option
* Finish the repair order
> Observation: At this point you should have a valuation entry in the
  accouting app
* From the repair order create a quotation and invoice it
> Obesrvation: If you check the accounting entries again you will see
  a second valuation entry

Why the fix:
------------
When checking if the line is eligible for valuation we make sure that if
it is linked to a repair order, this repair order should not have any
accounting entries linked to it.

opw-5429996

Forward-Port-Of: odoo/odoo#254468

Loading assets bundles into an iframe requires the iframe to be connected (present in the DOM) at time of insertion.

However, it can happen that iframes are removed from the DOM before all their assets have loaded in. In these instances, errors from failed bundle loads will turn into tracebacks.

This is generally not an issue in Chromium-based browsers as iframes do not fire a load event if they are disconnected; however, in Gecko-based browsers, this can happen. As such, mass_mailing users using Firefox currently receive a systematic traceback, as the CSS file "mass_mailing.assets_inside_builder_iframe.css" will not load.

Steps to reproduce:
- Use Firefox (or a Gecko-based browser)
- Open a new mailing
- Select the Events theme and make an edit (add a space...)
- Save the mailing
- Wait for 23 seconds

The bug may be non-deterministic.

Fix:

Errors during the iframe load process will no longer bubble up if their iframe is disconnected when the error occurs.

task-6293998

Co-authored-by: Damien Abeloos <abd@odoo.com>

Forward-Port-Of: odoo/odoo#269324

**Step to reproduce**
Reproducible in single app

The "name" field make this assertion fails:
```
self.assertRecordValues(sale_order.order_line[0], [{
            "product_id": no_variant_product_tmpl.product_variant_id.id,
            "name": 'No Variant\nAttribute: Value 1',
```
**Observation**
The name will not be the same depending which app are installed, purchase_product_matrix, changes the name of the product if there is a attribute value of a never variant: https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase_product_matrix/models/purchase.py#L168-L174 Which will be passed to the purchase_order_line:
https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase/models/purchase_order_line.py#L630-L634 that will pass the information to the sale order:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L114 https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L125-L126

**Additional information**
Since this [commit](https://github.com/odoo/odoo/commit/b8ebb26553f8170061debc7532606fd4777f0fcd#diff-5684edced9bdfc98021a85de4c6cdf691ea7add74e56ab50334a1d7db9ef4224R90) product_no_variant_attribute_value_ids was directly added in the purchase module.

breaking commit : https://github.com/odoo/enterprise/commit/bf286a0005b8e22ffa717419cd2dfacff861a265 
runbot-242362

Forward-Port-Of: odoo/odoo#268016

Issue:
----------------------------------------
When in a negative timezone, the "Out of Office until..." text in discuss shows the day before.

Steps to reproduce:
----------------------------------------
- Change the timezone of the user to "America/Toronto" for example
- Have an employee currently on leave until tomorrow
- Open discuss to chat with this employee
- The "Out of Office until..." shows today's date

Cause:
----------------------------------------
When calling `toLocaleString()` without a timezone specified in the options, the date is converted to local time (in the browser's timezone).

Here `persona.out_of_office_date_end` is just a date, `deserializeDateTime()` converts it to a timestamp, so the same day at 0am. Then if the timezone is negative, the timestamp becomes an hour the previous day when calling `toLocaleString()`. The format we give `DateTime.DATE_MED` doesn't include hours, so we just display the previous date.

Solution:
----------------------------------------
Add `timeZone:"UTC"` in the options to avoid the timezone conversion.

opw-6252040

Forward-Port-Of: odoo/odoo#268886
Forward-Port-Of: odoo/odoo#267479

\* = website

### Issue:
When a page is created either through the configurator or from an
existing page template, block-level snippets do not display the correct
title in the builder sidebar. Instead, "Block" is shown for all
snippets.

### Steps to Reproduce:

- **Configurator:**
  1. Install the website module or create a new website from Settings.
  2. Complete all configurator steps. Do not use "Skip and start from
     scratch".

- **Page template:**
  1. Open the website and click the "New" button in the systray.
  2. Click on "Page" and choose any template other than a blank page.

### Observed behavior:
The builder sidebar shows "Block" in the option container for all
snippets instead of their actual names.

### Reason:
Previously, just before the builder was opened, the `data-name`
attribute was injected through `_computeSnippetTemplates()` for any
snippet that did not already have it. This behavior was lost after the
plugin refactoring.

### Fix:
As before, we now inject the `data-name` attribute during builder setup
for snippets that do not already have it.

task-[6087348](https://www.odoo.com/odoo/all-tasks/6087348)

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

Forward-Port-Of: odoo/odoo#269287
Forward-Port-Of: odoo/odoo#259893

Currently, error occurs when user removes date on Accrued Expense Entry wizard.

Steps to replicate:
- Install `purchase` and `accountant` with demo.
- Open any Purchase Order > Click on cog menu > Accrued Expense Entry.
- Remove value from `date` and click else where.

Error:
```
  File '/home/odoo/odoo19/community/addons/account/wizard/accrued_orders.py', line 67, in _compute_reversal_date
    if not record.reversal_date or record.reversal_date <= record.date:
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<=' not supported between instances of 'datetime.date' and 'bool'

```

Cause:
- As the user removed value from `date`, [here] `record.date` is received as False.
- As a result the comparison `record.reversal_date <= record.date` causes this error to occur.

Solution:
- Added a conditional check for `date` before the date comparison.

[here]: https://github.com/odoo/odoo/blob/8791cdcd89ea3cb56b1fac63b3e2ffbd2956a912/addons/account/wizard/accrued_orders.py#L67

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

Forward-Port-Of: odoo/odoo#269418
Forward-Port-Of: odoo/odoo#262568

…unt number

When a provider returns an account without `account_number` (typical for Canadian banks, which do not use IBANs), the existing-journal search ran with `bank_account_number = False`. Because `bank_account_number` is a related field on `bank_account_id.account_number`, that search matched every bank journal in the user's allowed companies whose `bank_account_id` was unset.

If any of those journals was tied to a connected online link, the new sync was blocked with the misleading error "There's already a synchronized journal linked to this IBAN", even though no IBAN was involved.

Skip the search entirely when `account_number` is falsy: without an identifier there is nothing meaningful to dedup against, and the downstream code already handles `existing_journals` being empty by creating a fresh journal.

Note: when the provider omits `account_number`, a delete-and-recreate of the connection will now create a fresh journal rather than coincidentally reusing an unlinked empty-`bank_account_number` journal. That reuse path already failed (with a spurious "IBAN already connected" error) as soon as the user had more than one such journal, so the prior behavior was not reliable. The supported recovery path remains the reconnect button on the existing journal, which uses the `active_id` branch and is unchanged.

opw-6253563

Steps to reproduce:
------------------------------------------
1. Install Time Off module
2. Create a new Time Off type with Payroll Code (e.g, TEST)
3. Duplicate the Time Off type

Observation:
------------------------------------------
User Error raised:
```
Cannot insert 'Test (copy)':
Work entry type 'Test' of code 'TEST', with no country assigned, already exists.
```

Issue:
------------------------------------------
When you duplicate a Time off type, Odoo's default `copy()` method doesn't modify the code field. The `_check_code_unicity` constraint enforces that each combination of `code` and `country_id` must be unique. Since your duplicated record has the same `code`, the same `country_id` and a different `name`. The constraint correctly raises an error.

Solution:
------------------------------------------
Override the `copy()` method to automatically append a suffix to the code field when duplicating, similar to how the name field gets '(copy)' appended.

opw-6225931

### Steps to reproduce:
- Download "Website" app
- In the portal's "/my/account" address form, enter a "Company Name"
- Click "Save" to submit the form
- Reload the page and check if the company name was saved
> Company name isn't updated

### Cause of Issue:
`_create_or_update_address()` method was passing the 'parent_name' field directly through the main `partner_sudo.write(address_values)` call.
https://github.com/odoo/odoo/blob/391cec39b6048ad4f49015fd67888895dc176ee5/addons/portal/controllers/portal.py#L564-L571 Since `parent_name` is a readonly related field (related to `parent_id.name`), the write operation would fail silently to update it, creating orphaned changelog entries instead of properly updating the parent company entity.

### Fix:
Since the update of contact forms in v19.1, we can't just edit the "Company Employer" field without assigning an actual partner (existing or create new). The solution here was to add a case to account for when the portal user is an individual adding a "Company Name" for the first time.

opw-6115158

Forward-Port-Of: odoo/odoo#264356

The media list snippet forces the image to fill the height of its row. The
image column carries align-self-stretch and the image carries h-100, so when
the text next to the image is longer than the image is tall, the row grows to
fit the text and the image is stretched to that height (and cropped through
object-fit: cover). The longer the text, the more the image is distorted.

Drop h-100 from the image and align-self-stretch from its column in the
s_media_list snippet and in the mass_mailing_themes templates that reuse it.
With no forced height the image keeps its natural aspect ratio and the row
height follows its content, so the image is laid out next to the text instead
of being stretched to match it.

Steps to reproduce:
1. Open Email Marketing and create a new mailing.
2. Select the Blogging template for the mail body.
3. In a media item, replace the text next to an image with a very long paragraph.

=> The image is stretched and cropped to match the height of the text.

Ticket [link](https://www.odoo.com/odoo/project.task/5117571)
opw-5117571

Forward-Port-Of: odoo/odoo#268675
Forward-Port-Of: odoo/odoo#238138

Steps to Reproduce:
1. Install Accounting module (without Point of Sale).
2. Create a customer.
3. Create a journal entry with that customer set only at line level.
4. Post the journal entry.
5. Open the customer form.

Issue:
The Due smart button is not visible on the partner form even though an outstanding balance exists for the customer.

Note: This issue does not reproduce when Point of Sale is installed, as the POS module overrides `_compute_has_moves` with its own implementation that checks the outstanding balance directly.

Root Cause:
The `_compute_has_moves` method queries only `account.move `for partner matching. When a partner is referenced only at the account.move.line level, the partner is never picked up by this query, resulting in `has_moves = False` and the Due button remaining hidden.

Fix:
Replaced the EXISTS-based implementation with a UNION-based approach as the EXISTS implementation evaluated the query per partner row, whereas UNION processes all partners in a single batch query. Additionally extended the UNION to also include account.move.line partner matching, ensuring partners referenced only at the line level, are correctly detected and has_moves is set to True.

Result:
The Due smart button is now correctly visible for all partners with an outstanding balance, regardless of whether the partner is set at the journal entry level or only at the line level.

owp = 6243562

Forward-Port-Of: odoo/enterprise#120294
Forward-Port-Of: odoo/enterprise#119084