This update fixes and improves Odoo's internal HOOT testing tools, including better error handling, event simulation, storage mocks, and test search behavior. It helps developers catch issues more accurately and keeps automated tests stable without changing normal business workflows.

## Pull Request HOOT (PRHOOT) - part 19

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

Enterprise: https://github.com/odoo/enterprise/pull/65767

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

Fleet contract reminder calculations now skip contracts that do not have an expiration date. This prevents errors when checking reminder dates and helps ensure fleet contract alerts continue to work reliably.

_compute_contract_reminder is reading 'fleet.vehicle.log.contract' records with null expiration_date, later expiration_date is compared with a date without checking its validity. expiration_date can be null according to this:
https://github.com/odoo/odoo/blob/saas-17.2/addons/fleet/models/fleet_vehicle.py#L261

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

This fix ensures internal links work even when users click on text, icons, or other elements inside the link rather than the link itself. It improves navigation reliability in the web interface and prevents clicks from being ignored in common UI layouts.

Before this PR, a click on an internal link would not trigger the loadState if the click was not directly on the `a` element. This is because the children of `a` don't have a `href` element.

This PR fixes the issue by using the closest `a` as a reference for the `href`.

This change makes an internal web test more reliable by ensuring a dialog is fully shown before the test continues. It helps reduce random automated test failures, improving confidence in release checks without changing user-facing behavior.

runbot issue : 70187

This PR introduces a `l10n` test over the Balance Sheet reports. Each Balance Sheet report in the `LOC_DATA` global at the head of the file will be tested. The test generates a journal entry with a line in every account that is not `off_balance`. It then checks whether the Balance Sheet is balanced. The test does this both for debits and for credits. The test will give a warning for any installed Balance Sheet report which is not specified in the LOC_DATA global. The aim is to change th

This PR introduces a `l10n` test over the Balance Sheet reports.

Each Balance Sheet report in the `LOC_DATA` global at the head of the file will be tested.
The test generates a journal entry with a line in every account that is not `off_balance`.
It then checks whether the Balance Sheet is balanced.
The test does this both for debits and for credits.

The test will give a warning for any installed Balance Sheet report which is not specified in the LOC_DATA global. The aim is to change this to an error once all existing Balance Sheets are tested, to make this test mandatory for any new localizations.

For each localization with a Balance Sheet, the test needs to know the XMLIDs of:
- the CoA
- the Balance Sheet report
- the Total Assets line of the Balance Sheet
- the Total Liabilities line of the Balance Sheet
- the Total Equity line of the Balance Sheet (if applicable)

Setting the global `IDENTIFY_INCORRECT_ACCOUNTS` to `True` switches the behaviour of the test: it identifies the accounts that cause the imbalance using a binary search. This is off by default for runbot. 

**Performance impact**
- For each Balance Sheet, the test does the following:
     - load the chart template
     - create an account.move with 4 AMLs for each account (one debit and credit in the account; and one debit and credit in the counterpart account)
     - generate the report once.
- The Binary Search (which can be toggled when testing locally) is quite efficient: 
    - If there is just one incorrect account, then the report needs to be generated `log2(<number of accounts>)` times.
    - If there are `X` incorrect accounts, then in the worst-case the report may need to be generated `X * log2(<number of accounts>)` times.

On the Belgian CoA, with no incorrect accounts, the test takes 14s on my PC. With 4 incorrect accounts, the test takes 33s.

Task: 3060790

Forward-Port-Of: odoo/enterprise#65914
Forward-Port-Of: odoo/enterprise#36838

Steps to reproduce: - install timesheet module - install project_timesheet_forecast bridge module - open timesheets - click on all timesheets - search an employee name Issue: - employees that are not matching this search are still being displayed Cause: - the conditions that are in domain causes this issue Solution: - if we gave the condition in domain ,that the filter is based on related search then the issue will be solved task-3653034 Forward-Port-Of: odoo/enterprise#533

Steps to reproduce:
- install timesheet module
- install project_timesheet_forecast bridge module
- open timesheets
- click on all timesheets
- search an employee name

Issue:
-  employees that are not matching this search are still being displayed

Cause:
- the conditions that are in domain causes this issue

Solution:
- if we gave the condition in domain ,that the filter is based on related search then the issue will be solved

task-3653034

Forward-Port-Of: odoo/enterprise#53376

Versions -------- - 17.0 - saas-17.1 - saas-17.2 - saas-17.3 Steps ----- 1. Go to timesheets; 2. go to list view; 3. edit a timesheet line. Issue ----- `UncaughtPromiseError` Cause ----- Commit bae2e8146d48 added the `onRecordChanged` method, which fixed the issue of the timer not recording time spent on a project. The issue is that this method is also called when changing a row from the list view, and there's no `timesheet` value set by the timer, causing an error when

Versions
--------
- 17.0
- saas-17.1
- saas-17.2
- saas-17.3

Steps
-----
1. Go to timesheets;
2. go to list view;
3. edit a timesheet line.

Issue
-----
`UncaughtPromiseError`

Cause
-----
Commit bae2e8146d48 added the `onRecordChanged` method, which fixed the issue of the timer not recording time spent on a project.

The issue is that this method is also called when changing a row from the list view, and there's no `timesheet` value set by the timer, causing an error when trying to access `this.timesheet.resId`.

Solution
--------
Check `this.timerState.timesheetId` instead of `this.timesheet.resId`. `this.timerState` is guaranteed to exist, and its `timesheetId` value will be `undefined` if the timer isn't running, skipping the timer-specific logic.

Also handle default projects when set.

opw-4027099

Forward-Port-Of: odoo/enterprise#65879

Before, when creating an invoice for eu operations, lines without product were not accounted inside the ec sales report. Now when an invoice with lines without product happens, it will be displayed inside the ec sales report. This fix had to change the way the sbr icp export retrieved those values. Task: 3978307 Forward-Port-Of: odoo/enterprise#65455 Forward-Port-Of: odoo/enterprise#64265

Before, when creating an invoice for eu operations, lines without product were not accounted inside the ec sales report. Now when an invoice with lines without product happens, it will be displayed inside the ec sales report. This fix had to change the way the sbr icp export retrieved those values.

Task: 3978307

Forward-Port-Of: odoo/enterprise#65455
Forward-Port-Of: odoo/enterprise#64265

To reproduce the bug: - Have payroll and its l10n-au additional modules installed - Go to payroll -> config -> structure types - Change the first element 'Default Scheduled Pay' to semi-annually - Go to contacts and create click on New A python traceback will show. That's due to giving the PERIODS_PER_YEAR dictionary a non-existent key. As we can see, it lacks 'semi-monthly', 'bi-monthly', and 'semi-annually' periods. opw-4015682 Forward-Port-Of: odoo/enterprise#65618

