This fix prevents the Loans app from crashing during installation when some demo data is unavailable. It also updates an accounting report test to match recent dependency changes, helping automated checks remain reliable.

Prior to this change, if the demo data were loaded for account but couldn't be for account_loans, its installation would simply crash trying to reference an unknown xml_id 'account_loans_loan_demo1'.

See https://github.com/odoo/odoo/pull/200997 for details on how to reproduce

This fixes an issue where action buttons did not appear after users selected records in Data Cleaning and Knowledge list views. Users can now see and use the expected actions when working with selected items.

During the introduction of the Kanban's selection feature (cf. commit
[1]), the extraction of the SelectionBox component left some
`nbSelected` getters' references while it actually was renamed
`hasSelectedRecords`.

This commit adapts them properly.

[1]: https://github.com/odoo/odoo/commit/877895cc10b1218396f77f995dc7c87a9d22f585

This change restores a previous version of an appointment scheduling test because the newer version was failing unpredictably in automated checks. It helps keep the release process moving by preventing false failures that could delay merges, with no expected impact on customer-facing behavior.

Since odoo/enterprise#80074, the test `appointment status pill colors` randomly fails on runbot. The reasons are not clear yet, but to prevent that error from randomly popping on builds and potentially from slowing down the merge process, this commit simply reverts the changes to come back to the version of this test file as it was before odoo/enterprise#80074

Runbot error-159865

For upgrade tests, the test modules can be imported from odoo.upgrade. The current solution is not correct since `test_module_path` would be `odoo/upgrade/module/tests/test_file.py` and so the condition `test_module_path.endswith(file_path):` would match `/upgrade/module/tests/test_file.py` (but not `/odoo/upgrade/module/tests/test_file.py`) whitch is not really expected. The problem is even more problematic in master with #195929 because the tag `/module/tests/test_file.py` won't match

For upgrade tests, the test modules can be imported from odoo.upgrade.

The current solution is not correct since `test_module_path` would be `odoo/upgrade/module/tests/test_file.py`  and so the condition `test_module_path.endswith(file_path):` would match `/upgrade/module/tests/test_file.py` (but not `/odoo/upgrade/module/tests/test_file.py`) whitch is not really expected. 

The problem is even more problematic in master with #195929 because the tag  `/module/tests/test_file.py` won't match  `odoo/upgrade/module/tests/test_file.py`

Forward-Port-Of: odoo/odoo#200969

See commits :) Entreprise PR: https://github.com/odoo/enterprise/pull/79471 Forward-Port-Of: odoo/odoo#197891

See commits :)

Entreprise PR: https://github.com/odoo/enterprise/pull/79471

Forward-Port-Of: odoo/odoo#197891

Steps to reproduce ================== - Install repair,web_studio - Go to repair - Open any record - Open studio - Switch to the misceallaneous tab - Click on the Operation Type field - Add the "Technical / Receive notifications in Odoo" group in "Allow visibility to groups" ``` TypeError: Cannot read properties of undefined (reading '0') at PropertiesField._getSeparatorFoldKey ``` Cause of the issue ================== Since the user doesn't have that group, the field `p

Steps to reproduce
==================

- Install repair,web_studio
- Go to repair
- Open any record
- Open studio
- Switch to the misceallaneous tab
- Click on the Operation Type field
- Add the "Technical / Receive notifications in Odoo" group in "Allow visibility to groups"

```
TypeError: Cannot read properties of undefined (reading '0')
  at PropertiesField._getSeparatorFoldKey
```

Cause of the issue
==================

Since the user doesn't have that group, the field `picking_type_id` will no be available.

```py
repair_properties = fields.Properties(
    'Properties',
    definition='picking_type_id.repair_properties_definition'
)
```

That field is needed as it's the definition field for the repair_properties field.

Solution
========

When postprocessing views, we already add some fields that are needed by others. We can do the same for properties fields.

opw-4594796

Forward-Port-Of: odoo/odoo#200197

How to reproduce: - Create a dashboard with pivot grouped such that some group values are empty (E.g. CRM lead > group by 'lost reason') - Add a pivot.header formula where you point towards the positional field (e.g. `=ODOO.PIVOT.HEADER(1,"#lost_reason_id",1)` ) - Add a relational filter that points on the 'lost reason' model - Go back to the dashboard app to visualize it and click on the modified cell -> crash The pivot ui plugin did not properly account for that scenario as it was ex

How to reproduce:
- Create a dashboard with pivot grouped such that some group values are empty (E.g. CRM lead > group by 'lost reason')
- Add a pivot.header formula where you point towards the positional field (e.g. `=ODOO.PIVOT.HEADER(1,"#lost_reason_id",1)` )
- Add a relational filter that points on the 'lost reason' model
- Go back to the dashboard app to visualize it and click on the modified cell

-> crash

The pivot ui plugin did not properly account for that scenario as it was expecting a string as an output of `getPivotHeaderValue`. However, the later had changed its return type since we handle both balues and stringified values as arguments in the formula.

Task-4582602

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

Forward-Port-Of: odoo/odoo#199634
Forward-Port-Of: odoo/odoo#198002

### Steps to reproduce: - Create a new invoice - Attach a ZIP file then a PDF file - The file viewer shows but tries to preview the ZIP file - Happens with all non-viewable files ### Cause: The ZIP file is put as main attachment and the method `register_as_main_attachment` only change the main attachment (with `force=False`) when there is no main attachment. The behavior of the file viewer is problematic because we cannot switch between the attachments in the preview, so we cannot see

