**Step to reprocduce :**
1. Install sale_project module
2. Create a product
        - type: Service
        - Invoice policy: based on the milestones
        - Create on order: Project & Task.
3. Create a sale order with that product and add two SO lines with different descriptions.
4. Confirm the sale order.
5. Click on the Tasks smart button in the sale order to open the generated tasks.
6. From one of the tasks (e.g., m1)
7. Manually remove the existing milestone and sales order item from the task.
8. Then assign a different milestone (e.g., m2) to the task.
9. The sale order item set different (e.g., m1) instead of the newly set milestone.

**Issue:**

When a task has its `milestone_id` and `sale_line_id` manually cleared, and a new milestone
is later assigned, the task does not get the correct Sales Order Item.

**Cause:**
In the `_compute_sale_line` method, the logic priority the parent task and project when
computing the `sale_line_id`, and only uses the `milestone_id.sale_line_id` as a fallback.

https://github.com/odoo/odoo/blob/259f7eafb15882807640a00cf6939129f27c8fbb/addons/sale_project/models/project_task.py#L109-L113

**Solution :** 

To fix this `_compute_sale_line` method to priority the milestone's `sale_line_id` 
when a milestone is explicitly set. This ensures that if the task’s milestone 
changes, its sale line reflects the one from the milestone, even for subtasks.

opw-4701106

Forward-Port-Of: odoo/odoo#215213

- Open the Project app. The URL is `/odoo/project`;
- Open a project. For example, the project with ID 5. The URL is `/odoo/project/5/tasks`;
- Click on an embedded action. For example, 'Planning'. The URL  is `/odoo/project/5/tasks/5/action1574`;
- Switch to another embedded action. For exemple, `Timesheet`. The URL is `/odoo/project/5/tasks/5/project-timesheets`. Note that in this case, the last action of the URL has changed.

Reload the browser (F5).

When reloading the router and the action service will use the URL to reconstruct the breadcrumb. It will decompose the URL as follows:

- `/odoo/project` : The list of projects;
- `/odoo/project/5` : The form view of the project '5', this is a known limitation; this step was not included the initial flow;
- `/odoo/project/5/tasks`: The list of tasks of the project 5;
- `/odoo/project/5/tasks/5` : The form view of the task 5. This line is an error, the task 5 should not be included in the breadcrumb.
- `/odoo/project/5/tasks/5/project-timesheets` : The `Timesheet` embedded action.

The issue occurs because the 'active_id' of the 'Timesheet' embedded action is taken as a 'resId' for the action tasks, which add an error on the breadcrumb.

This commit, changes the behaviour to allways replace the last action with the embedded action. This behaviour is already done when changing of embedded action, but not for the first one.

If we take our example again :
- `/odoo/project`;
- `/odoo/project/5/tasks`;
- Click on an embedded action: `/odoo/project/5/action1574`;
- Switch to another embedded action: `/odoo/project/5/project-timesheets`

After reloading, the breadcrumb will be:
- `/odoo/project` : The list of projects;
- `/odoo/project/5` : The form view of the project '5';
- `/odoo/project/5/project-timesheets` : The `Timesheet` embedded action.

However, this commit causes a side effect. The list of tasks will no longer appear in the breadcrumb. Users can still access it via the Top Menu.

opw-4889557

Forward-Port-Of: odoo/odoo#219504
Forward-Port-Of: odoo/odoo#219404

In the following scenario, changes to the odoo.conf file could be lost:
1. A long-running process enters a `writable()` block (e.g. git checkout)
2. While it is still running, another process wants to update the conf file but gets blocked waiting for `writable()`. However it has already loaded the entire `odoo.conf` file into memory ready to write it back.
3. The first long running process now makes a change to the `odoo.conf` file. In the case of the checkout process, it is changing the `server_wide_modules` key.
4. The first process finishes and releases the `writable()` lock.
5. The second process now writes to the conf file, however it is using the now-stale version it held in memory from step 2.
6. The original changes to the conf file are lost.

The fundamental issue is that the `update_conf` function is loading the conf file into memory too early. To fix this, we aquire the `writable()` lock first, and then we can load the conf file knowing that it won't change until we are done.

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

Forward-Port-Of: odoo/odoo#220073
Forward-Port-Of: odoo/odoo#219928

Steps to reproduce the issue:

0. Set work_entry_source to "attendance" on the running contract 
   of the employee.
1. Create an attendance for yesterday 23:00:00 UTC to today 
   06:00:00 UTC.
