`* = {'web', 'project', 'hr_timesheet', 'hr_holidays', 'hr_attendance', 
'analytic'}`

Before this Commit:
The Graph view was not adaptable to the use of widgets, leading to issues with
the representation of time. Specifically, hours were shown as float values in
the graph view. For example, 5 hours and 30 minutes were displayed as 5.50
instead of the more intuitive hh:mm format. Although widgets like "float_time"
or "timesheet_uom" were available to format these values, they were ineffective
in the Graph view due to the architecture parser's limitations. This caused
confusion for users trying to interpret the time accurately.

After this Commit:
The Graph view is now adaptable to the use of widgets. This means that when a
widget is applied to format a field's value, the value will be displayed in the
specified format. For example, hours can now be shown in the hh:mm format
instead of as a float. 

Widget `timesheet_uom` is used at places where the module is related/depended
on `hr_timesheet` otherwise `float_time`.

This improvement also ensures that the formatted values
are reflected in the Y-axis (Ticks/Intervals) of the Graph view, enhancing the
user's ability to interpret the data accurately.

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

Task-3861721

Forward-Port-Of: odoo/odoo#173726
Forward-Port-Of: odoo/odoo#164280

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, configure a separate discount account for invoices
- Create an invoice:
  * Customer: [any]
  * Currency: [a foreign currency] (e.g. EUR)
  * Invoice Lines: [Price: 100€ - Discount: 50%]
- Check the "Journal Items" tab => Amount in currency for the receivable account and the discount account should be 50. Debit and credit should be the corresponding amount in the currency of the company.
- Change the currency of the invoice to the currency of the company
- Save the invoice

**Issue:**
When the currency is changed, all the amounts in currency are simply converted to the currency of the company.
Upon save, the "payment_term" line is recomputed to match with the values on the invoice lines, resulting on an amount of $50 for amount in currency, debit and credit. Which is correct.
However, the recomputation doesn't occur for the discount lines, resulting to an incorrect discount amount.

**Solution:**
Recompute the discount lines if the currency rate is changed.

opw-3881661




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

Forward-Port-Of: odoo/odoo#173692

Issue:
======
We can update the content of the editable before we choose the theme
which results in unexpected behaviors.

Steps to reproduce the issue:
=============================
- Open the email marketing app
- In the browser dev tools, set a big network throttle
- Create a new mailing
- Write in the editable zone before the template selection has had a
  chance to appear
- Click on design tab in the sidebar
- Traceback

Spec:
=====
We should not be able to write in the editable zone before choosing a
template.

Solution:
=========
We add a new option `waitForSnippets` for the `wysiwyg` to force the
editable element as `contenteditable="false"` until the snippets are
loaded. Once the snippets are loaded we set `contenteditable="true"`
back again.

