Steps to reproduce: - Employees > Configuration > Working schedules - Set your working schedule to have non round numbers (Not mandatory but makes the issue much easier to reproduce) - Timesheets > Edit to have the required hour total - Sometimes rounding errors will cause the formatting to change (Overtime of +0:00, display in red...) This issue is not deterministic but we currently use exact comparisons between floats to determine the formatting so it could happen anytime. The error mar

Steps to reproduce:
- Employees > Configuration > Working schedules
- Set your working schedule to have non round numbers (Not mandatory but makes the issue much easier to reproduce)
- Timesheets > Edit to have the required hour total
- Sometimes rounding errors will cause the formatting to change (Overtime of +0:00, display in red...)

This issue is not deterministic but we currently use exact comparisons between floats to determine the formatting so it could happen anytime. The error margin was chosen to be much lower than what a difference of 1min could cause (Since the rounding errors are in the vicinity of 1e-16).

opw-4123649

Forward-Port-Of: odoo/enterprise#69845

This commit adapts documents tests to changes made in https://github.com/odoo/odoo/pull/180776 Forward-Port-Of: odoo/enterprise#70795

This commit adapts documents tests to changes made in https://github.com/odoo/odoo/pull/180776

Forward-Port-Of: odoo/enterprise#70795

### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create a repair order and mark it as done. #### > If you go back to the product return, the stock move of the original return appears twice. ### Cause of the Issue: Clicking on t

### Steps to reproduce:

- Create a Helpdesk team with the options "Return" and "Repairs"
- Create a product, sell 1 unit and deliver it.
- Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket.
- Create a repair order and mark it as done.

#### > If you go back to the product return, the stock move of the original return appears twice.

### Cause of the Issue:

Clicking on the `End Repair` button of the repair will call the `action_repair_end` with a `default_picking_id` equal to the `picking_id` of the `repair.order` in the context. However, during this call a stock move groing from repair location to the repair location will be created and mark as done for the final product to be assocaited with the repair order:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L379-L382 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L417-L442 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L444-L449 Since no `picking_id` is specified in its `move_vals`, the default `picking_id` (that is the return) will be added to the vals of the create here:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/odoo/models.py#L4564 So that the newly created move will be linked to the return move even thought this makes no sense.

opw-4159779

Forward-Port-Of: odoo/enterprise#69936

Forward-Port-Of: odoo/enterprise#70715

Forward-Port-Of: odoo/enterprise#70715

When validation an order in a Chilean shop, the date is not show on the receipt. Steps to reproduce: ------------------- * Change the company for the Chilean one **CL Company** * Go to the **Point of sale** App * Open shop session * Make and order and validate it > Observation: The date is not reported on the receipt Why the fix: ------------ Commit https://github.com/odoo/enterprise/commit/1ce4eaa025426354c640e6e6c69269b1e6b2c7d1 moved the date on receipt in the header for the chi

When validation an order in a Chilean shop, the date is not show on the receipt.

Steps to reproduce:
-------------------
* Change the company for the Chilean one **CL Company**
* Go to the **Point of sale** App
* Open shop session
* Make and order and validate it
> Observation: The date is not reported on the receipt

Why the fix:
------------
Commit https://github.com/odoo/enterprise/commit/1ce4eaa025426354c640e6e6c69269b1e6b2c7d1 moved the date on receipt in the header for the chilean localization.

Header uses the data from `props.headerData`
https://github.com/odoo/odoo/blob/5f748c9d5731fe2e7e519ee9625da25e2bb219bc/addons/point_of_sale/static/src/app/navbar/cash_move_popup/cash_move_receipt/cash_move_receipt.xml#L6

The date field in `headerData` is computed in `getReceiptHeaderData` https://github.com/odoo/enterprise/blob/923dfe962b714797ee41e8f7beed2cb2d6df7048/l10n_cl_edi_pos/static/src/overrides/models/pos_store.js#L48

However, this commit https://github.com/odoo/odoo/commit/5cb7639160cef5401ada8cdde5a5522d8d29c9a9 removed the field `receiptDate` on the pos order. We thus use the same logic to set the date in `headerData`.

opw-4136943

Forward-Port-Of: odoo/enterprise#70131

### Steps to reproduce * install `l10n_th_reports` * create a Thai company and its branch * using the company selector, ensure the current company is the branch company, while selecting both parent and branch company * open the Thai Tax Report * attempt to export the "Sales Tax Report (xlsx)" You should be met with a traceback about a tax group External ID not being found ### Cause The system looks for an XML ID which is only present in the parent company, while using the branch

### Steps to reproduce