2. Create an attendance today from 08:00:00 UTC to 16:00:00 UTC.

Current behavior before PR:
Odoo will create a conflicting work entry with the one created 
in step 1, because the logic recreates all work entries in a 
timeframe between the start date at 00:00:00 and end date at 
23:59:59. The first entry started before this timeframe, so the 
recreated work entry does not align with the existing one, 
causing a conflict.

Desired behavior after PR is merged:
The work entries now span a single day at a time. If an 
attendance starts at night and ends the next morning, two 
entries will be created: one from the start time to end of day, 
and another from the start of the next day to the end time.

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

Forward-Port-Of: odoo/enterprise#90588

**Steps to reproduce:**

- Install `sale_subscription`
- Create a recurring product (P1) and a non-recurring product (P2)
- Create a Sale Order (S1) with P1 (quantity > 0) and confirm it
- Create an upsell of S1 (new child order S2)
- In S2, edit the P1 line, and select P2
- Set quantity > 0 for P2
- Confirm S2

**Issue:**

After confirming the upsell order (S2), the quantity of P1 on the
original subscription (S1) is incorrectly increased by the quantity of
P2 from S2. The _compute_parent_line_id method did not reset the
parent_line_id when the product was not a subscription Product,
which caused it to incorrectly update the subscription

This issue is present in all three versions: **16.0, 17.0, and 18.0**.

**Solution:**

Reset parent_line_id to False if the product is not a subscription
product to prevent incorrect subscription updates.

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

Forward-Port-Of: odoo/enterprise#90848
Forward-Port-Of: odoo/enterprise#88282

Issue
=====
When a package is scanned as the destination package, if a source location was previously scanned, the source location will be updated for every product who will be packed.

How to reproduce
================
- Enable multi-locations and package;
- Create an empty package, two locations and two products;
- Create a delivery in the Barcode app;
- Scan the first location then the first product;
- Scan the second location then the second product;
- Scan the empty package -> The package is rightly assigned as the result package for both lines, but the source location of the first product was update for the last scanned source location.

Cause of the issue
==================
When a source location was previously scanned, when a line is updated (`updateLine`), we update the line's source location. Usually, that's the wanted behavior but in this case, we don't want to the source location of already processed lines when we scan a destination package.

Solution
========
When calling `updateLine` from `_assignEmptyPackage`, give a key in the parameters to not update the source location.

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

Forward-Port-Of: odoo/enterprise#90280
Forward-Port-Of: odoo/enterprise#89142

The system will crash when we receive nothing in `response` and also tryig to retrieve values from response.

**Error:-**
`TypeError: 'NoneType' object is not subscriptable`

**Root Cause:-**
- While we are in `EC Company`.
- When we click `Process Now` on the invoice. It will call `button_process_edi_web_services` method. And while in execution when at [1], `move.company_id._l10n_ec_is_demo_environment()` is `False`, then it calls `_l10n_ec_send_document` method.
- While submitting electronic invoices to SRI, the method `_l10n_ec_get_client_service_response_new()` sometimes returns `None` .
- It may also lack expected keys like 'estado' or 'comprobantes', depending on SRI’s behavior.

[1]
https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_ec_edi/models/account_edi_format.py#L425-L428

**Solution:-**
- Wrapped the access to response and its keys inside a `try...except` block that catches:- 
   - `TypeError`: for cases where the response is `None`.


**Sentry - 6708486009, 6728767866**

Forward-Port-Of: odoo/enterprise#88611

**Steps to reproduce**:
1. Install `l10n_cz` and `l10n_cz_reports_2025`.
2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and confirm the bill.
3. Go to Reporting → Tax Return → VAT Control Statement (CZ).
4. You will see the bill listed under section B2. Now export the XML.
5. In the exported XML, the field `dan_dppd` is present.

**Observations**:
When exporting XML from the VAT Control Statement report, the date field in the B2 section is incorrectly named `dan_dppd`.
According to the official CZ VAT Control Report documentation ([link](https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1#110009830_dppd)), As a result, when importing the generated XML into the CZ portal, the field appears blank because it is not recognized.

**Issue**:
The export template uses the incorrect tag `dan_dppd` instead of the correct `dppd` for the B2 section.

**Solution**:
The export template was updated to use `dppd` instead of `dan_dppd` in the B2 section, as per the official documentation.

opw-4868515

Forward-Port-Of: odoo/enterprise#90394

**Current Behavior:**

Manual discounts are not retained when adding optional products to the order.

**Steps to Reproduce:**

1) Install the sale_subscription module.
2) Create a subscription with a recurring plan.
3) Add a product to the Optional Products section. 
4) Manually set a discount on the optional product. 
5) Click on the Add to Order Lines (cart) button.
6) A new SOL is created.