To reproduce the bug:
- Have payroll and its l10n-au additional modules installed
- Go to payroll -> config -> structure types
- Change the first element 'Default Scheduled Pay' to semi-annually
- Go to contacts and create click on New

A python traceback will show. That's due to giving the PERIODS_PER_YEAR dictionary a non-existent key. As we can see, it lacks 'semi-monthly', 'bi-monthly', and 'semi-annually' periods.

opw-4015682

Forward-Port-Of: odoo/enterprise#65618

PR #62452 (15.0+) added extra IAP calls that retry requesting the cancellation status in case the cancellation was not processed yet. In odoo/odoo#122663 (17.0+), IAP calls were disabled in tests. When fw-porting the first PR above, this change of behaviour in 17.0 was not taken into account meaning that the tests kept failing in 17.0+. We fix this by applying the same strategy as #62452 - patch the thread to remove the testing attribute during IAP calls. runbot-64793 Forward-Port-O

PR #62452 (15.0+) added extra IAP calls that retry requesting the cancellation status in case the cancellation was not processed yet.

In odoo/odoo#122663 (17.0+), IAP calls were disabled in tests.

When fw-porting the first PR above, this change of behaviour in 17.0 was not taken into account meaning that the tests kept failing in 17.0+.

We fix this by applying the same strategy as #62452 - patch the thread to remove the testing attribute during IAP calls.

runbot-64793

Forward-Port-Of: odoo/enterprise#65867

Add a currency rates update method using the BCU (Banco Central Uruguayo) webservices for Uruguay (UY). Webservices used: - Get last currency rate update date https://cotizaciones.bcu.gub.uy/wscotizaciones/servlet/awsultimocierre - Get rates https://cotizaciones.bcu.gub.uy/wscotizaciones/servlet/awsbcucotizaciones Latest PDF specification [here](https://drive.google.com/file/d/122UtHhpdYEmbOti0nr0d-brZs65kiLDT/view) Rates can be manually verified [here](https://www.bcu.gub.uy/Esta

Add a currency rates update method using the BCU (Banco Central Uruguayo) webservices for Uruguay (UY).

Webservices used:
- Get last currency rate update date
  https://cotizaciones.bcu.gub.uy/wscotizaciones/servlet/awsultimocierre
- Get rates
  https://cotizaciones.bcu.gub.uy/wscotizaciones/servlet/awsbcucotizaciones