* install `l10n_th_reports`
* create a Thai company and its branch
* using the company selector, ensure the current company is the branch company, while selecting both parent and branch company
* open the Thai Tax Report
* attempt to export the "Sales Tax Report (xlsx)"

You should be met with a traceback about a tax group External ID not being found

### Cause

The system looks for an XML ID which is only present in the parent company, while using the branch company

opw-4181071

Forward-Port-Of: odoo/enterprise#70467

Currently, an error occurs when the system tries to access the attribute name 'account_fiscal_id' through 'company_id' [1] but it is not available in 'res_company' model. Step to produce: - Install the 'l10n_ke_edi_oscu_stock' module. - Create a product, Set a company as Kenya, Change a 'Product Type' storable to service or consumable. - Again change a 'Product Type' to a storable product. ```AttributeError: 'res.company' object has no attribute 'account_fiscal_id'``` Link [1]: ht

Currently, an error occurs when the system tries to access the attribute name 'account_fiscal_id' through 'company_id' [1] but it is not available in 'res_company' model.

Step to produce:

- Install the 'l10n_ke_edi_oscu_stock' module.
- Create a product, Set a company as Kenya, Change a 'Product Type'
storable to service or consumable.
- Again change a 'Product Type' to a storable product.

```AttributeError: 'res.company' object has no attribute 'account_fiscal_id'```

Link [1]: https://github.com/odoo/enterprise/blob/3f0113b0d95200466f51b9c1f75b58a3534fb34c/l10n_ke_edi_oscu_stock/models/product.py#L21-L22

To resolve this issue, Get a product country code from 'account_fiscal_country_id' instead of 'account_fiscal_id'

Sentry-5862212825

Forward-Port-Of: odoo/enterprise#70148

Before this commit, the "tour pointers" that indicated to users that they needed to scroll the "snippets modal" were misaligned. Their position did not account for the iframe offset of the modal. task-4072655 Forward-Port-Of: odoo/odoo#181146

Before this commit, the "tour pointers" that indicated to users that they needed to scroll the "snippets modal" were misaligned. Their position did not account for the iframe offset of the modal.

task-4072655

Forward-Port-Of: odoo/odoo#181146

Before this commit: - In the branch's TDS Entry wizard, In the journal field no journal is displayed. After this commit: - In the branch's TDS Entry wizard, In the journal field main company's journal should be displayed. - When a new branch is created, the TDS Journal from the main company should be automatically assigned to the branch. Task-4154543 Forward-Port-Of: odoo/odoo#178933

Before this commit:
- In the branch's TDS Entry wizard, In the journal field no journal is displayed.

After this commit:
- In the branch's TDS Entry wizard, In the journal field main company's journal should be displayed.
- When a new branch is created, the TDS Journal from the main company should be automatically assigned to the branch.

Task-4154543

Forward-Port-Of: odoo/odoo#178933

Previously, when SO confirmed the default project manager remain unset. This commit adapts the functionality of setting the project manager if the template is included otherwise the manager remains unset. task-3953729 Forward-Port-Of: odoo/odoo#181593

Previously, when SO confirmed the default project manager remain unset. This commit adapts the functionality of setting the project manager if the template is included otherwise the manager remains unset.

task-3953729

Forward-Port-Of: odoo/odoo#181593

In the multilevel dropdown, when the submenu dropdown is accessed within the parent dropdown, it closes the parent dropdown, making it inaccessible to the child dropdown menu. We don't want the BS dropdown to close when the sub dropdown is clicked Task-4037692 Forward-Port-Of: odoo/odoo#173269

In the multilevel dropdown, when the submenu dropdown is accessed within the parent dropdown, it closes the parent dropdown, making it inaccessible to the child dropdown menu.
We don't want the BS dropdown to close when the sub dropdown is clicked

Task-4037692

Forward-Port-Of: odoo/odoo#173269

Steps to reproduce: -go to shop -choose product which has multi option attribute -tick atleast one attribute -add to cart Issue: -multi option values are not visible in cart description in mobile view. Cause: -the issue caused due to use of d-none and d-md-block classes, due to this it will not show in small size devices. Fix: -replace d-none and d-md-block with empty string, so now the values will show for all devices. opw-3853263 --- I confirm I have signed the CLA a

Steps to reproduce:
-go to shop
-choose product which has multi option attribute
-tick atleast one attribute
-add to cart

Issue:
-multi option values are not visible in cart description in mobile view.

Cause:
-the issue caused due to use of d-none and d-md-block classes, due to this it
 will not show in small size devices.

Fix:
-replace d-none and d-md-block with empty string, so now the values will show for all
 devices.

opw-3853263

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

Forward-Port-Of: odoo/odoo#178308