**Issue:**

The newly created SOL does not retain the manually set discount.

**Cause:**

- When the user clicks the Add to Order Lines button, the `add_option_to_order` method is triggered.
This method creates a new sale order line (SOL) using values from `_get_values_to_add_to_order`.

- In the current implementation, this method is overridden for subscription orders to exclude the 
discount value from the returned data.

https://github.com/odoo/enterprise/blob/42d829ea6e6a98f251cfffc8fb67b5320a5ada12/sale_subscription/models/sale_order_option.py#L17-L21

- This forces a recomputation of the discount based on pricelist rules, 
which unintentionally removes any manually set discount.

**Solution:**

- Only remove the discount value from the returned data and trigger recomputation 
if there is no manual discount.

- This ensures that any user-defined discount is preserved when creating the order line.

opw-4840735

Forward-Port-Of: odoo/enterprise#90423
Forward-Port-Of: odoo/enterprise#89381

**Steps to reproduce:**

- Install `sale_subscription`
- Create a recurring product (P1) and a non-recurring product (P2)
- Create a Sale Order (S1) with P1 (quantity > 0) and confirm it
- Create an upsell of S1 (new child order S2)
- In S2, edit the P1 line, and select P2
- Set quantity > 0 for P2
- Confirm S2

**Issue:**

After confirming the upsell order (S2), the quantity of P1 on the
original subscription (S1) is incorrectly increased by the quantity of
P2 from S2. The _compute_parent_line_id method did not reset the
parent_line_id when the product was not a subscription Product,
which caused it to incorrectly update the subscription

This issue is present in all three versions: **16.0, 17.0, and 18.0**.

**Solution:**

Reset parent_line_id to False if the product is not a subscription
product to prevent incorrect subscription updates.

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

Forward-Port-Of: odoo/enterprise#90848
Forward-Port-Of: odoo/enterprise#88282

Steps to reproduce the issue:

0. Set work_entry_source to "attendance" on the running contract 
   of the employee.
1. Create an attendance for yesterday 23:00:00 UTC to today 
   06:00:00 UTC.
2. Create an attendance today from 08:00:00 UTC to 16:00:00 UTC.

Current behavior before PR:
Odoo will create a conflicting work entry with the one created 
in step 1, because the logic recreates all work entries in a 
timeframe between the start date at 00:00:00 and end date at 
23:59:59. The first entry started before this timeframe, so the 
recreated work entry does not align with the existing one, 
causing a conflict.

Desired behavior after PR is merged:
The work entries now span a single day at a time. If an 
attendance starts at night and ends the next morning, two 
entries will be created: one from the start time to end of day, 
and another from the start of the next day to the end time.

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

Forward-Port-Of: odoo/enterprise#90588

The system will crash when we receive nothing in `response` and also tryig to retrieve values from response.

**Error:-**
`TypeError: 'NoneType' object is not subscriptable`

**Root Cause:-**
- While we are in `EC Company`.
- When we click `Process Now` on the invoice. It will call `button_process_edi_web_services` method. And while in execution when at [1], `move.company_id._l10n_ec_is_demo_environment()` is `False`, then it calls `_l10n_ec_send_document` method.
- While submitting electronic invoices to SRI, the method `_l10n_ec_get_client_service_response_new()` sometimes returns `None` .
- It may also lack expected keys like 'estado' or 'comprobantes', depending on SRI’s behavior.

[1]
https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_ec_edi/models/account_edi_format.py#L425-L428

**Solution:-**
- Wrapped the access to response and its keys inside a `try...except` block that catches:- 
   - `TypeError`: for cases where the response is `None`.


**Sentry - 6708486009, 6728767866**

Forward-Port-Of: odoo/enterprise#88611

#### Issue:
This commit adds a missing account.return.type data in the Oman localization. This is related to the new Accounting Returns #81569

The l10n_om module did not include an account.return.type record, which prevents the "Returns" button (linked to the action_open_returns) from appearing in the Tax Report. As a result, users in Oman are unable to access the Tax Closing form.

Also the l10n_om is a community module, because of that, we need to add a new enterprise module to add the related data for the tax returns.

