This update fixes issues in how automated tests are selected and run, including a typo and problems with file paths containing dots. It helps maintain stable quality checks and reduces the risk of incorrect test runs during development and releases.

Fix a typo introduce in previous changes
Backport a fix to restore test file behavior from 18.2
Fix test-file with dots in path

This change corrects how upgrade-related tests are matched so the right tests are selected during automated checks. It helps prevent missed or incorrectly selected upgrade tests, improving confidence in release validation without affecting end users.

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`

Opening the product catalog from a quotation no longer fails when a product has no category assigned. This helps sales users continue preparing quotations even when product data is incomplete.

Currently, an exception is raised when the user clicks on the catalog in a quotation if a product has no assigned category.

Steps to Reproduce:

1. Install the sale_management module.
2. Navigate to Sales -> Configuration -> Settings.
3. Enable the Pricelists.
4. Open a new Pricelists -> Add a Price Rules with Apply To `Category`, select a category, and save.
5. Go to Products -> Products.
6. Open an existing product and remove its product category.
7. Go to Sales -> Orders -> New Quotation.
8. Select the created Pricelists, and click on Catalog.
9. An error occurs.

Error:
`AttributeError
'bool' object has no attribute 'startswith'
`

This issue [1] occurs because when the user tries to access product category, the product category is not provided, as it is not a required field.

[1] -
https://github.com/odoo/odoo/blob/4bf8fc4c43ab7d8fd923aaaea8c6423c9a16e428/addons/product/models/product_pricelist_item.py#L481

This fix resolves the issue by ensuring that the product category exists before trying to access it.

sentry-6320016916

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

This fixes a Project app issue where a sub-task could incorrectly appear in a project's task board after being converted to a regular task and then back to a sub-task. Users now see task lists that correctly respect the option to show or hide sub-tasks.

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

Manual starts of Odoo no longer produce noisy zero and one entries from LED status updates. This keeps startup logs easier to read and helps teams spot real issues faster.

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#197768 Forward-Port-Of: odoo/odoo#197127

Forward-Port-Of: odoo/odoo#197768
Forward-Port-Of: odoo/odoo#197127

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

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

#### Description of the issue/feature this PR addresses: When updating an allocation's number_of_days, a validation check is performed to ensure that we do not reduce the `number_of_days` to be less than the number of leaves that are taken by the employee. However this logic also takes into consideration any virtual leaves (leaves that are in the `confirm` or `validate1` state, ie. leaves that are awaiting an approval) that may have been requested by an employee. These virtual leaves that ar

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

When updating an allocation's number_of_days, a validation check is performed to ensure that we do not reduce the `number_of_days` to be less than the number of leaves that are taken by the employee. However this logic also takes into consideration any virtual leaves (leaves that are in the `confirm` or `validate1` state, ie. leaves that are awaiting an approval)  that may have been requested by an employee. These virtual leaves that are not yet approved should not count towards the calculation since it could be possible that the employer could refuse them or the employee's accrual plan could grant sufficient leaves if it is requested for a future date.


#### Current behavior before PR:

1. Setup a timeoff type that requires approval from the manager
2. Set up an accrual plan where an employee accrues '_N_' days of leave at the start of each year with **no carryover** (NOTE: the no carryover is the most crucial step because this is what writes the number_of_days on the leave allocation to zero)
3. Request a leave by an employee for any date after the carryover period.

What should have happened: The accrual should reset the leaves based on no carryover policy back to _N_ days 
However, it throws a validation error:

Now the issue happens because when we see that the carryover is none because of which:
1. The allocated leaves are set to 0 when calling this CRON (for no carryover): https://github.com/odoo/odoo/blob/cf18c4ac88919513a9f2b922d625fa5dc113cb39/addons/hr_holidays/models/hr_leave_allocation.py#L527
2. The leave that was requested by the employee but not yet approved causes the validation to fail. It is best explained in the below screen recording which uses the test case mentioned in the commit:

https://github.com/user-attachments/assets/f8914bac-815d-48c9-b4b2-c132a2fccbdb

![image](https://github.com/user-attachments/assets/cc2e221d-a725-4e9e-aaee-a054f644dff6)
![image](https://github.com/user-attachments/assets/8522bc81-5416-4bf0-ac71-bea1d2a133b8)


#### Desired behavior after PR is merged:

Virtual Leaves that are not yet approved would not block us from updating the allocation's `number_of_days`

opw-4442471

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

Forward-Port-Of: odoo/odoo#200000
Forward-Port-Of: odoo/odoo#198382

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

- Introduced `ir.config_parameter` settings for product and customer limits in POS. - Refactored partner loading to use configurable customer limit. task-id: 4610131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199923

- Introduced `ir.config_parameter` settings for product and customer limits in POS.
- Refactored partner loading to use configurable customer limit.

task-id: 4610131




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

Forward-Port-Of: odoo/odoo#199923

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 you make a os order, close the session an then re-open it without going through the backend, the starting tracking number is related to the previous session. Steps to reproduce: ------------------- * Open pos shop * Make an order and pay it * Select **New order** * Close the session, do not go in the backend * Re-open the session > Observation: The tracking number is like `X03`. If we make an order, the tracking number will then be `(X+1)01`. Why the fix: ---------

Currently, when you make a os order, close the session an then re-open it without going through the backend, the starting tracking number is related to the previous session.

Steps to reproduce:
-------------------
* Open pos shop
* Make an order and pay it
* Select **New order**
* Close the session, do not go in the backend
* Re-open the session
> Observation: The tracking number is like `X03`. If we make an order,
the tracking number will then be `(X+1)01`.

Why the fix:
------------
When closing the register the current order is marked as cancelled and a reloading of the page is done. When reloading, the `onMounted` of the product screen is triggered which creates a new order.

We will condition the effect of the `onMounted` in a `useEffect` so that we don't create new orders when we are closing the session.

opw-4435140

Forward-Port-Of: odoo/odoo#194666

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

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

This commit completes the fix https://github.com/odoo/odoo/pull/197508. In this commit we make sure that the thread has the correct `can_react` value by also checking that the user has a valid portal_partner. Forward-Port-Of: odoo/odoo#200398

This commit completes the fix https://github.com/odoo/odoo/pull/197508.
In this commit we make sure that the thread has the correct `can_react` value by also checking that the user has a valid portal_partner.

Forward-Port-Of: odoo/odoo#200398

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

Prior to this commit, attempting to print a receipt for a paid order in the PoS restaurant with l10n_sa_pos installed resulted in an error. In later versions, the process would fail silently. This error occurred because the getReceiptHeaderData method in the PoS restaurant used ‘this.get_order()’ to retrieve the order, which is not applicable for paid orders. The order is now passed as an argument to the getReceiptHeaderData function, allowing it to be used when assigning the is_settlement fi

Prior to this commit, attempting to print a receipt for a paid order in the PoS restaurant with l10n_sa_pos installed resulted in an error. In later versions, the process would fail silently. This error occurred because the getReceiptHeaderData method in the PoS restaurant used ‘this.get_order()’ to retrieve the order, which is not applicable for paid orders.

The order is now passed as an argument to the getReceiptHeaderData function, allowing it to be used when assigning the is_settlement field.

This was actually resolved in PR: #145252 but was accidentally reverted during this PR: #142566

Current behavior before PR - 
In saas-17.4, we get a traceback for the is_settlement field
In 18.0+ it will silently fail

Desired behavior after PR:
Print the order

Steps to reproduce:
1.) Install
point_of_sale;
pos_restaurant;
l10n_sa_pos;
2.) This should have created a company 'SA Company' with the country code of 'SA', currency of 'SAR', country_id of Saudi Arabia. If not create one and activate it.
3.) Create a Restaurant point of sale shop
4.) Create a sale > validate so we had orders in the 'Paid' state
5.) Ensure no table is selected
6.) Navigate to orders > filter 'Paid'
7.) Select a paid order and 'Print Receipt'

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

Forward-Port-Of: odoo/odoo#200607

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

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

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

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

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

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

[task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#195607

[task-4421055](https://www.odoo.com/odoo/project.task/4421055)

Forward-Port-Of: odoo/odoo#195607

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

Previously: - Zero-priced combo products could always be sold on eCommerce. However, this shouldn't be allowed if `prevent_zero_price_sale` is enabled. - Zero-priced combo items couldn't be sold on eCommerce if `prevent_zero_price_sale` was enabled. However, this should always be allowed since only the price of the combo product matters (not its items). Forward-Port-Of: odoo/odoo#199755

Previously:
- Zero-priced combo products could always be sold on eCommerce. However, this shouldn't be allowed if `prevent_zero_price_sale` is enabled.
- Zero-priced combo items couldn't be sold on eCommerce if `prevent_zero_price_sale` was enabled. However, this should always be allowed since only the price of the combo product matters (not its items).

Forward-Port-Of: odoo/odoo#199755

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

Since 18.0, the name field of draft invoice is false instead of "/", this causes an issue in the name replace as we try to use the replace() method on a False boolean. Forward-Port-Of: odoo/enterprise#80922

Since 18.0, the name field of draft invoice is false instead of "/", this causes an issue in the name replace as we try to use the replace() method on a False boolean.

Forward-Port-Of: odoo/enterprise#80922

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

Outgoing emails now contain more message IDs in references to help thread formation. This is notably due to parent_id being the first thread message, hence often technical, and this cause issues in multi odoo communications. This increases a bit query counters when sending emails. Indeed when preparing outgoing emails we now have to search for messages, and check for subtype details, which means additional queries. See community PR for more details. Task-4559249 Forward-Port-Of: odoo/e

Outgoing emails now contain more message IDs in references to help thread formation. This is notably due to parent_id being the first thread message, hence often technical, and this cause issues in multi odoo communications.

This increases a bit query counters when sending emails. Indeed when preparing outgoing emails we now have to search for messages, and check for subtype details, which means additional queries.

See community PR for more details.

Task-4559249

Forward-Port-Of: odoo/enterprise#79364
Forward-Port-Of: odoo/enterprise#79048

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

- Adding 'Demo Mode' option in the DIAN settings section - Adding demo mode bypasses to the relevant methods to imitate recieving a positive response from DIAN without sending anything task-4087930 Forward-Port-Of: odoo/enterprise#79086

- Adding 'Demo Mode' option in the DIAN settings section
- Adding demo mode bypasses to the relevant methods to imitate recieving a
positive response from DIAN without sending anything

task-4087930

Forward-Port-Of: odoo/enterprise#79086

Overrides xml and xlsx export for Estonia intrastat because the current columns of the default intrastat report don't match with estonian government requirements. More information can be found at those addresses: - Arrivals: https://www.stat.ee/en/questionnaires/intrastat-arrivals-2024-month - Dispatches: https://www.stat.ee/en/questionnaires/intrastat-dispatches-2024-month task-3989930 Forward-Port-Of: odoo/enterprise#80917 Forward-Port-Of: odoo/enterprise#71114

Overrides xml and xlsx export for Estonia intrastat because the current columns of the default intrastat report don't match with estonian government requirements.

More information can be found at those addresses:
- Arrivals: https://www.stat.ee/en/questionnaires/intrastat-arrivals-2024-month
- Dispatches: https://www.stat.ee/en/questionnaires/intrastat-dispatches-2024-month

task-3989930

Forward-Port-Of: odoo/enterprise#80917
Forward-Port-Of: odoo/enterprise#71114

Versions: ----------- - 17.0 Steps to reproduce: ------------------------- - go to timesheet module - click on grid cell Issue: ------- The action helper in web grid was resulting in only the web content being displayed in the timesheet grid and so helper was missing Cause: --------- The action helper was being called from web_grid, causing a lack of content in the timesheet_grid. Solution: ----------- Create a dedicated function to retrieve the no-content helper, enhanc

Versions:
-----------
- 17.0

Steps to reproduce:
-------------------------
- go to timesheet module
- click on grid cell

Issue:
-------
The action helper in web grid was resulting in only the web content being
displayed in the timesheet grid and so helper was missing

Cause:
---------
The action helper was being called from web_grid, causing a lack of content in
the timesheet_grid.

Solution:
-----------
Create a dedicated function to retrieve the no-content helper, enhancing
portability for easy customization.

task-3429403

Forward-Port-Of: odoo/enterprise#80524
Forward-Port-Of: odoo/enterprise#56158

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

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

This commit improves the tool tip and the presentation of the quality control random view. When you set a quality point to "random" with a percentage of 20% and process a transfer of 100 units, it does not mean that exactly 20% of the transfer will be inspected. Instead, each unit has a 20% probability of being checked. For example, if you process ten transfers of 100 units each, you might get 18 quality checks in one transfer, 10 in another, 25 in the next, and so on. The key point is tha

This commit improves the tool tip and the presentation of the quality control random view.

When you set a quality point to "random" with a percentage of 20% and process a transfer of 100 units, it does not mean that exactly 20% of the transfer will be inspected. Instead, each unit has a 20% probability of being checked.

For example, if you process ten transfers of 100 units each, you might get 18 quality checks in one transfer, 10 in another, 25 in the next, and so on. The key point is that, statistically, approximately 20% of your total quantities will be inspected over multiple transfers.

opw-4527413

Forward-Port-Of: odoo/enterprise#80588
Forward-Port-Of: odoo/enterprise#80482

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

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

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

*l10n_nl_intrastat,l10n_nl_reports,l10n_nl_reports_sbr, l10n_nl_reports_sbr_icp,l10n_nl_reports_sbr_ob_nummer, l10n_nl_reports_sbr_status_info [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78111

*l10n_nl_intrastat,l10n_nl_reports,l10n_nl_reports_sbr, l10n_nl_reports_sbr_icp,l10n_nl_reports_sbr_ob_nummer, l10n_nl_reports_sbr_status_info

[task-4421055](https://www.odoo.com/odoo/project.task/4421055)

Forward-Port-Of: odoo/enterprise#78111

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

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