Latest PDF specification [here](https://drive.google.com/file/d/122UtHhpdYEmbOti0nr0d-brZs65kiLDT/view)
Rates can be manually verified [here](https://www.bcu.gub.uy/Estadisticas-e-Indicadores/Paginas/Cotizaciones.aspx)
For questions or updated specifcations, please send an email to mesadeayuda@bcu.gub.uy

*Note: the `CodigoISO` tag isn't a reliable ISO code, that's why we use their specific `Moneda` currency code instead.*

Credits to **Adhoc** for the development.

Original PR: odoo/enterprise#49519

Forward-Port-Of: odoo/enterprise#65169

To allow other localizations to use the same logic for negative lines, we moved the methods in account. We still extend it in the module to add specific logic about taxes and documents. task-3943357 Forward-Port-Of: odoo/enterprise#64379

To allow other localizations to use the same logic for negative lines, we moved the methods in account. 
We still extend it in the module to add specific logic about taxes and documents.

task-3943357

Forward-Port-Of: odoo/enterprise#64379

Versions -------- - 16.0+ Steps ----- 1. Create a rental product template; 2. add an attribute w/ 2 or more values; 3. go to "Rental prices" and add new pricings for specific variants; 4. copy the product template; 5. go to the "Rental prices" of the copied product. Issue ----- The pricings refer to the products variants of the original template instead of the newly created ones. Cause ----- Default copy logic doesn't link the new pricings to the new products. Solution -

Versions
--------
- 16.0+

Steps
-----
1. Create a rental product template;
2. add an attribute w/ 2 or more values;
3. go to "Rental prices" and add new pricings for specific variants;
4. copy the product template;
5. go to the "Rental prices" of the copied product.

Issue
-----
The pricings refer to the products variants of the original template instead of the newly created ones.

Cause
-----
Default copy logic doesn't link the new pricings to the new products.

Solution
--------
Add a `copy` override which creates new pricings for the proper variants.

opw-3878124

Forward-Port-Of: odoo/enterprise#65597
Forward-Port-Of: odoo/enterprise#63284

The issue: When there is a validation error happened directly with the DIAN, the error message is DIAN_RESULT, which does not explain much to the client. The Fix: explain to the client what is a DIAN_RESULT error opw-3921726 Forward-Port-Of: odoo/enterprise#65632 Forward-Port-Of: odoo/enterprise#65547

The issue:
When there is a validation error happened directly with the DIAN, the error message is DIAN_RESULT, which does not explain much to the client.

The Fix:
explain to the client what is a DIAN_RESULT error

opw-3921726

Forward-Port-Of: odoo/enterprise#65632
Forward-Port-Of: odoo/enterprise#65547

With https://github.com/odoo/enterprise/pull/45256/files we broke the left scroll bar of the transactions. Both sides of the bank rec widget should have their own. Before the fix:  After the fix:  opw-4029287 Forward-Port-Of: odoo/enterprise#65901

With https://github.com/odoo/enterprise/pull/45256/files we broke the left scroll bar of the transactions.
Both sides of the bank rec widget should have their own.

Before the fix:
![image](https://github.com/odoo/enterprise/assets/107402834/aab92304-d5b2-4a71-857e-5cf7c51d3aca)

After the fix:
![image](https://github.com/odoo/enterprise/assets/107402834/b2e699cd-e188-42b7-b5fc-34ebf79c0840)

opw-4029287

Forward-Port-Of: odoo/enterprise#65901

The module depends on documents_spreadsheet and crm in the manifest but contains references for [fields](https://github.com/odoo/enterprise/blob/a935055b1ea60b799e5c61c46a09231c4d210095/documents_spreadsheet_crm/data/files/pipeline_revenue_report_template.json#L280) defined in [crm_enterprise](https://github.com/odoo/enterprise/blob/a935055b1ea60b799e5c61c46a09231c4d210095/crm_enterprise/models/crm_lead.py#L10) and relies on the autoinstall of the enterprise module. The dependency should be expl

The module depends on documents_spreadsheet and crm in the manifest but contains references for [fields](https://github.com/odoo/enterprise/blob/a935055b1ea60b799e5c61c46a09231c4d210095/documents_spreadsheet_crm/data/files/pipeline_revenue_report_template.json#L280) defined in [crm_enterprise](https://github.com/odoo/enterprise/blob/a935055b1ea60b799e5c61c46a09231c4d210095/crm_enterprise/models/crm_lead.py#L10) and relies on the autoinstall of the enterprise module. The dependency should be explicit because crm_enterprise can be uninstalled by users and the documents would still be there with missing fields.

Forward-Port-Of: odoo/enterprise#64549

Problem --------- `_get_digital_signature` currently returns a sudo certificate. This is not safe. Objective --------- Don't return a sudo certificate to anyone having access to this company. Forward-Port-Of: odoo/enterprise#65874 Forward-Port-Of: odoo/enterprise#65607

Problem
---------
`_get_digital_signature` currently returns a sudo certificate. This is not safe.

Objective
---------
Don't return a sudo certificate to anyone having access to this company.

Forward-Port-Of: odoo/enterprise#65874
Forward-Port-Of: odoo/enterprise#65607

When creating a timesheet from the ticket view form, an access error is raised if the active company is different from the company of its project. Step to reproduce: - install helpdesk_sale_timesheet - open helpdek - open configuration menu -> helpdesk teams - select a team with the visibility set on 'invited portal users' - enable the 'billing' feature, and add a project on this team - select as active company any company other than the one set on the project selected before - select

When creating a timesheet from the ticket view form, an access error is raised if the active company is different from the company of its project.

Step to reproduce:
- install helpdesk_sale_timesheet
- open helpdek
- open configuration menu -> helpdesk teams
- select a team with the visibility set on 'invited portal users'
- enable the 'billing' feature, and add a project on this team
- select as active company any company other than the one set on the project selected before
- select an existing ticket, or create a new one on the team
- try creating a new timesheet Validation error is raised

Source of the issue:
If no company_id is given in the vals_list, the default company_id used by analytic line model is the active company. The issue is not present on task, because the key 'company_id' is correctly set in the '_timesheet_preprocess' method. This method is overwritten in the helpdesk_sale module and the updates done in it prevent the correct setting of the 'company_id' later on.

Solution:
Ensure that the 'company_id' key is present and consistent when creating a new timesheet from the ticket form view.

version: 16.0 - master

task - 3581941

Forward-Port-Of: odoo/enterprise#65575
Forward-Port-Of: odoo/enterprise#50150

The coverage reports do not print the right account ids when searching for the ones that are not used. ### Steps to reproduce: - Install the 'l10n_de' module and switch to a German company - Go in Accounting > Configuration > Management > Accounting Reports - Go in the German Profit and Loss report - Click on the button 'Accounts Coverage Report' - In the downloaded report the yellow lines should not appear as they are linked ### Cause: When searching for the ids that are not linked,

The coverage reports do not print the right account ids when searching for the ones that are not used.

### Steps to reproduce:
- Install the 'l10n_de' module and switch to a German company
- Go in Accounting > Configuration > Management > Accounting Reports
- Go in the German Profit and Loss report
- Click on the button 'Accounts Coverage Report'
- In the downloaded report the yellow lines should not appear as they are linked

### Cause:
When searching for the ids that are not linked, the code actually only look up the ones that are linked to an account.

### Solution:
Fix the condition on the ids.

opw-3993835

Forward-Port-Of: odoo/enterprise#65628

### Original issue: When creating a debit note on a bill from a purchase order with the option 'copy_lines', the field 'Purchase Order' in the lines is not populated. ### Steps to reproduce: - Install Purchase, Inventory apps and the l10n_co_edi module - Switch to a Colombian company - Go to Accounting > Configuration > Accounting > Journals - In the Vendor Bill journal > Advanced Settings, uncheck the 'Electronic invoicing UBL 2.1 (Colombia)' option - Go to Purchase > Orders > Purchase

### Original issue:
When creating a debit note on a bill from a purchase order with the option 'copy_lines', the field 'Purchase Order' in the lines is not populated.

### Steps to reproduce:
- Install Purchase, Inventory apps and the l10n_co_edi module
- Switch to a Colombian company
- Go to Accounting > Configuration > Accounting > Journals
- In the Vendor Bill journal > Advanced Settings, uncheck the 'Electronic invoicing UBL 2.1 (Colombia)' option
- Go to Purchase > Orders > Purchase Orders, create a new one and confirm it
- 'Receive Products' and 'Validate'
- Go back to the Purchase order
- 'Create Bill' and 'Confirm'
- From actions, choose 'Debit Note'
- In the wizard, tick 'Copy Lines', select a 'Concepto Nota de Débito' and 'Create Debit Note'
- Display the Purchase Order field in the Invoice Line tab is visible, it should not be populated

### Cause:
This bug is due to another fix that have been badly made because no tests were there. Most of the content of enterprise/l10n_co_edi/wizards/account_debit_note.py:_prepare_default_values is not called when it is supposed to and called when it's not. 

In the 'Create Debit Note' wizard view there is an option to copy the lines and so, autopopulate them. This option is not displayed for Debit Notes generated from Credit Notes because the lines would be negative. 
(https://github.com/odoo/odoo/blob/47eff65afdba3a2a8283342d8b636657f1fac317/addons/account_debit_note/wizard/account_debit_note_view.xml#L16) 

The logic of this option is located in the module account_debit_note: https://github.com/odoo/odoo/blob/2a02ba4de1c823bcdef0e8b6b6373fa27b5587a1/addons/account_debit_note/wizard/account_debit_note.py#L64, the line_ids value is filled with a default value if copy_lines is False. If left empty, the lines are copied from the original account.move. 

In this commit, https://github.com/odoo/enterprise/commit/c738f14d4ac88d508b6b75747788f5867eb71a68 we are trying to manually populate the lines of a debit note when it is generated from a credit note. But the code is made so that the lines are always copied. 

So in this other commit https://github.com/odoo/enterprise/commit/fa65a1ff8cb7333a3339438513d1eeb5d5f9690e there is a correction to take the copy_lines into consideration. But it breaks the precedent fix as Debit Notes of Credit Notes always have copy_lines to False. So the code to copy the lines manually is actually never called for Debit Notes of Credit Notes (which is the only case we want it to be called in). But is called every time copy_lines is set to True therefore ignoring the actual code to copy the lines in the module account_debit_note. 

In the context of the bug of this PR, the problem comes from the manual copying of lines that is missing the value purchase_order_id.

### Solution:
Changing the logic of the _prepare_default_values function:
- if not a Colombian company or not a debit note of a credit note, stop here
       - we let the logic in account_debit_note copy the lines (or not) depending on copy_lines.
- if the debit note comes from a credit note, we copy the lines and return

With this flow, the lines will not be copied manually so the value purchase_order_id will be populated.

opw-3962301

Forward-Port-Of: odoo/enterprise#65528
Forward-Port-Of: odoo/enterprise#64689

When renting with deliveries, if it's about a kit with subkit and shared component, the return will not be correct To reproduce the issue: 1. In Settings, enable "Rental Transfers" 2. Create a kit K as follow: - K - C1 - C2 - C3 - C2 3. Confirm a rental with 1 x K Error: in the return, there are two lines for each C2, which makes sense since each line is linked to a different kit. However, the quantity on each line is incorrect: 2 instead of 1 When

When renting with deliveries, if it's about a kit with subkit and
shared component, the return will not be correct

To reproduce the issue:
1. In Settings, enable "Rental Transfers"
2. Create a kit K as follow:
   - K
     - C1
       - C2
       - C3
     - C2
3. Confirm a rental with 1 x K

Error: in the return, there are two lines for each C2, which makes
sense since each line is linked to a different kit. However, the
quantity on each line is incorrect: 2 instead of 1

When generating the SM of the return, we first generate the values
https://github.com/odoo/odoo/blob/8db471e74238481a5429f0fcf8fbce1c0960ff27/addons/stock/models/stock_rule.py#L205-L206
In `_push_prepare_move_copy_values`, at some point, we adapt the
quantity of the returned SM based on the other SM of the SO. To do
so, we only consider the SM with the same product (among other
conditions). This criterion is not strict enough: for instance, when
looking at C2 of K, we take its quantity *and* we also take C2 of C1,
which is incorrect. Of course, we do the same when looking at C2 of
C1, hence the incorrect quantities.

OPW-3996074

Forward-Port-Of: odoo/enterprise#65758

To reproduce the issue: 1. Go to the wire transfer provider and enable it 2. Make sure there is a “Pending Message", if not click “Reload Pending Message” 3. Create a quotation in USD 4. Send by Email 5. Preview 6. Accept & Sign 7. Pay Now 8. Select Wire Transfer and Pay The amount will show under communication with as EUR. To fix it, only show this when the SEPA provider is used. opw-4006206 PS: I targeted 17 because it's the closest stable release to odoo.com (where we ex

To reproduce the issue:

1. Go to the wire transfer provider and enable it
2. Make sure there is a “Pending Message", if not click “Reload Pending Message”
3. Create a quotation in USD
4. Send by Email
5. Preview
6. Accept & Sign
7. Pay Now
8. Select Wire Transfer and Pay

The amount will show under communication with as EUR.

To fix it, only show this when the SEPA provider is used.

opw-4006206

PS: I targeted 17 because it's the closest stable release to odoo.com (where we experience the issue). Seemingly no one else has run into this over the years so I didn't want to change previous versions needlessly.

Forward-Port-Of: odoo/enterprise#65291
Forward-Port-Of: odoo/enterprise#65256

Avoid the installation of Odoo windows version in unsafe places. Forward-Port-Of: odoo/odoo#170356

Avoid the installation of Odoo windows version in unsafe places.

Forward-Port-Of: odoo/odoo#170356

Versions -------- - saas-17.1+ Steps ----- 1. Have Appointments installed; 2. go to Appointments / Configuration / Resource Leaves; 3. create a new Resource Time Off; 4. use the daterange widget to select a start & end date. Issue ----- No matter which end date you select, it will be on the same day as the start date. Cause ----- Commit bc2ea5fb6d12dc3e6c09c36c7bdc48276fb7960a modified the `resource_calendar_leave_form` to use the `daterange` widget for the `date_from` & `dat

Versions
--------
- saas-17.1+

Steps
-----
1. Have Appointments installed;
2. go to Appointments / Configuration / Resource Leaves;
3. create a new Resource Time Off;
4. use the daterange widget to select a start & end date.

Issue
-----
No matter which end date you select, it will be on the same day as the start date.

Cause
-----
Commit bc2ea5fb6d12dc3e6c09c36c7bdc48276fb7960a modified the `resource_calendar_leave_form` to use the `daterange` widget for the `date_from` & `date_to` fields. As a consequence, selecting any `date_from` value triggers the `_compute_date_to` method, overriding the `date_to` field selected by the datepicker.

Solution
--------
If the leave has a `date_to` value, and it is valid (i.e. not earlier than `date_from`), don't recompute the value.

Also fixed an issue computing the `date_to` field by actually converting the `date_from` value to the user's tz:
- `user_tz.localize(date_from)` only adds `tzinfo`, it doesn't change the values from UTC.
- As a consequence, if `date_from` is '2024-05-01 23:00:00' with user tz Europe/Brussels, the compute method will set hh:mm:ss of `date_to` to '23:59:59', then convert it to UTC, so '21:59:59', which is before `date_from`, causing to a validation error.
- Instead, '2024-05-01 23:00:00' should first get converted to local time '2024-05-02 01:00:00', so that `date_to` gets set correctly to '2024-05-02 21:59:59' UTC.

opw-3910990

Forward-Port-Of: odoo/odoo#167024

Problem: Placeholders were added in 17.0 to be used when switching to Studio mode. However, this placeholder will appear on the printed report if the `res.partner` has no name. Creating a `Delivery Address` for a `res.partner` does not require a name due to its type. Purpose: Hide this placeholder in cases were `Delivery Address` record does not have a `name` set. Steps to Reproduce: 1) Enable `Signatures` for deliveries 2) Create a new `Delivery Address` with no `name` for an existing `

Problem: Placeholders were added in 17.0 to be used when switching to Studio mode. However, this placeholder will appear on the printed report if the `res.partner` has no name. Creating a `Delivery Address` for a `res.partner` does not require a name due to its type.

Purpose: Hide this placeholder in cases were `Delivery Address` record does not have a `name` set.

Steps to Reproduce:
1) Enable `Signatures` for deliveries
2) Create a new `Delivery Address` with no `name` for an existing `res.partner` record
3) Create a SO -> confirm -> sign delivery
4) Print `Delivery Slip`

opw-3988100

Forward-Port-Of: odoo/odoo#171305

Here the error was due to timezone differences, so a frozentime wouldn't act indifferent irrespective of timezone. Also the isCheck is required in tour because a default run function is generated for every tour step for the specific I changed it is click. It is currently not affecting the tour because the tour is run with no delay. task-4004285 Forward-Port-Of: odoo/odoo#170476

Here the error was due to timezone differences, so a frozentime wouldn't act indifferent irrespective of timezone. Also the isCheck is required in tour because a default run function is generated for every tour step for the specific I changed it is click. It is currently not affecting the tour because the tour is run with no delay.

task-4004285

Forward-Port-Of: odoo/odoo#170476

We should add the price_unit via a `t-out` attribute, using a condition inside, rather than trying to use `t-if`. This was missed in resolving fw-port issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171439 Forward-Port-Of: odoo/odoo#171041

We should add the price_unit via a `t-out` attribute, using a condition inside, rather than trying to use `t-if`. This was missed in resolving fw-port issues.


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

Forward-Port-Of: odoo/odoo#171439
Forward-Port-Of: odoo/odoo#171041

In commit [1], the `o-map-omit` SCSS function has been modified in order to fix the values of CSS variables that would have been wrongly set to `'True'` or `'False'`, instead of boolean `true` and `false`. However, the issue only happened in "website", so the code should not have been added in this function which is located in the "web" module, because it is really website-specific. This commit moves this fix in the website `o-map-force-nulls` function instead. [1]: https://github.com/odoo

In commit [1], the `o-map-omit` SCSS function has been modified in order to fix the values of CSS variables that would have been wrongly set to `'True'` or `'False'`, instead of boolean `true` and `false`. However, the issue only happened in "website", so the code should not have been added in this function which is located in the "web" module, because it is really website-specific.

This commit moves this fix in the website `o-map-force-nulls` function instead.

[1]: https://github.com/odoo/odoo/commit/e01b861b89546ab5d7b5ce8269b06e9b7a845835

Related to opw-3957157

Forward-Port-Of: odoo/odoo#171312

- Before Commit: Users were unable to filter moves specifically for debit notes. An `ir.act.window` access error prevented users with invoice access rights from creating debit notes. - After Commit: Users can now directly filter debit notes using the new Debit Note filter over Customer Invoices, Vendor Bills, Journal Entries & Journal items views. And resolved the `ir.act.window` access error by updating the method to retrieve the action dictionary appropriately. **task**-3992112 F

- Before Commit:
Users were unable to filter moves specifically for debit notes.
An `ir.act.window` access error prevented users with invoice access rights from
creating debit notes.

- After Commit:
Users can now directly filter debit notes using the new Debit Note filter over
Customer Invoices, Vendor Bills, Journal Entries & Journal items views.
And resolved the `ir.act.window` access error by updating the method to retrieve
the action dictionary appropriately.

**task**-3992112

Forward-Port-Of: odoo/odoo#169785

This error occurs when the user drag & drop the newly created calendar event and select ``This and Following events`` in ``Edit Recurrent event`` Steps to reproduce: - Install ``Calendar`` module - Create a new event from the Calendar view - Edit event -> Enable ``Recurrent`` - Now click on any day from ``Repeat on`` and remove the day which is selected by default (eg: if Tuesday is the default then select Monday and unselect Tuesday) - Save and Unarchive it and go back to the calend

This error occurs when the user drag & drop the newly created calendar event and select ``This and Following events`` in ``Edit Recurrent event``

Steps to reproduce:
- Install ``Calendar`` module
- Create a new event from the Calendar view
- Edit event -> Enable ``Recurrent``
- Now click on any day from ``Repeat on`` and remove the day which is selected by 
  default (eg: if Tuesday is the default then select Monday and unselect Tuesday)
- Save and Unarchive it and go back to the calendar view
- Now drag & drop the newly created event to anywhere and select 
  ``This and Following events`` in ``Edit Recurrent event``

Traceback: 
``ValueError: not enough values to unpack (expected 1, got 0)``

The error on line [1] occurs because ``recurrence_id`` is not found in ``self``. This issue stems from a change made in commit [2], where ``recurrency`` was set to ``True``. Consequently, when an event is archived, ``recurrency`` remains ``True``, but the event lacks a ``recurrence_id``. This absence of ``recurrence_id`` in ``self`` at line [1] triggers an error. However, before this commit, the expected behavior was that when an event is archived, ``recurrency`` should be set to ``False``.

This commit will fix the error by passing ``false`` for ``update_recurrence`` when ``recurrence_id`` is not present.

[1]: https://github.com/odoo/odoo/blob/d7cfef9c51461a595f3f46c7b91e5c56241d4af3/addons/calendar/models/calendar_event.py#L1196
[2]: https://github.com/odoo/odoo/commit/48e3f725a2506ca63336a131661542cacc6f1ab5

sentry-5462902179

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

Forward-Port-Of: odoo/odoo#169040

Before this PR, the live chat support page test was sometimes failing. This test ensures all the Odoo modules are successfully loaded on the support page. Until now, the test was waiting 1 second, which might be enough to load Odoo modules but not all the live chat assets. If the live chat assets are still loading when the browser instance is closed, the promise rejects and the test fails. This test now ensures all the live chat assets are loaded beforehand. This change is beneficial becau

Before this PR, the live chat support page test was sometimes failing. This test ensures all the Odoo modules are successfully loaded on the support page.

Until now, the test was waiting 1 second, which might be enough to load Odoo modules but not all the live chat assets. If the live chat assets are still loading when the browser instance is closed, the promise rejects and the test fails.

This test now ensures all the live chat assets are loaded beforehand. This change is beneficial because it also ensures that runtime assets such as translations, live chat CSS, or fonts are properly loaded as well.

This PR fixes this issue.

runbot-60514

Forward-Port-Of: odoo/odoo#171372

**Steps to reproduce:** - Install Invoicing - Go to "Settings / Technical / Email / Email Templates" - Open "Invoicing: Sending" - In "Email Configuration" tab, remove value of "To (Partners)" [partner_to] and add a placeholder for "To (Emails)" [email_to] For example: {{ object.partner_id.email }}) - Create an invoice and open "Send & Print" wizard **Issue:** Recipients field is empty. It should contain customer's email. Same issue with "Cc" [email_cc] field of email template. **Ca

**Steps to reproduce:**
- Install Invoicing
- Go to "Settings / Technical / Email / Email Templates"
- Open "Invoicing: Sending"
- In "Email Configuration" tab, remove value of "To (Partners)" [partner_to] and add a placeholder for "To (Emails)" [email_to] For example: {{ object.partner_id.email }})
- Create an invoice and open "Send & Print" wizard

**Issue:**
Recipients field is empty. It should contain customer's email.
Same issue with "Cc" [email_cc] field of email template.

**Cause:**
When generating the recipients of "Send & Print" wizard, the placeholder defined in email_to field of the email template is not evaluated.

opw-3999260




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

Forward-Port-Of: odoo/odoo#171485

This commit fixes two things: 1- Allow for importing V3.2.2 Factura-E. 2- While importing, if the customer doesn't exist in our database, we create it. The country and the VAT were never set correctly as the country code is in three letter format in the XML and two letter format in Odoo. task-4011534 Forward-Port-Of: odoo/odoo#170744

This commit fixes two things:
1- Allow for importing V3.2.2 Factura-E.
2- While importing, if the customer doesn't exist in our database, we create it. The country and the VAT were never set correctly as the country code is in three letter format in the XML and two letter format in Odoo.

task-4011534

Forward-Port-Of: odoo/odoo#170744

Following the changes introduced in https://github.com/odoo/odoo/commit/5a452e9baecb32d3a7de7b975841a1a981b20dcc, archived product template attribute values were not being loaded, leading to errors when loading paid orders. opw-4012873 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171427

Following the changes introduced in https://github.com/odoo/odoo/commit/5a452e9baecb32d3a7de7b975841a1a981b20dcc, archived product template attribute values were not being loaded, leading to errors when loading paid orders.

opw-4012873

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

Forward-Port-Of: odoo/odoo#171427

Problem: For an Italian public company, when sending an invoice there is no warning triggered when the field "Origin Document Type" is empty Steps to reproduce: - Install "Contacts" and "Accounting" apps - Create an Italian company and set its fiscal localization - Create a new Italian contact and fill out the "Destination Code" with a six-digit code - Create an invoice for this contact, in the "Electronic Invoicing" tab, leave the field "Origin Document Type" empty - Confirm the invoic

Problem:
For an Italian public company, when sending an invoice there is no warning triggered when the field "Origin Document Type" is empty

Steps to reproduce:
- Install "Contacts" and "Accounting" apps
- Create an Italian company and set its fiscal localization
- Create a new Italian contact and fill out the "Destination Code" with a six-digit code
- Create an invoice for this contact, in the "Electronic Invoicing" tab, leave the field "Origin Document Type" empty
- Confirm the invoice and click on "Send & Print", there is no warning saying that the field "Origin Document Type" must be filled out

Cause:
Errors in the conditions

Note:
Modification in the get_records_action because self.id returns an id of type NewId which raise an error (see below) in this fix workflow because it is called in an onchange function. self.ids[0] returns an id of type int

Error raised: TypeError: Object of type NewId is not JSON serializable

Steps to reproduce:
- Do the 4 first steps as above
- Create a second invoice with another customer which is not a public italian administration (can be from another country)
- Select the invoices and click on "Send & Print" in the "Actions" button

opw-3844664

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

Forward-Port-Of: odoo/odoo#162776

The German delivery slips only show the company address, not the actual delivery address. ### Steps to reproduce: - Install l10n_de and switch to a German company - Create a delivery address to a company - Create a new SO, select the company as the customer and validate - Go to the created Delivery order, the delivery address should be the one you created before - Validate and print the delivery slip ### Cause: The German document format is DIN 5008 and this format does not include t

The German delivery slips only show the company address, not the actual delivery address.

### Steps to reproduce:
- Install l10n_de and switch to a German company
- Create a delivery address to a company
- Create a new SO, select the company as the customer and validate
- Go to the created Delivery order, the delivery address should be the one you created before
- Validate and print the delivery slip

### Cause:
The German document format is DIN 5008 and this format does not include the delivery address on the slips.

### Solution:
Add the delivery address in the additional addresses that should be printed.

opw-3961185

Forward-Port-Of: odoo/odoo#170902

Previously, the end-time of 'date_to' for leave requests was consistently set to the end of the day (i.e., 23:59), which was only desirable for public holidays (ref.1). However, this caused undesired behavior in other modules, such as the appointment module. The behavior was tracked down to an onchnge method (ref.2) supposed to be triggered only if date_from has changed. What happend instead that both updates: updating date_from as well as date_to, triggered the onchange. With this comm

Previously, the end-time of 'date_to' for leave requests was consistently
set to the end of the day (i.e., 23:59), which was only desirable for
public holidays (ref.1). However, this caused undesired behavior in other
modules, such as the appointment module. The behavior was tracked down
to an onchnge method (ref.2) supposed to be triggered only if date_from
has changed. What happend instead that both updates:
updating date_from as well as date_to, triggered the onchange.

With this commit we modify the datetime_field, so it only triggers the
date_from update when the date_from has changed. So it would behave in the
following way:

1) date_from field has changed -> will trigger the onchange (setting date_to)
date_from: Monday 10:00 -> Monday 12:00
date_to:   Monday 18:00 -> Monday 20:00 (results in Monday **23:59**)
                                                           