Note 1: Removing the line of `this._activatecontenteditable` from
`_onMouseDown` in `odooEditor` because it keeps setting the editable
element as `contenteditable="true"` everytime we click. The line can be
safely removed because it's a leftorver from when clicking on links
would set everything to `contenteditable=false` except the link itself,
then clicking somewhere else would reactivate it. (introduced here
https://github.com/odoo/odoo/commit/72dd8d6e3c95f614353b1e87322a67c877c255c7)
. When it was outside the condition, it was hard to guess that it was not
needed anymore when we removed that `contenteditable` hack for links.

Note 2: the `odoo-editor` div in website have `contenteditable=false`
so dropped snippets will not be editable too. We call
`activatecontenteditable` after the drop of the snippets.

task-3901534

Forward-Port-Of: odoo/odoo#173812
Forward-Port-Of: odoo/odoo#168008

Steps to reproduce:
-------------------
1. Create a new analytic plan and set it as the default analytic plan in Project settings (it must be different from the 'Projects' plan)
2. Create again a new analytic plan and set its parent to the one you have created in step 1.
3. Create a new analytic account linked to the plan you have just created in step 2.
4. Create a new project and a new task
5. Link the analytic account you have created in step 3. to the task
6. Create a new timesheet linked to the task
7. In Accounting > Analytic Items, the analytic account of the timesheet will not be reported in the plan you created in step 2.

Fix:
-------------------
The 'Projects' plan (the default one) represents the 'account_id' field of analytic.account.line, other plans have names with the following format: 'x_plan{plan.id}_id' (they are fields created on the fly).
When creating a timesheet we were always setting its account.analytic.account to the 'account_id' field by default and ignoring the other plans.
The fix we propose is to look at the top-level plan of the account.analytic.account of the timesheet being created or modified, and link it to the plan it belongs to.
Note that we keep the 'account_id' ('Projects' plan) updated even if the account does not belong to this plan because this field is used in other parts of the code.

Linked PR: https://github.com/odoo/odoo/pull/139225

task-3820916

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

Forward-Port-Of: odoo/odoo#162213

Issue:
===============
When a manufacturing order (MO) is created, the default components are 
automatically reserved and are made visible in the barcode module. However, 
even if these components are later unreserved, they will continue to be 
displayed in the barcode module.

Resolution:
================
To address this issue, we've taken the step to avoid forcefully re-reserving 
the components when a component is unreserved. This resolves the persistent 
display of components in the barcode.

Steps to Reproduce:
======================
1. Create a manufacturing order (MO) and confirm it.
2. Navigate to the barcode module within the manufacturing order.
3. By default, the components are reserved, so they are visible in the 
   barcode module.
4. Go to the form view of the MO in MRP and unreserve the components.
5. Check the barcode module again, and notice that the unreserved components 
   are still visible.

Expected Result:
==================
After implementing the solution, When we opens the MO in the barcode module 
only reserved components should be visible. When a component is unreserved, 
it should no longer be visible in the barcode module for manufacturing order.

task-3869731

Forward-Port-Of: odoo/enterprise#66448
Forward-Port-Of: odoo/enterprise#61827

## Pull Request HOOT (PRHOOT) - part 20

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869
Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019
Part 14: https://github.com/odoo/odoo/pull/158916
Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971
Part 15.5: https://github.com/odoo/odoo/pull/166463
Part 16: https://github.com/odoo/odoo/pull/166311
Part 17: https://github.com/odoo/odoo/pull/168328
Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657
Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767

Community: https://github.com/odoo/odoo/pull/173332

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

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

Forward-Port-Of: odoo/enterprise#66895

…invoices

Steps to Reproduce on Runbot:

1. Set up AvaTax in Accounting settings
2. Make sure that the “Use AvaTax API” field is checked for the fiscal position named “Automatic Tax Mapping (AvaTax)”
3. Go to “Tax Groups” and for the record called “Tax 15%”, add “Test” to the field called “Preceding Subtotal”
4. Go to the Product Category called “All” and choose any selection for the field called “AvaTax Category”
5. Make an invoice and add the fiscal position named “Automatic Tax Mapping (AvaTax)”
6. Save then print the invoice. Notice on the printed invoice that above the box called “Total”, the box called “Untaxed Amount” shows up with no tax box.
7. Uncheck the “Use AvaTax API” field for the fiscal position named “Automatic Tax Mapping (AvaTax)” (This step is basically the inverse of step 2)
8. Print the invoice again and notice this time that the box will instead be called “Test” (which we set in step 3) and that a box showing the tax amount will show up.

This commit fixes the issue so that the value in "Preceding subtotal" is shown for printed Avatax invoices too.

opw-4027280

Forward-Port-Of: odoo/enterprise#66932

`* = {'helpdesk', 'hr_payroll', 'planning', 'project_timesheet_forecast',
'project_timesheet_forecast_sale'}`

Before this Commit:
The Graph view was not adaptable to the use of widgets, leading to issues with
the representation of time. Specifically, hours were shown as float values in
the graph view. For example, 5 hours and 30 minutes were displayed as 5.50
instead of the more intuitive hh:mm format. Although widgets like "float_time"
or "timesheet_uom" were available to format these values, they were ineffective
in the Graph view due to the architecture parser's limitations. This caused
confusion for users trying to interpret the time accurately.

After this Commit:
The Graph view is now adaptable to the use of widgets. This means that when a widget is applied to format a field's value, the value will be displayed in the specified format. For example, hours can now be shown in the hh:mm format instead of as a float. 

Widget `timesheet_uom` is used at places where the module is related/depended
on `hr_timesheet` otherwise `float_time`.

This improvement also ensures that the formatted values are reflected in the Y-axis (Ticks/Intervals) of the Graph view, enhancing the user's ability to interpret the data accurately.

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

Task-3861721

Forward-Port-Of: odoo/enterprise#66944
Forward-Port-Of: odoo/enterprise#66050