### Steps to reproduce:
- Create a new invoice
- Attach a ZIP file then a PDF file
- The file viewer shows but tries to preview the ZIP file
- Happens with all non-viewable files

### Cause:
The ZIP file is put as main attachment and the method `register_as_main_attachment` only change the main attachment (with `force=False`) when there is no main attachment.

The behavior of the file viewer is problematic because we cannot switch between the attachments in the preview, so we cannot see the PDF. But if we add another PDF file (so one ZIP and 2 PDFs), we can switch but it will never show the ZIP again, only the two PDFs. This behavior is due to the [next/previous arrows](https://github.com/odoo/odoo/blob/e4da068d6c9c8885dd4663d50dee11c9ea1516a3/addons/mail/static/src/components/web_client_view_attachment_view/web_client_view_attachment_view.xml#L13) being displayed only if [`attachmentsInWebClientView`](https://github.com/odoo/odoo/blob/e4da068d6c9c8885dd4663d50dee11c9ea1516a3/addons/mail/static/src/models/attachment.js#L323-L328) contains more than one item. But this list only contains viewable attachments (PDF or Images), and the next/previous arrows only take attachments from this list. As the arrows are [changing the main attachment](https://github.com/odoo/odoo/blob/e4da068d6c9c8885dd4663d50dee11c9ea1516a3/addons/mail/static/src/models/web_client_view_attachment_view.js#L17) to change the displayed preview, it never comes back to the problematic ZIP file.

### Solution:
Also display the arrows if the main attachment is not viewable and there is more than one attachment.
This way the user can return in the list of viewable attachments.

This is not an optimal because Odoo will still try to display the ZIP file, but it is a simple fix that works. 
I tried restraining the main attachment field only to viewable files in this [PR](https://github.com/odoo/odoo/pull/196390), but it seems to break things specially with OCR extraction and apparently it is sometimes wanted to have an XML as main attachment.

opw-4486363

Forward-Port-Of: odoo/odoo#200817
Forward-Port-Of: odoo/odoo#196446

Before this PR, the real live chat operator name was shown on the channel join notification. The issue is that the name is stored in the message in database, which does not allow configuration according to who's seing the message. A decent solution is to always store the live chat user name if any, which comes with some downsides such as not being able to update the messages afterwards. However, live chat conversations are short lived which mitigates the issue. Description of the issue/fea

Before this PR, the real live chat operator name was shown on the channel join notification. The issue is that the name is stored in the message in database, which does not allow configuration according to who's seing the message.

A decent solution is to always store the live chat user name if any, which comes with some downsides such as not being able to update the messages afterwards. However, live chat conversations are short lived which mitigates the issue.

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

Forward-Port-Of: odoo/odoo#200565

- Show price/unit of orderline in receipt screen & in product screen (only for orderlines where the price was manually changed). - Remove useless functions `getOldUnitDisplayPrice` and `priceChange`. task-id: 4606620 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199538

- Show price/unit of orderline in receipt screen & in product screen (only for orderlines where the price was manually changed).
- Remove useless functions `getOldUnitDisplayPrice` and `priceChange`.

task-id: 4606620



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

Forward-Port-Of: odoo/odoo#199538

- Fix missing space between "Customer Note" & "Kitchen Note" - Reduce space for combo products (register & receipt) - Remove empty <ul> element from order lines (when no `packLotLines`) task-id: 4578826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197816

- Fix missing space between "Customer Note" & "Kitchen Note"
- Reduce space for combo products (register & receipt)
- Remove empty <ul> element from order lines (when no `packLotLines`)



task-id: 4578826






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

Forward-Port-Of: odoo/odoo#197816

Before this commit, any client error would lead to a displayed Odoo traceback dialog. While the goal is obviously to have a code without any possible traceback, visitors really should not see those. This is especially true in the website: if a website visitor (who has no idea the visited website uses Odoo) gets a traceback because of a Chrome extension, it makes no sense to display the traceback at all. It can be justified for connected users (not portal, but base.group_user) as they li

Before this commit, any client error would lead to a displayed Odoo
traceback dialog. While the goal is obviously to have a code without any
possible traceback, visitors really should not see those.

This is especially true in the website: if a website visitor (who has no
idea the visited website uses Odoo) gets a traceback because of a Chrome
extension, it makes no sense to display the traceback at all. It can be
justified for connected users (not portal, but base.group_user) as they
likely are employees of the company using Odoo and should be able to see
issues and report them to us (e.g. even in the Chrome extension case: so
we can make our code support the breaking extension or decide that it
cannot be used alongside Odoo).

The errors for visitors are still logged in the browser console, even
with more detailed logs in that case.

Note that we use `await user.hasGroup('base.group_user')` upon error to
be able to implement this feature. In the frontend, it actually does a
RPC call as that group information is not in the session_info. We could
add it in the session_info, but since the use case is showing an error,
the extra RPC *upon error* is fine for now.

Notice that traceback dialogs (and the related error handling that comes
with them, like preventing an error to be considered as an error and
logged in the console) are also still enabled in debug mode or during
testing tours.

task-4290643

Forward-Port-Of: odoo/odoo#185481

Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle customer accounts. Steps to reproduce: ------------------- * Install **l10n_es_pos** and switch to the ES Company * Open shop session * Add products to the order, select any customer, pay with customer account * Select **New order** * Select the previous customer and select **Settle due accou

Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle customer accounts.

Steps to reproduce:
-------------------
* Install **l10n_es_pos** and switch to the ES Company
* Open shop session
* Add products to the order, select any customer, pay with customer account
* Select **New order**
* Select the previous customer and select **Settle due accounts**
* Select any payment method
* Validate order -> Yes
> Observation: Cannot invoice empty order

Why the fix:
------------
Spain requires to invoice all orders. In Pos, everything is considered as an order but settling customer accounts does not fall under the definition of an order outside of Odoo (no transfer of product, amount=0).

Therefore when we settle customer account we skip the automatic invoicing and fallback on the pos bahavior without the localization.

opw-4185144

Enterprise PR: https://github.com/odoo/enterprise/pull/71958

Forward-Port-Of: odoo/odoo#199197
Forward-Port-Of: odoo/odoo#183682

Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back who the recipients were. In this work we also log the (redacted) From and To headers. We decided to redact the headers out of excessive caution regarding the GDPR. The new `email_anonymize` function must balance disambiguation and redaction. Disambiguation so it is easy to tell two different emai

Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back who the recipients were.

In this work we also log the (redacted) From and To headers. We decided to redact the headers out of excessive caution regarding the GDPR.

The new `email_anonymize` function must balance disambiguation and redaction. Disambiguation so it is easy to tell two different email addresses appart (for debugging). Redaction so it hard to find the original email address back (for privacy). It must also be simple.

We conducted several experiments using a dataset of 600ish email address (95% of which have a local part that is at least 6 characters long) to determine a nice function. The final function keep the first character for shorter inputs (length of local part < 6) and the first plus two lasts chars for longer inputs (>=6). Using that function we achieve a 99% disambiguation of emails in the dataset (with or without redacting the domain) while retaining minimal info (3 chars at most).

Redacting the domain isn't that useful as most addresses use gmail, hotmail, outlook, yahoo.

Task-4361561

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

Forward-Port-Of: odoo/odoo#198839
Forward-Port-Of: odoo/odoo#188697

Since the upgrade of Chartjs to v4.3 in [commit 1], stacked charts in website were wrongly computed. This commit fixes it. [commit 1]: https://github.com/odoo/odoo/commit/7e3c1ecdb86110912b15722e600f9571692807ed task-4603349 Forward-Port-Of: odoo/odoo#199186

Since the upgrade of Chartjs to v4.3 in [commit 1], stacked charts in website were wrongly computed. This commit fixes it.

[commit 1]: https://github.com/odoo/odoo/commit/7e3c1ecdb86110912b15722e600f9571692807ed

task-4603349

Forward-Port-Of: odoo/odoo#199186

Changing the name: PDF -> Invoice PDF. task-4614454 Forward-Port-Of: odoo/odoo#199934

Changing the name: PDF -> Invoice PDF.

task-4614454

Forward-Port-Of: odoo/odoo#199934

Before this commit, when the compute method of the project_id field in `project.task` model is triggered, the compute method of `display_in_project` field is not triggered and so when a user converts a sub-task to a task and convert again the task into a sub-task, the display_in_project for that sub-task stays at True instead of being falsy as expected. This commit makes sure the compute of `display_in_project` field is triggered even if the one of the project_id is triggered since now the co

Before this commit, when the compute method of the project_id field in `project.task` model is triggered, the compute method of `display_in_project` field is not triggered and so when a user converts a sub-task to a task and convert again the task into a sub-task, the display_in_project for that sub-task stays at True instead of being falsy as expected.

This commit makes sure the compute of `display_in_project` field is triggered even if the one of the project_id is triggered since now the compute of project_id no longer depends on `display_in_project` field and so we will not have a dependency loop.

Steps to reproduce the issue:
----------------------------
0. Install Project app.
1. Create a project A
2. Create a task A on that project A
3. Create a sub-task B in task A
4. Go to the form view of sub-task B
5. Clear the parent_id field on that sub-task (to convert it into a task)
6. Set the task A as the parent task of sub-task B
7. Go back to the kanban view of tasks of Project A

Current behavior:
----------------

The sub-task B is displayed in the kanban view even if the filter `Show sub-task` is not enabled

Expected behavior:
-----------------

The sub-task B should not be displayed in the kanban view if the filter Show sub-task is not enabled.

opw-4597692

Forward-Port-Of: odoo/odoo#200582

**Problem**: When collaborating, indenting a list item (`LI`) using "Tab" causes a structural issue in the DOM. **Scenario**: 1. User C1 and C2 both edit a list item in collaboration mode. - Common structure at the beginning: `<ul><li>[]</li></ul>` - When C1 presses "Tab", the DOM updates to: `<ul (new)><li (new)><ul><li>[]</li></ul></li (new)></ul (new)>` 2. At this point C2 still has: `<ul><li>[]</li></ul>` 3. When C2 receives a mutation update, it tries to inse

**Problem**:
When collaborating, indenting a list item (`LI`) using "Tab"
causes a structural issue in the DOM.

**Scenario**:
1. User C1 and C2 both edit a list item in collaboration mode.
   - Common structure at the beginning:
     `<ul><li>[]</li></ul>`
   - When C1 presses "Tab", the DOM updates to:
     `<ul (new)><li (new)><ul><li>[]</li></ul></li (new)></ul (new)>`
2. At this point C2 still has:
   `<ul><li>[]</li></ul>`
3. When C2 receives a mutation update, it tries to insert:
   `<ul (new)><li (new)><ul><li>[]</li></ul></li (new)></ul (new)>`
   before:
   `<li>[]</li>`
   - **Issue**: `li` is already inside `li (new)`, causing a DOM error.

**Solution**:
- Before inserting, remove `li2`, then reinsert it at the
  correct position.
- This ensures the `.before()` operation does not conflict
  with `li1`.

**PS**: I adapted `createPeers` and `Wysiwygs` to make it work with
custom content and by default it will use `initialValue`, because in
this test i needed to test collaboration with `ul`, `li`.

**Steps to Reproduce**:
1. Open two tabs with the editor.
2. Create a bullet list in the first tab.
3. Press "Tab" to indent a list item.
4. Observe a traceback error in the second tab.

opw-4538671

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

Forward-Port-Of: odoo/odoo#199402

### Description of the issue/feature this PR addresses: - The editor only provided a font size dropdown with predefined options, preventing the selection of a custom font size. ### Desired behavior after PR is merged: - A font size input field is added to toolbar using an _`iframe`_, ensuring the selection remains intact in editable area. - Clicking the font size input selects the text and displays the predefined font size dropdown. - The entered value in the font size input is appl

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

- The editor only provided a font size dropdown with predefined options, preventing the selection of a custom font size.

### Desired behavior after PR is merged:

- A font size input field is added to toolbar using an _`iframe`_, ensuring the selection remains intact in editable area.
- Clicking the font size input selects the text and displays the predefined font size dropdown.  
- The entered value in the font size input is applied to the selected content after a _`200ms`_ debounce.
- The font size can also be selected from the dropdown.
- Font size dropdown closes on Enter and Tab key press.
- ArrowUp/Down moves focus to font size dropdown.

task-4488396

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

Forward-Port-Of: odoo/odoo#196961

The post processing cron has been recently changed to be disabled by default (ecc5711f002180d7ccf37654d5c3ea5b057b3a17) but this change wasn't properly tested on module updates, which did disable the cron regardless of the providers states. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200897

The post processing cron has been recently changed to be disabled by default (ecc5711f002180d7ccf37654d5c3ea5b057b3a17) but this change wasn't properly tested on module updates, which did disable the cron regardless of the providers states.


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

Forward-Port-Of: odoo/odoo#200897

Logs when odoo was started manually were polluted by zeros and ones due to recurrent echos to the led configuration file. Forward-Port-Of: odoo/odoo#200696

Logs when odoo was started manually were polluted by zeros and ones due to recurrent echos to the led configuration file.

Forward-Port-Of: odoo/odoo#200696

**Issue:** - When selecting the `DIN 5008 (external_layout_din5008)` layout in the report layout and printing the report, the footer font size appears too small.  **Solution:** - After the PR [#100723](https://github.com/odoo/odoo/pull/100723), the table layout was stabilized, but it introduced a very small `font-size (0.7em)`. A subsequent change by `malb` applied a font-size to the `.co

**Issue:**

-  When selecting the `DIN 5008 (external_layout_din5008)` layout in the report layout and printing the report, the footer font size appears too small.

![before_fix](https://github.com/user-attachments/assets/603725a6-065b-43bf-948c-009476833a3b)


**Solution:**

- After the PR [#100723](https://github.com/odoo/odoo/pull/100723), the table layout was stabilized, but it introduced a very small `font-size (0.7em)`. A subsequent change by `malb` applied a font-size to the `.company_details` class, but this is no longer sufficient due to the presence of `<p>` tags in the footer.

To resolve this - 
- remove the general font-size directive
- add a new one in li
- add a limited line-height to the `<p>` tag to reduce the vertical size of the footer, given we are boosting the font size.


![after_fix](https://github.com/user-attachments/assets/b7c033f3-7c84-488a-b8c9-bb6198be59dd)

opw-4506533

Forward-Port-Of: odoo/odoo#198117

Before this commit, since https://github.com/odoo/odoo/pull/175858, the call view in mobile was too small to fit all of the call UI, this commit fixes this issue. | Before | After | |--------|--------| |  |  | Forward-Port-Of: odoo/odoo#200838 Forward-Port-Of: odoo/odoo#200703

Before this commit, since https://github.com/odoo/odoo/pull/175858,

the call view in mobile was too small to fit all of the call UI, this commit fixes this issue.

| Before | After |
|--------|--------|
| ![image](https://github.com/user-attachments/assets/86452883-f37c-4e18-961c-7bf2a2aceff6)  | ![image](https://github.com/user-attachments/assets/aa71c7c8-e8c0-4647-a261-6f496bed2dbb) |

Forward-Port-Of: odoo/odoo#200838
Forward-Port-Of: odoo/odoo#200703

Versions -------- - 18.0+ Steps ----- 1. Set website to display prices tax included; 2. have a combo item published; 3. open product's eCommerce page as public user. Issue ----- Access Error. Cause ----- Commit 4ec8d2198a1a0 added a disclaimer for combo items products tax calculations. It checks the `taxes_id` fields of the `combo_item_ids`. Issue is that the `product.combo` model isn't accessible for public users (unlike `product.product` and `product.template`. Solution

Versions
--------
- 18.0+

Steps
-----
1. Set website to display prices tax included;
2. have a combo item published;
3. open product's eCommerce page as public user.

Issue
-----
Access Error.

Cause
-----
Commit 4ec8d2198a1a0 added a disclaimer for combo items products tax calculations. It checks the `taxes_id` fields of the `combo_item_ids`. Issue is that the `product.combo` model isn't accessible for public users (unlike `product.product` and `product.template`.

Solution
--------
Use `sudo` on the combo product.

opw-4608719

Forward-Port-Of: odoo/odoo#200887

When a live chat session is created, the "isLoaded" field of the thread comes from the server to avoid loading messages if it's not needed. However, sending this information on the bus can rollback the newest value after message fetch. This PR ensures this information is not sent through the bus. This issue was discovered in 18.2 as websockets are enabled during tours. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merg

When a live chat session is created, the "isLoaded" field of the thread comes from the server to avoid loading messages if it's not needed.

However, sending this information on the bus can rollback the newest value after message fetch. This PR ensures this information is not sent through the bus.

This issue was discovered in 18.2 as websockets are enabled during tours.

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

Forward-Port-Of: odoo/odoo#200531

Fix error in .pot and .po files that led to wrong translations. opw-4621039 Forward-Port-Of: odoo/odoo#200708

Fix error in .pot and .po files that led to
wrong translations.

opw-4621039

Forward-Port-Of: odoo/odoo#200708

Before this PR, creating a live chat in a first tab would correctly open the chat window in a second tab. However, messages were not received in real-time before the second tab reload. This issue occurs because the bus service is not started in the second tab. To solve this issue, the bus service is now started when there is at least one thread known locally. The behavior stays lazy, nothing is starting until required. part of task-4607689 Description of the issue/feature this PR addres

Before this PR, creating a live chat in a first tab would correctly open the chat window in a second tab. However, messages were not received in real-time before the second tab reload. This issue occurs because the bus service is not started in the second tab.

To solve this issue, the bus service is now started when there is at least one thread known locally. The behavior stays lazy, nothing is starting until required.

part of task-4607689

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

Forward-Port-Of: odoo/odoo#199779

opw-4464701 Forward-Port-Of: odoo/odoo#199707 Forward-Port-Of: odoo/odoo#199548

opw-4464701

Forward-Port-Of: odoo/odoo#199707
Forward-Port-Of: odoo/odoo#199548

Previously, the toaster notification incorrectly displayed the number of product variants instead of actual products found. This commit removes the (useless) notification when products are found and only displays "No more product found" when no results match the search. task-id: 4595775 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198960

Previously, the toaster notification incorrectly displayed the number of product variants instead of actual products found. This commit removes the (useless) notification when products are found and only displays "No more product found" when no results match the search.

task-id: 4595775





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

Forward-Port-Of: odoo/odoo#198960

### Before Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services.  - Access to Codabox was limited to companies with an accounting firm with a VAT number assigned ### Now Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical  VAT numbers.   - Module summary, descriptions and ot

### Before

Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services. 
- Access to Codabox was limited to companies with an accounting firm with a VAT number assigned


### Now

Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical  VAT numbers.  

- Module summary, descriptions and other texts are updated to generalize 

- Companies without an accounting firm can access the Codabox configuration settings

task - 4460499

Forward-Port-Of: odoo/odoo#200434
Forward-Port-Of: odoo/odoo#198622

Due to the pasword security meter on the right of the input, the content of the input can overflow behind the security meter. Note: I seized the opportunity to reindent this file according to our coding guidelines task-4630394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200522

Due to the pasword security meter on the right of the input, the content of the input can overflow behind the security meter.

Note: I seized the opportunity to reindent this file according to our coding guidelines

task-4630394

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

Forward-Port-Of: odoo/odoo#200522

Before this commit, some tests based on the default text color only worked if the tests were run with enterprise because the default text color was hard-coded based on the style of enterprise. 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 Forward-Port-Of: odoo/odoo#200643

Before this commit, some tests based on the default text color only worked if the tests were run with enterprise because the default text color was hard-coded based on the style of enterprise.

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

Forward-Port-Of: odoo/odoo#200643

- Install l10n_cz and switch to a cz company. - In bank reconciliation, create a new bank transaction and set its date to a past or future date (not today) The date of the newly created bank transaction is automatically set to today. In the Czech Republic, it is required to use the taxable supply date as the accounting date. This functionality was introduced by 184c1e65a9992e890af81bb60eeeb7b8b825ab54. However, it also sets the taxable supply date for bank transactions, which is incorre

- Install l10n_cz and switch to a cz company.

- In bank reconciliation, create a new bank transaction and set its date to a past or future date (not today)

The date of the newly created bank transaction is automatically set to today.

In the Czech Republic, it is required to use the taxable supply date as the accounting date. This functionality was introduced by 184c1e65a9992e890af81bb60eeeb7b8b825ab54. However, it also sets the taxable supply date for bank transactions, which is incorrect.

opw-4544305




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

Forward-Port-Of: odoo/odoo#200127

Currently, an error occurs when users press the data-hotkey 'ALT + Q' to split expense and any expense is not available in the split expense line. Step to produce: - Install the ```hr_expense``` module. - Create an expense, add a category, and click on the `Split Expense` button. - Delete all expenses from the split expense line, and press the data-hotkey `ALT + Q` to click on the `Split Expense` button to split expenses. ```IndexError: tuple index out of range``` This occurs becau

Currently, an error occurs when users press the data-hotkey 'ALT + Q' to split expense and any expense is not available in the split expense line.

Step to produce:

- Install the ```hr_expense``` module.
- Create an expense, add a category, and click on the `Split Expense` button.
- Delete all expenses from the split expense line, and press the data-hotkey `ALT + Q` to click on the `Split Expense` button to split expenses.

```IndexError: tuple index out of range```

This occurs because the system attempts to access the first expense from the split expense line [1], but expenses are not available.

Link [1]: https://github.com/odoo/odoo/blob/280b762e7cd1b3d9a578bbae60cbb9b137ee5ce5/addons/hr_expense/wizard/hr_expense_split_wizard.py#L36

To resolve this issue, Disable a 'Split Expense' button after simply adding a  `disabled` attribute on it.

Sentry-6015854429

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

Forward-Port-Of: odoo/odoo#200438
Forward-Port-Of: odoo/odoo#190323

Before this commit: ==================== Archiving a product that is part of draft orderlines in an open session caused an error in the Indian localization. Specifically, the system threw a "l10n_in_hsn_code" error when attempting to reopen the session, as the archived product was no longer accessible. After this commit: ==================== A user-friendly error message is displayed to notify the user about the archiving products when the session is open and products are in use, ensuring

Before this commit:
====================
Archiving a product that is part of draft orderlines in an open session caused an error in the Indian localization. Specifically, the system threw a "l10n_in_hsn_code" error when attempting to reopen the session, as the archived product was no longer accessible.

After this commit:
====================
A user-friendly error message is displayed to notify the user about the archiving products when the session is open and products are in use, ensuring data consistency and preventing errors when reopening sessions.

Task-4518025

Forward-Port-Of: odoo/odoo#195563

We made invisible the `screen_orientation` field if `can_be_kiosk` was `False` on the IoT Box, but we still updated the screen orientation if `screen_orientation` was set: which was always the case as it has a default value. We now update only if the IoT Box `can_be_kiosk`. Task: 4606855 Forward-Port-Of: odoo/enterprise#81023

We made invisible the `screen_orientation` field if `can_be_kiosk` was `False` on the IoT Box, but we still updated the screen orientation if `screen_orientation` was set: which was always the case as it has a default value.
We now update only if the IoT Box `can_be_kiosk`.

Task: 4606855

Forward-Port-Of: odoo/enterprise#81023

How to reproduce the issue: - Create an expense budget and associate it to a project. - Create invoice/bills related to the project In the project dashboard view, the remaining value will be marked in green for expenses that exceed the budget (over-achieving costs) and in red for expenses that are under the budget (under-achieving costs). However, this was deemed non-intuitive, as under-achieving costs should be seen as a positive indicator. After this commit the color for expense budg

How to reproduce the issue:

- Create an expense budget and associate it to a project.
- Create invoice/bills related to the project

In the project dashboard view, the remaining value will be marked in green for expenses that exceed the budget (over-achieving costs) and in red for expenses that are under the budget (under-achieving costs). However, this was deemed non-intuitive, as under-achieving costs should be seen as a positive indicator.

After this commit the color for expense budget are inverted.

opw-4562815

Forward-Port-Of: odoo/enterprise#79965

Purpose ======= Recent changes have made bill encoding easier than ever (most notably, a bill date is set by default if left empty), but offering a robust duplicate bill detection is more important than ever in the modern electronic invoicing world, where bills are more and more handled automatically. We want to make sure that: - Potential duplicates remain visible at all time, including in list view - Automated actions like auto posting are not done when a potential duplicate is detect

Purpose
=======

Recent changes have made bill encoding easier than ever (most notably, a bill date is set by default if left empty), but offering a robust duplicate bill detection is more important than ever in the modern electronic invoicing world, where bills are more and more handled automatically.

We want to make sure that:
- Potential duplicates remain visible at all time, including in list view
- Automated actions like auto posting are not done when a potential duplicate is detected.

Specs
=====

1.  Do not hide the warning on potential bill duplicate for posted invoices. The information remains pertinent.

2. When a move should be posted automatically (by the Auto-post feature on account.move or by the OCR auto-post), but a potential duplicate is found, prevent the auto-post from happening. Log the information in the chatter: "Auto-post was disabled on this invoice because a potential duplicate was detected."

3. In list view put the reference in red background when a potential duplicate on that invoice is detected.

task-4578751

Community PR: https://github.com/odoo/odoo/pull/197891

Forward-Port-Of: odoo/enterprise#79471

This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts. opw-4185144 Community PR: https://github.com/odoo/odoo/pull/183682 Forward-Port-Of: odoo/enterprise#80125 Forward-Port-Of: odoo/enterprise#71958

This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts.

opw-4185144

Community PR: https://github.com/odoo/odoo/pull/183682

Forward-Port-Of: odoo/enterprise#80125
Forward-Port-Of: odoo/enterprise#71958

Adding a condition for Avatax not being enabled on the taxes column in portal view of sales orders. task: 4423974 Forward-Port-Of: odoo/enterprise#77683

Adding a condition for Avatax not being enabled on the taxes column in portal view of sales orders.
task: 4423974

Forward-Port-Of: odoo/enterprise#77683

## Issue: In Luxembourg companies, when creating an employee contract with an hourly wage, the indexed wage is always displayed as 0, causing the payslip to incorrectly show 0 for the basic salary. ## Steps to reproduce: 1. Create a new employee 2. Create a new contract for this employee with a hourly wage and Luxembourg: Regular Pay structure 3. Create a new payslip for this employee 4. Check the basic salary: it will be 0 ## Root cause: - The previous implementation did not account

## Issue:
In Luxembourg companies, when creating an employee contract with an hourly wage, the indexed wage is always displayed as 0, causing the payslip to incorrectly show 0 for the basic salary.

## Steps to reproduce:
1. Create a new employee
2. Create a new contract for this employee with a hourly wage and Luxembourg: Regular Pay structure
3. Create a new payslip for this employee
4. Check the basic salary: it will be 0

## Root cause:
- The previous implementation did not account for hourly wage contracts when computing the indexed wage, leading to incorrect salary calculations.

## Solution:
- Added logic to correctly compute the indexed wage for hourly contracts.
- Adjusted related salary rules to differentiate between hourly and monthly wage types.
- Updated views to reflect the correct unit (per month or per hour) based on the wage type.
- Added a test case to validate the correct computation for hourly contracts.

OPW-4460735

Forward-Port-Of: odoo/enterprise#79031
Forward-Port-Of: odoo/enterprise#78789

Steps to Reproduce the Bug: - Install stock_picking_batch. - Go to Barcode > Operations > Delivery Orders > Batches. - Select any batch: - Click on the Parameters button > In the Operation section: - Click on Return Products. Problem: A traceback is raised: "The method 'stock.picking.batch.action_create_return_picking' does not exist." The function “action_create_return_picking” belongs to the “stock.picking” model, not to “stock.picking.batch” records. We are not

Steps to Reproduce the Bug:
    - Install stock_picking_batch.
    - Go to Barcode > Operations > Delivery Orders > Batches.
    - Select any batch:
        - Click on the Parameters button > In the Operation section: - Click on Return Products.

Problem:
A traceback is raised:
"The method 'stock.picking.batch.action_create_return_picking' does not exist."

The function “action_create_return_picking” belongs to the “stock.picking” model, not to “stock.picking.batch” records. We are not supposed to be able to return products from a batch.

Moreover, even for “stock.picking” records, products can only be returned from done pickings. However, this button is displayed in all picking states except the done state:
https://github.com/odoo/enterprise/blob/2d5dbb93e6b33c2be786f9b2361c993f715d1a7f/stock_barcode/static/src/components/main.xml#L119

Solution:
Have the same condition for done pickings as in:
https://github.com/odoo/enterprise/blob/2d5dbb93e6b33c2be786f9b2361c993f715d1a7f/stock_barcode/static/src/components/main.xml#L165-L170

opw-4624039

Forward-Port-Of: odoo/enterprise#80717

Steps to reproduce: 1. Upload a link and Video type documents 2. Create a shortcut 3. Go to My drive 4. Kanban card not displayed correctly Technical Reason: When creating a shortcut via 'action_create_shortcut', missing 'mimetype' and 'url' fields caused improper rendering of link/video shortcuts. After this commit: will display the proper format of the link/video. Task-4477679 Forward-Port-Of: odoo/enterprise#78677

Steps to reproduce:
1. Upload a link and Video type documents
2. Create a shortcut
3. Go to My drive
4. Kanban card not displayed correctly

Technical Reason:
When creating a shortcut via 'action_create_shortcut', missing 'mimetype' and 'url' fields 
caused improper rendering of link/video shortcuts.

After this commit:
will display the proper format of the link/video.

Task-4477679

Forward-Port-Of: odoo/enterprise#78677

Steps to reproduce: - create two companies - create two analytic account (no company defined) - create for company B an analytic distribution model with one of the analytic account and define company A as parter - With Company A, create an invoice and on the line use the other analytic account and confirm Issue: The distribution model for Company B will not be used and only the account distribution from the original invoice will be defined on the line Cause: In the _get_distribution

Steps to reproduce:
- create two companies
- create two analytic account (no company defined)
- create for company B an analytic distribution model with one of the analytic account and define company A as parter
- With Company A, create an invoice and on the line use the other analytic account and confirm

Issue:
The distribution model for Company B will not be used and only the account distribution from the original invoice will be defined on the line

Cause:
In the _get_distribution method, the partner is incorrectly set to Company B, leading to this issue.

opw-4414850

Forward-Port-Of: odoo/enterprise#79366
Forward-Port-Of: odoo/enterprise#76395

### Issue: - Refused overtime in attendance, is not correctly excluded from work entries, for employees where the contract work entry resource is attendances. ### Steps To Reproduce: - Create a new employee with a 40h work schedule. - Create a new contract for the employee, and set the `Work Entry Source` to `Attendances` - Change the contract status to running. - Go to the attendance tab. - Create a new attendance for the employee. - Make sure the attendance interval includes some ove

### Issue:
- Refused overtime in attendance, is not correctly excluded from work entries, for employees where the contract work entry resource is attendances.

### Steps To Reproduce:
- Create a new employee with a 40h work schedule.
- Create a new contract for the employee, and set the `Work Entry Source` to `Attendances`
- Change the contract status to running.
- Go to the attendance tab.
- Create a new attendance for the employee.
- Make sure the attendance interval includes some overtime.
- Confirm the attendance.
- Refuse the overtime in the attendance.
- Go to work entries and regenerate new ones.
- Notice the work entry duration includes refused overtime.

### Solution:
- In `_get_attendance_intervals` we rely on the `check_out` date to determine the attendance interval. however this date coresponds to the end of the attendance including refused overtime.

- We modified the attendance `check_out` date to remove hours that are refused overtime.

opw-4571285

Forward-Port-Of: odoo/enterprise#80831

This commit upgrades the image upload endpoint to the one available in the v2 API. This is done because X is deprecating the old upload API endpoint. We also needed to update how the media id was fetched from the response as it changed between versions. task-4606722 Forward-Port-Of: odoo/enterprise#80232

This commit upgrades the image upload endpoint to the one available in the v2 API. This is done because X is deprecating the old upload API endpoint.

We also needed to update how the media id was fetched from the response as it changed between versions.

task-4606722

Forward-Port-Of: odoo/enterprise#80232

### Before Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services.  - Access to Codabox was limited to companies with an accounting firm with a VAT number assigned ### Now Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical  VAT numbers.   - Module summary, descriptions and ot

### Before

Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services. 
- Access to Codabox was limited to companies with an accounting firm with a VAT number assigned


### Now

Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical  VAT numbers.  

- Module summary, descriptions and other texts are updated to generalize 

- Companies without an accounting firm can access the Codabox configuration settings

task - 4460499

Forward-Port-Of: odoo/enterprise#80818
Forward-Port-Of: odoo/enterprise#77240

Steps to reproduce: 1. Open new table appointment form from the appointment app 2. Select a table ressource that is linked to a pos_config that has no current_session_id 3. Save Traceback is shown Fix: When notifying the tables of the appointment update the wrong session object was used. This commit ensure that the correct object is used in order to notify the sessions linked to the reserved tables Forward-Port-Of: odoo/enterprise#80889

Steps to reproduce:
1. Open new table appointment form from the appointment app
2. Select a table ressource that is linked to a pos_config that has no current_session_id
3. Save

Traceback is shown

Fix:
When notifying the tables of the appointment update the wrong session object was used. This commit ensure that the correct object is used in order to notify the sessions linked to the reserved tables

Forward-Port-Of: odoo/enterprise#80889

Forward-Port-Of: odoo/enterprise#80854

Forward-Port-Of: odoo/enterprise#80854

Before this commit, the `helpdesk_pick_template_as_message_from_knowledge` tour fails in no demo because the admin user is not named `Mitchell Admin` and so the step does not find the signature field. This commit adds the signature on the admin user to make sure the signature will be the same with demo data and without demo data. Forward-Port-Of: odoo/enterprise#80743

Before this commit, the `helpdesk_pick_template_as_message_from_knowledge` tour fails in no demo because the admin user is not named `Mitchell Admin` and so the step does not find the signature field.

This commit adds the signature on the admin user to make sure the
signature will be the same with demo data and without demo data.

Forward-Port-Of: odoo/enterprise#80743

Problem ---------- - Number field of HrPayslip model was removed, it makes crash the SHIF Report wizard - Demo data payslips doesn't contains NHIF or SHIF amount, it makes the SHIF report wizard add the payslip with an amount of 0. Objective ---------- - check if the SHIF/NHIF amount == 0 before add it in report entries. - recompute the demo data after the shif module installation Solution ---------- - replace payslip.number by payslip.name - add a condition on the SHIF/NHIF amoun

Problem
----------
- Number field of HrPayslip model was removed, it makes crash the SHIF Report wizard
- Demo data payslips doesn't contains NHIF or SHIF amount, it makes the SHIF report wizard add the payslip with an amount of 0.

Objective
----------
- check if the SHIF/NHIF amount == 0 before add it in report entries.
- recompute the demo data after the shif module installation

Solution
----------
- replace payslip.number by payslip.name
- add a condition on the SHIF/NHIF amount to add the payslip

task-4463586

Forward-Port-Of: odoo/enterprise#80455

In the external and internal layouts, some default variables are set conditionally (`o` in particular) This commit evaluates the content of the t-if expression to imitate what the real qweb does. Otherwise, the variable risks of being erased from the context of the node, which is necessary to add field on the right variable with the right type. opw-4592446 Forward-Port-Of: odoo/enterprise#80019

In the external and internal layouts, some default variables are set conditionally (`o` in particular) This commit evaluates the content of the t-if expression to imitate what the real qweb does. Otherwise, the variable risks of being erased from the context of the node, which is necessary to add field on the right variable with the right type.

opw-4592446

Forward-Port-Of: odoo/enterprise#80019

As a user I want to be able to choose if I want the frame or not, and as it's saved in a preference like way, I want to be able to disable the default frame if I enable it previously Steps: - Setup a signature image for your user - Open Sign - Upload a document and add Signature field - Sign the document - Open the Sign dialog - Check the "frame" option - Sign - Repeat the steps BUT uncheck frame option Actual result: - Signature frame is still there for the user - All signature

As a user I want to be able to choose if I want the frame or not, and as it's saved in a preference like way, I want to be able to disable the default frame if I enable it previously

Steps:
- Setup a signature image for your user
- Open Sign
- Upload a document and add Signature field
- Sign the document
- Open the Sign dialog
- Check the "frame" option
- Sign
- Repeat the steps BUT uncheck frame option

Actual result:
- Signature frame is still there for the user
- All signature have the frame by default

Expected result:
- If user sign without frame, this preferences is apply for next signature

opw-4610410

Forward-Port-Of: odoo/enterprise#80848