2) date_from field hasn't changed (and date_to has changed)-> won't trigger the onchange
date_from: Monday 10:00 -> Monday 10:00
date_to:   Monday 18:00 -> Monday 20:00 (results in Monday **20:00**)

(ref.1)
[IMP] resource: compute date_to for better ux
https://github.com/odoo-dev/odoo/commit/e0f3dd9e01d91896f1c00fb5cb3ce5c821912d03
https://github.com/odoo/odoo/pull/115688

(ref.2)
ResourceCalendarLeaves._compute_date_to
https://github.com/odoo/odoo/blob/6ae13a697bfd685366d10aa763de1bd6f2bd3e43/addons/resource/models/resource_calendar_leaves.py#L53-L61

[Reproduce]
- Install appointment
- Create New Resource Time Off (Appointments/ Configuration/ Resource Leaves)
- change time of "End Date"
- BUG: time sets itself to 23:59

opw-3841275

Forward-Port-Of: odoo/odoo#160665

When exporting non-grouped records we include archived records in results, this commits makes grouped results consiste with that, i.e. now also grouped records will include archived results [Reproduce] - Install crm - Go to: crm app - Switch to List view - Remove all filters - Use filter "Lost" - Group by "Stage" - Select all and Export -> BUG: exported xlsx file is empty Note: Above we have a specyfic case, to generalize that steps we can say, that whenever we filter with "Los