The visibility of the button is controlled by the following condition: [Code](https://github.com/odoo/enterprise/blob/f924f120cbd04002e21c78b081e1c8006b56a4b6/account_reports/models/account_report.py#L1776)

#### Affected Versions:
18.3 and later

#### Steps to reproduce:

1.Install the l10n_om module
2.Switch to the Oman company
3.Go to Accounting > Reporting > Tax Report
4.The "Returns" button is not visible

#### Expected behavior
The "Returns" button should be visible, allowing the user to generate the closing tax form.

#### Current behavior
The button is hidden due to missing account.return.type data in the Oman localization.

OPW-4943024

Steps to reproduce:
- Have the main company in USD
- Have 3 different currency rates in date 1, 2 and today
- Create a Vendor Bill in EUR in date 1
- Make Payment (EUR) in date 1, it should not have an associated move
- Create a Bank transaction, at date 2, matching the payment amount in EUR Bank Journal
- Make a batch payment including the created payment
- Open bank reconciliation of EUR Bank journal
- Select the transaction and the batch payment
- Validate

Issue: User Error will raise
```
The move (OTR/2017/00001) is not balanced.
The total of debits equals $ aaa and the total of credits equals $ bbb
You might want to specify a default account on journal "Bank other currency" to automatically balance each move.
```

This occurs because when retrieving the exchange rate values, amounts are converted using the payment values, computed at payment date. Later on, when we aggregate payment amounts, we convert manually the result without specifying a date, creating an issue in case the reconciliation date occurs after a rate change

Forward-Port-Of: odoo/enterprise#88299

**Steps to reproduce**:
1. Install `l10n_cz` and `l10n_cz_reports_2025`.
2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and confirm the bill.
3. Go to Reporting → Tax Return → VAT Control Statement (CZ).
4. You will see the bill listed under section B2. Now export the XML.
5. In the exported XML, the field `dan_dppd` is present.

**Observations**:
When exporting XML from the VAT Control Statement report, the date field in the B2 section is incorrectly named `dan_dppd`.
According to the official CZ VAT Control Report documentation ([link](https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1#110009830_dppd)), As a result, when importing the generated XML into the CZ portal, the field appears blank because it is not recognized.

**Issue**:
The export template uses the incorrect tag `dan_dppd` instead of the correct `dppd` for the B2 section.

**Solution**:
The export template was updated to use `dppd` instead of `dan_dppd` in the B2 section, as per the official documentation.

opw-4868515

Forward-Port-Of: odoo/enterprise#90394

**Steps to reproduce**:
1. Install `l10n_cz` and `l10n_cz_reports_2025`.
2. Create a vendor bill with a vendor whose place of supply is in-country, set the bill amount to more than 10,000, and confirm the bill.
3. Go to Reporting → Tax Return → VAT Control Statement (CZ).
4. You will see the bill listed under section B2. Now export the XML.
5. In the exported XML, the field `dan_dppd` is present.

**Observations**:
When exporting XML from the VAT Control Statement report, the date field in the B2 section is incorrectly named `dan_dppd`.
According to the official CZ VAT Control Report documentation ([link](https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1#110009830_dppd)), As a result, when importing the generated XML into the CZ portal, the field appears blank because it is not recognized.

**Issue**:
The export template uses the incorrect tag `dan_dppd` instead of the correct `dppd` for the B2 section.

**Solution**:
The export template was updated to use `dppd` instead of `dan_dppd` in the B2 section, as per the official documentation.

opw-4868515

Forward-Port-Of: odoo/enterprise#90394

Currently, an error occurs when rescheduling a task's date from the Gantt view.

**Steps to Reproduce:**

 - Install the `project_enterprise` module.
 - Go to `Settings` and enable `Task Dependencies`.
 - Go to `Projects`, create a `project`, and add `two tasks` (Task 1 and Task 2) under that project.
 - Open `Task 2` > `Blocked By`, click `Add a line`, and select `Task 1`.
 - Return to the `project's tasks`, switch to `Gantt View`, and choose `Auto-Reschedule (Keep Buffer)` as the 
   rescheduling method.
 - `Double-click` on any date in the unassigned block, select `Task 1`, and `drag it to next date`.

`TypeError: '>' not supported between instances of 'bool' and 'datetime.datetime'`

This error occurs when rescheduling a task to a forward date, and a dependent
task has no start date. When the parent task is rescheduled, the system
attempts to reschedule the dependent task as well, but since it has no
start date, an error occurs [1] due to condition at [3].

The same error occurs when rescheduling a task to a backward date, and a
depends on task has no deadline date. When the child task is rescheduled,
the system attempts to reschedule the parent task as well, but since it has no
deadline date, an error occurs [2] due to condition at [3].

**Steps to Reproduce for backward rescheduling:**
 - Follow the first 5 steps from the forward rescheduling steps.
  - Remove the Deadline from Task 1, if it has.
 - Double-click on any date in the unassigned block, select Task 2, and drag
   it to previous date.

This commit ensures that the incorrect condition is removed from [3]. Now,
it checks whether the record is a candidate for moving, and both forward
and backward rescheduling are handled safely.

[1]- https://github.com/odoo/enterprise/blob/aaad26c28fd4bc1e94e99717076ecbcf74f5f357/project_enterprise/models/project_task.py#L1209

[2]- https://github.com/odoo/enterprise/blob/8cc8443dc11c176b55f7eb3efa07db5edb7e6b0c/project_enterprise/models/project_task.py#L1221

[3]- https://github.com/odoo/enterprise/blob/302f1a5e82ffbf383d37f003820fe780654fae2f/project_enterprise/models/project_task.py#L1203

sentry-6738017612

Forward-Port-Of: odoo/enterprise#90025

**Steps to reproduce:**

1. Install l10n_it_edi module
2. Create an invoice where the product description includes a newline.
3. Make sure the invoice uses VAT tax.
3. Confirm the invoice.
4. Click on send
5. Only enable Send to Tax Agency.
6. Click "Send" again.
7. Go to the Attach files and download the attachment.
8. Check the `<Descrizione>` (description) in the XML file.

**Issue:**

The `<Descrizione>` field in the `<DettaglioLinee>` tag includes newline characters, which are not accepted by SDI portal.

**Causes:**

The line description is using '\n'.join(...), which results in actual newline characters in the XML.

https://github.com/odoo/odoo/blob/ca7de6b2fbe4626583b67a34d77bbb523d972f79/addons/account/models/account_move_line.py#L513

https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/l10n_it_edi/models/account_move.py#L316-L324

**Solution:**

To fix this, replace newline characters in the description with spaces and Strip leading/trailing whitespace. 
This ensures SDI receives a single-line <Descrizione>value.

**Before fix:** 
![image](https://github.com/user-attachments/assets/c69c0305-b48a-4cac-b290-cc7453ea2afa)

**After fix:** 
![image](https://github.com/user-attachments/assets/7fdd60fa-d46c-413c-9dbe-982cec4544cc)

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4808826)
opw-4808826

co-authored by: Raj Bhuva (bhra@odoo.com)

Steps to reproduce the issue:

0. Set work_entry_source to "attendance" on the running contract 
   of the employee.
1. Create an attendance for yesterday 23:00:00 UTC to today 
   06:00:00 UTC.
2. Create an attendance today from 08:00:00 UTC to 16:00:00 UTC.

Current behavior before PR:
Odoo will create a conflicting work entry with the one created 
in step 1, because the logic recreates all work entries in a 
timeframe between the start date at 00:00:00 and end date at 
23:59:59. The first entry started before this timeframe, so the 
recreated work entry does not align with the existing one, 
causing a conflict.

Desired behavior after PR is merged:
The work entries now span a single day at a time. If an 
attendance starts at night and ends the next morning, two 
entries will be created: one from the start time to end of day, 
and another from the start of the next day to the end time.

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

Forward-Port-Of: odoo/enterprise#90588

There is a bug, when portal user wants to access a article with visibility set to everyone through help page on the website, the portal user wouldn't be able to see anything by clicking on browse button, while if the portal users logs out and access the same page, they would be able to see the articles. The steps to reproduce:
1- Setup a database with helpdesk, website, and knowledge app installed.
2- On website app --> help --> Helpdesk Team, enable the knowledge checkbox.
3- Create an article and publish it on the website and set the visibility to everyone.
4- Login as an portal user.
5- Navigate to help page on the website. Click on Browse articles.
6- You can see the article is not shown here.
7- Logout from the portal user and repeat the step 5. You can now see the article.

In the current version, if the user is not logged in, they will access the article with visibility set to everyone, which is expected. This is done by returning [] in the _search_is_article_visible. Elsewise, if the user is an internal user, the member_domain and is_article_visible_by_everyone are checked to see if either user has access on the article or the article is visible by everyone. If the user is not an internal user (portal user), the article will be only accessed if they are a member of the article, without checking article's visibility, which causes the bug.

opw-4835998