Issue: ===== Written html code inside the forum post gets rendered in the readonly view. Steps to reproduce the issue: ============================= - Create a new forum post - Write `<p>abc</p>` - Save - The `p` element disappears (it got rendered, you can check it by inspecting the element). Origin of the issue and solution: ================================= Let's first name the `p` element added by the editor as `pe` to differenciate between them. The issue is divided

Issue:
=====
Written html code inside the forum post gets rendered in the readonly
view.

Steps to reproduce the issue:
=============================
- Create a new forum post
- Write `<p>abc</p>`
- Save
- The `p` element disappears (it got rendered, you can check it by
  inspecting the element).

Origin of the issue and solution:
=================================

Let's first name the `p` element added by the editor as `pe` to
differenciate between them.

The issue is divided into 2 subproblems:

- We need to save the correct value: currently if we have written in the
  editor `<p>abc</p>`, it will save the value `<pe><p>abc</p></pe>`
  which means that the two `p` element will be handled the same either
  both will appear as a string in the readonly view or will be rendered
  which is not right. To solve the issue, we need to override the
  `value` of the text area and not the html before the submit. By
  doing this the textarea.value will be equal to
  `<pe>&lt;p&gt;abcdef&lt;/p&gt;</pe>` which is the correct value.

- Now the second problem is when we edit the post , it will render again
  the `p` element that we wrote. The fetched template actually have the
  correct value inside the textarea, but seems like the browser when
  rendering it, it will convert the value to `<pe><p>abd</p></pe>` which
  is not right, and if we use textarea.html it will encode the `<pe>`
  element which is wrong too. To get the original value, we fetch if
  again and use it in the options of the wysiwyg.

  opw-4148163

Forward-Port-Of: odoo/odoo#181357
Forward-Port-Of: odoo/odoo#179854

Instead of only allowing selection by limited account type, the system allows selection by group. 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#181370 Forward-Port-Of: odoo/odoo#181327

Instead of only allowing selection by limited account type, the system allows selection by group.

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#181370
Forward-Port-Of: odoo/odoo#181327

This commit juste move the code from this PR https://github.com/odoo/odoo/pull/179107 from l10n_es_pos to l10n_es_edi_facturae. opw-4074779 Forward-Port-Of: odoo/odoo#181553

This commit juste move the code from this PR https://github.com/odoo/odoo/pull/179107
from l10n_es_pos to l10n_es_edi_facturae.

opw-4074779

Forward-Port-Of: odoo/odoo#181553

Current behaviour: --- When going to /customers or /partners and selecting a partner, in the References section, if the text is too long, the image will be taking the text height Expected behaviour: --- The image fits the width but not the height Steps to reproduce: --- 1. Go to Website 2. Go to /customers 3. Select a partner that has references 4. Open the editor (top left) 5. Add long text to one of the reference 6. The image will match the text height Cause of the issue:

Current behaviour:
---
When going to /customers or /partners and selecting a partner, 
in the References section, if the text is too long, the image will be taking the text height

Expected behaviour:
---
The image fits the width but not the height

Steps to reproduce:
---
1. Go to Website
2. Go to /customers
3. Select a partner that has references
4. Open the editor (top left)
5. Add long text to one of the reference
6. The image will match the text height

Cause of the issue:
---
Caused by: https://github.com/odoo/odoo/commit/1efdb96227dab8f1b3bcb8e8854dbad5dd874e69

Fix:
---
Removed h-100 and added w-100

opw-3970462

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

Forward-Port-Of: odoo/odoo#173363

In 17.0 the add a line of the res.partner.bank is no longer adding a line directly in the list view but opening a wizard. The xpath of the base_iban was no longer working like it should. task:4197710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180865

In 17.0 the add a line of the res.partner.bank is no longer adding a line directly in the list view but opening a wizard.
The xpath of the base_iban was no longer working like it should.

task:4197710




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

Forward-Port-Of: odoo/odoo#180865

Overriding the _compute_field_value in order to only prefetch the currently requested field. opw-4213262 Forward-Port-Of: odoo/odoo#181534

Overriding the _compute_field_value in order to only prefetch the currently requested field.

opw-4213262

Forward-Port-Of: odoo/odoo#181534

### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create a repair order and mark it as done. #### > If you go back to the product return, the stock move of the original return appears twice. ### Cause of the Issue: Clicking on t

### Steps to reproduce:

- Create a Helpdesk team with the options "Return" and "Repairs"
- Create a product, sell 1 unit and deliver it.
- Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket.
- Create a repair order and mark it as done.

#### > If you go back to the product return, the stock move of the original return appears twice.

### Cause of the Issue:

Clicking on the `End Repair` button of the repair will call the `action_repair_end` with a `default_picking_id` equal to the `picking_id` of the `repair.order` in the context. However, during this call a stock move groing from repair location to the repair location will be created and mark as done for the final product to be assocaited with the repair order:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L379-L382 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L417-L442 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L444-L449 Since no `picking_id` is specified in its `move_vals`, the default `picking_id` (that is the return) will be added to the vals of the create here:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/odoo/models.py#L4564 So that the newly created move will be linked to the return move even thought this makes no sense.

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

Forward-Port-Of: odoo/odoo#180008

Since https://github.com/odoo/odoo/pull/121963, there are tooltips on search panel items when the user hovers them. However, it is not very convenient since the user needs to hover precisely the span which contains the item name for the tooltip to pop up. This commit simply moves up the data-tooltip attribute in the elements hierarchy so that it will show for the whole button instead of only the title. This also fixes a bug with the tooltip position in the charts of account search panel as a sid

Since https://github.com/odoo/odoo/pull/121963, there are tooltips on search panel items when the user hovers them. However, it is not very convenient since the user needs to hover precisely the span which contains the item name for the tooltip to pop up. This commit simply moves up the data-tooltip attribute in the elements hierarchy so that it will show for the whole button instead of only the title. This also fixes a bug with the tooltip position in the charts of account search panel as a side effect.

task-3917084

Forward-Port-Of: odoo/odoo#180776

Before this commit, it was possible for the same order to be created multiple times if the order was sent to the server concurrently. While the order button has a guard to prevent duplicate clicks, the `sendDraftToServer` function can be called from different places, some of which lack this guard. For example, the `setTable` function triggers order syncing but does not have the duplicate protection. Steps to reproduce: 1. Create an order in a table 2. Block the internet connection to preven

Before this commit, it was possible for the same order to be created multiple times if the order was sent to the server concurrently. While the order button has a guard to prevent duplicate clicks, the `sendDraftToServer` function can be called from different places, some of which lack this guard. For example, the `setTable` function triggers order syncing but does not have the duplicate protection.

Steps to reproduce:
1. Create an order in a table
2. Block the internet connection to prevent the order from syncing
2. Go to the floor screen
3. Re-enable a slow internet connection
4. Quickly click on two different tables without orders

This behavior results in duplicate order creation.

Since it's not possible to enforce uniqueness on the server side via a constraint, this commit introduces a debouncing mechanism in the `_save_to_server` function. This ensures that an order cannot be sent to the server more than once concurrently, preventing duplicate creation.

opw-4136101

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

Forward-Port-Of: odoo/odoo#180278

Problem: When creating a sale order without selecting a partner or if the partner has no language set, the note field displays the default terms in English, regardless of the user's language. It should display the note in the current user's language instead. Steps to reproduce: - Add default terms and conditions in both English and Arabic. - Change the user language to Arabic. - Create a new quotation without selecting a partner. - The note is displayed in English, but it should be in Ar

Problem:
When creating a sale order without selecting a partner or if the partner has no language set, the note field displays the default terms in English, regardless of the user's language. It should display the note in the current user's language instead.

Steps to reproduce:
- Add default terms and conditions in both English and Arabic.
- Change the user language to Arabic.
- Create a new quotation without selecting a partner.
- The note is displayed in English, but it should be in Arabic as per the user’s language while no partner selected yet.

opw-4176183

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

Forward-Port-Of: odoo/odoo#181185

[Real Decreto-ley 4/2024] of June 26, 2024 introduces some changes to the tax rates to address the economic and social consequences arising from the conflicts in Ukraine and the Middle East. The VAT reductions of 5% (pasta and seed oils) and 0% (basic foodstuffs and olive oils) previously introduced will be increased to 7.5% and 2%, respectively, starting on October 1, 2024. The rates of the equivalence surcharge applicable to these products will increase from 0.6% and 0%, to 1% and 0.26%,

[Real Decreto-ley 4/2024] of June 26, 2024 introduces some changes to the tax rates to address the economic and social consequences arising from the conflicts in Ukraine and the Middle East.

The VAT reductions of 5% (pasta and seed oils) and 0% (basic foodstuffs and olive oils) previously introduced will be increased to 7.5% and 2%, respectively, starting on October 1, 2024.

The rates of the equivalence surcharge applicable to these products will increase from 0.6% and 0%, to 1% and 0.26%, respectively.

An upgrade script is provided that automatically disables the deprecated VAT of 5% and Rec. Eq. of 0.62% when upgrading the `l10n_es` module.

[Real Decreto-ley 4/2024]: https://www.boe.es/buscar/act.php?id=BOE-A-2024-12944

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

Related to https://github.com/odoo/enterprise/pull/69736

Forward-Port-Of: odoo/odoo#181236
Forward-Port-Of: odoo/odoo#179797