When exporting non-grouped records we include archived records in results, this commits makes grouped results consiste with that, i.e. now also grouped records will include archived results

[Reproduce]
- Install crm
- Go to: crm app
	- Switch to List view
	- Remove all filters
	- Use filter "Lost"
	- Group by "Stage"
	- Select all and Export -> BUG: exported xlsx file is empty

Note: Above we have a specyfic case, to generalize that steps we can say, that whenever we filter with "Lost" and use whatever "group by" then export is empty

opw-3901258

Forward-Port-Of: odoo/odoo#169626
Forward-Port-Of: odoo/odoo#166097

## Steps to reproduce: - Install POS app - Change the warehouse to a 2-step delivery method - Create a sales order for a product and confirm - Ensure the product is reserved for the picking transfer **as** the issue doesn't exist (all transfers are successfully cancelled) if there are no products reserved - Go to POS and settle the sales order - The delivery transfer is cancelled but the picking transfer (with product reserved) is not cancelled. although all transfers should be cancelled i

## Steps to reproduce:
- Install POS app
- Change the warehouse to a 2-step delivery method
- Create a sales order for a product and confirm
- Ensure the product is reserved for the picking transfer **as** the issue doesn't exist (all transfers are successfully cancelled) if there are no products reserved
- Go to POS and settle the sales order
- The delivery transfer is cancelled but the picking transfer (with product reserved) is not cancelled. although all transfers should be cancelled if the order is fully delivered!

## Investigation:
- When the product is already reserved, the picking transfer is in the **Ready/assigned** state
- When updating the steps, the **Ready/assigned** state is not taken into consideration and so the picking transfer is not updated to be **cancelled**

opw-3474929

Forward-Port-Of: odoo/odoo#170190
Forward-Port-Of: odoo/odoo#164753

SDI does not accept negative lines. But people use it to define flat global discount. We reuse the logic from l10n_mx_edi, so we move it to account. It will now try to create a flat discount for other lines that have the same tax. [Task link](https://www.odoo.com/odoo/project.task/3943357) task-3943357 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168939

SDI does not accept negative lines. But people use it to define flat global discount.
We reuse the logic from l10n_mx_edi, so we move it to account. 
It will now try to create a flat discount for other lines that have the same tax.

[Task link](https://www.odoo.com/odoo/project.task/3943357)
task-3943357



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

Forward-Port-Of: odoo/odoo#168939

To reproduce: ============= - share a project with a portal user - connect as the portal user - on a task paste an image in the description - save -> AccessError Problem: ======== Portal user doesn't have the right to create attachments Solution: ========= - when saving the record, editor tries to save the image as an attachment by `POST` request on the route `/web_editor/attachment/add_image` - `/web_editor/attachment/add_image` is not dedicated to portal user, so the save met

To reproduce:
=============
- share a project with a portal user
- connect as the portal user
- on a task paste an image in the description
- save -> AccessError

Problem:
========
Portal user doesn't have the right to create attachments

Solution:
=========
- when saving the record, editor tries to save the image as an attachment by `POST` request on the route `/web_editor/attachment/add_image`

- `/web_editor/attachment/add_image` is not dedicated to portal user, so the save method is patched to modify the route to custom one `/project_sharing/attachment/add_image`

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

Forward-Port-Of: odoo/odoo#170497

When the grid mode was added in commit [1], the "Padding" grid option was impacting all the grid items at the same time. This was not looking good in the "Masonry" snippet, because the images would have the same padding as the text grid items, while it would look better if they could take the whole space. The padding was therefore forced to 0 px for this snippet images (see commit [2]), preventing this option from having an impact on them. However, the "Padding" option was improved in commit

When the grid mode was added in commit [1], the "Padding" grid option was impacting all the grid items at the same time. This was not looking good in the "Masonry" snippet, because the images would have the same padding as the text grid items, while it would look better if they could take the whole space. The padding was therefore forced to 0 px for this snippet images (see commit [2]), preventing this option from having an impact on them.

However, the "Padding" option was improved in commit [3], allowing the padding to be set on the grid items individually. There is therefore no need to block this option for the "Masonry" images anymore.

This commit removes the CSS rules preventing the "Padding" option from being applied on "Masonry" images. Note that the default padding is still set to 0 px, as it looks better, but it can now be modified with the option. Also note that the CSS rule about not showing the padding highlights was not working, as it was forgotten and not adapted when doing commit [3].

[1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec
[2]: https://github.com/odoo/odoo/commit/85b352af319edec84407f2046cf795b4e5503460
[3]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712

task-3970022

Forward-Port-Of: odoo/odoo#168013

The `isVisible` function did not consider those as visible. This had the side effect that they would be removed when they were the only child of a link since we remove links that do not have visible content. Steps to reproduce: - Go to Email Templates in debug mode - Open the code view and add `<a href="#"><t t-out="object.name"></t></a>` - Save - Notice that the link and the t-out have been lost opw-3990415 Forward-Port-Of: odoo/odoo#171369 Forward-Port-Of: odoo/odoo#171212

The `isVisible` function did not consider those as visible. This had the side effect that they would be removed when they were the only child of a link since we remove links that do not have visible content.

Steps to reproduce:
- Go to Email Templates in debug mode
- Open the code view and add `<a href="#"><t t-out="object.name"></t></a>`
- Save
- Notice that the link and the t-out have been lost

opw-3990415

Forward-Port-Of: odoo/odoo#171369
Forward-Port-Of: odoo/odoo#171212

Current behavior: When the restaurant is closed and "Self Ordering" is set to "QR menu + ordering", we can't access the combo choices and product attributes. Same issue when "Self Ordering" is set to "QR menu" (restaurant can be opened or closed) Steps to reproduce: - Install "Point of Sale" app and "pos_restaurant" module - In the settings, set "Self Ordering" to "QR menu + Ordering" and save - Click on "Preview Web interface" - Click on the button to access the products - You can't se

Current behavior:
When the restaurant is closed and "Self Ordering" is set to "QR menu + ordering", we can't access the combo choices and product attributes. Same issue when "Self Ordering" is set to "QR menu" (restaurant can be opened or closed)

Steps to reproduce:
- Install "Point of Sale" app and "pos_restaurant" module
- In the settings, set "Self Ordering" to "QR menu + Ordering" and save
- Click on "Preview Web interface"
- Click on the button to access the products
- You can't see the attributes of a product or the possibilities of a combo when click on these products

Solution:
Allow to access the next steps for combo or product with attributes and remove button "Add to cart" if we shouldn't process a command

opw-3854839


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

Forward-Port-Of: odoo/odoo#171524
Forward-Port-Of: odoo/odoo#169817

### Steps to reproduce the issue: 1. Create two Sale Orders with Service Products based on Timesheets 2. Select both Sale Orders in the List view and click on "Create Invoices" 3. Uncheck "Consolidated Billing" and Create Draft Invoice 4. You only create one Invoice, doing the same steps with Storable Products creates two ### Explanation: `sale.order._create_invoices` can receive a `grouped` boolean argument that will determine whether to create one joint Invoice or multiple ones. Wh

### Steps to reproduce the issue:

1. Create two Sale Orders with Service Products based on Timesheets
2. Select both Sale Orders in the List view and click on "Create Invoices"
3. Uncheck "Consolidated Billing" and Create Draft Invoice
4. You only create one Invoice, doing the same steps with Storable Products creates two

### Explanation:

`sale.order._create_invoices` can receive a `grouped` boolean argument that will determine whether to create one joint Invoice or multiple ones. When a Service Product based on Timesheets is being evaluated to create an invoice, the call to `sale.order._create_invoices` is missing this `grouped` argument.

### Suggested fix:

Adding a `grouped` argument fixes the issue.

opw-3915213

Forward-Port-Of: odoo/odoo#171569
Forward-Port-Of: odoo/odoo#170584

Add a domain so deprecated accounts aren't suggested in expenses. task-3974053 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171557 Forward-Port-Of: odoo/odoo#168704

Add a domain so deprecated accounts aren't suggested in expenses.

task-3974053


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

Forward-Port-Of: odoo/odoo#171557
Forward-Port-Of: odoo/odoo#168704

Separate tax tags have been done to be able to differentiate taxes for ec sales report Task: 3978307 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170768 Forward-Port-Of: odoo/odoo#168729

Separate tax tags have been done to be able to differentiate taxes for ec sales report

Task: 3978307

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

Forward-Port-Of: odoo/odoo#170768
Forward-Port-Of: odoo/odoo#168729

**Steps to reproduce:** - Open "Configure Document Layout" in settings. - Add only an image in the company_details section. **Issue:** - The customer added only an image to company_details in their production version 15.2. However, after migrating to version 17, the image appears in company_details but does not show up in the document preview. In version 15.2, there were some changes to company details that caused this issue https://github.com/odoo/odoo/pull/122438. - Due to these chan

**Steps to reproduce:**
- Open "Configure Document Layout" in settings.
- Add only an image in the company_details section.

**Issue:**

- The customer added only an image to company_details in their production version 15.2. However, after migrating to version 17, the image appears in company_details but does not show up in the document preview. In version 15.2, there were some changes to company details that caused this issue https://github.com/odoo/odoo/pull/122438. 
- Due to these changes, company_details is processed with the html2plaintext() function, which removes all the tags from company_details and only links and text will remain.
- This function does not recognize the image element and removes it along with other elements. I have prepared a fix that recognizes the image element from company_details and prevents it from getting discarded.
- Video reference from RunBot version 17: https://drive.google.com/file/d/1Ml62xIV1mhwKwU8KRHdc-qfTFCZhEqY0/view?usp=sharing
- I have also added a test case for html2plaintext function in test_html2plaintext function by backporting this method from 
master.

OPW : [3945490](https://www.odoo.com/odoo/my-tasks/3945490?cids=2)

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

Forward-Port-Of: odoo/odoo#171440
Forward-Port-Of: odoo/odoo#169027

Versions -------- - 15.0 - 16.0 - 17.0 - saas-17.1 - saas-17.2 - saas-17.3 Issue ----- Commit 9426ee54b927 introduced the \uFEFF character to web_editor as a zero-width non-breaking whitespace. When this gets added to a HTML node, and processed for translation, it throws an "empty document" error. Cause ----- When passed to the `get_text_content` function, the call to `html.fromstring('\uFEFF').text_content()` throws an error. \uFEFF is not technically classified as whitespace

Versions
--------
- 15.0
- 16.0
- 17.0
- saas-17.1
- saas-17.2
- saas-17.3

Issue
-----
  Commit 9426ee54b927 introduced the \uFEFF character to web_editor as a zero-width non-breaking whitespace. When this gets added to a HTML node, and processed for translation, it throws an "empty document" error.

Cause
-----
When passed to the `get_text_content` function, the call to `html.fromstring('\uFEFF').text_content()` throws an error. \uFEFF is not technically classified as whitespace, so the `nonspace` function which attempts to prevent processing empty documents doesn't catch it.

Solution
--------
Instead of the `isspace` method, use a regex which matches on all whitespace as well as \uFEFF.

To be applied on stable versions while the origins of stray ZWNBSPs get tackled on master.

opw-3957259

Forward-Port-Of: odoo/odoo#171578
Forward-Port-Of: odoo/odoo#169122

The checksum flag does not exists in older Docker versions. Forward-Port-Of: odoo/odoo#171627

The checksum flag does not exists in older Docker versions.

Forward-Port-Of: odoo/odoo#171627

This commit addresses an issue where events removed due to changes in their recurrence rules from Google, and those cancelled separately on Google, could be attempted to be cancelled twice in Odoo. opw-3997021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171240

This commit addresses an issue where events removed due to changes in their recurrence rules from Google, and those cancelled separately on Google, could be attempted to be cancelled twice in Odoo.

opw-3997021

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

Forward-Port-Of: odoo/odoo#171240

Description of the issue/feature this PR addresses: ------------------- Auto-cancelling Time Offs when editing public holidays was added in Jun 2022 ([see PR](https://github.com/odoo/odoo/pull/81225)) , but the cancellation of Time Offs wasn't updated to also remove the link to timesheets. If the user attempts to manually delete a timesheet linked to a Time Off (`holiday_id`​ in `hr.leave`​), they will be asked to cancel the Time Off which by this point had already been auto-cancelled, and a

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

Auto-cancelling Time Offs when editing public holidays was added in Jun 2022 ([see PR](https://github.com/odoo/odoo/pull/81225)) , but the cancellation of Time Offs wasn't updated to also remove the link to timesheets. If the user attempts to manually delete a timesheet linked to a Time Off (`holiday_id`​ in `hr.leave`​), they will be asked to cancel the Time Off which by this point had already been auto-cancelled, and as long as the link exists (regardless of cancellation) the timesheet cannot be deleted from the user frontend.

This PR adds an override call to unlink the timesheets before the leave (the inital validated timeoff) is force canceled.

Current behavior before PR:
-------------------
Steps to reproduce:
1. Create and validate an arbitrary Time Off, checking that it also creates a timesheet entry.
2. Create a new public holiday spanning the entire duration of the Time Off created in (1)
3. Attempt to delete the timesheet entry created in (1), if it is not already deleted.

Although you will be asked to cancel the timeoff first, that is not possible because the timeoff will be auto-cancelled by this point, making the deletion of the timesheet impossible.

Desired behavior after PR is merged:
-------------------

At step 3, user should be able to delete the timesheet associated to the timeoff.

Task-3697074

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

Forward-Port-Of: odoo/odoo#168223
Forward-Port-Of: odoo/odoo#154321

This commit odoo/odoo@af46b928a18da8e6276c107c5ed07cfd9e87d1bf introduced a fix to ensure submenu pages uniqueness. An issue arises when manual submenu are created and don't have a view_id set. To avoid this issue, we now fallback on the initial page receives if no view is found. Forward-Port-Of: odoo/odoo#171556 Forward-Port-Of: odoo/odoo#171391

This commit odoo/odoo@af46b928a18da8e6276c107c5ed07cfd9e87d1bf introduced a fix to ensure submenu pages uniqueness.

An issue arises when manual submenu are created and don't have a view_id set. To avoid this issue, we now fallback on the initial page receives if no view is found.

Forward-Port-Of: odoo/odoo#171556
Forward-Port-Of: odoo/odoo#171391