This fix prevents errors when comparing units of measure that are missing expected hierarchy information. It helps keep unit-related operations stable instead of failing when incomplete data is encountered.

parent_path for self and/or other_uom might not exist. And split operation cannot performed on a null value.

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

Deferred report audit details now exclude invoice or bill lines that fall entirely within the selected report period, matching the behavior already used in report totals. This prevents extra lines from appearing in audits and helps finance teams review deferred amounts more reliably.

The `PreparationPrinterContent` test was checking if the preparation receipt was containing a specific string. But the check was performed on the `.render-container` which is generated for printing and erased just after. That was causing a random error in the test. Now we call internal `pos_store` method that generate the receipt content and we check if the string is present in the content. runbot error id: 114884 Forward-Port-Of: odoo/odoo#197212

The `PreparationPrinterContent` test was checking if the preparation receipt was containing a specific string. But the check was performed on the `.render-container` which is generated for printing and erased just after. That was causing a random error in the test.

Now we call internal `pos_store` method that generate the receipt content and we check if the string is present in the content.

runbot error id: 114884

Forward-Port-Of: odoo/odoo#197212

Before this commit, if a many2one field was loaded with its data, it would not get connected. For example, in the Chilean localization, the account_move is loaded when capturing an order, but it would not get linked, causing an error. opw-4479284 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196994 Forward-Port-Of: odoo/odoo#193616

Before this commit, if a many2one field was loaded with its data, it would not get connected. For example, in the Chilean localization, the account_move is loaded when capturing an order, but it would not get linked, causing an error.

opw-4479284

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

Forward-Port-Of: odoo/odoo#196994
Forward-Port-Of: odoo/odoo#193616

Bug === 1. Create a mailing for an event registration 2. Add that mailing to the template 3. Create a new mailing for "mailing list" => The "event registration" template is proposed and it should be. Since 5226dc972560870d03e7e4bc5a838f1951b90ac7 , we removed the JS form view, which added `mailingFilterTemplates: true` in the env. That environment variable was responsible for the HTML component to filter the templates based on the model. Task-4568452 Forward-Port-Of: odoo/odoo#197437

Bug
===
1. Create a mailing for an event registration
2. Add that mailing to the template
3. Create a new mailing for "mailing list" => The "event registration" template is proposed and it should be.

Since 5226dc972560870d03e7e4bc5a838f1951b90ac7 , we removed the JS form view, which added `mailingFilterTemplates: true` in the env. That environment variable was responsible for the HTML component to filter the templates based on the model.

Task-4568452

Forward-Port-Of: odoo/odoo#197437

--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197489

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

Forward-Port-Of: odoo/odoo#197489

Having no country on a portal user would cause attempting to edit personal information through the portal to have an internal server error. Added a check to country_id to ensure that the country_id is a numerical value before casting to an int to avoid this internal server error. opw-4309159 Forward-Port-Of: odoo/odoo#186374

Having no country on a portal user would cause attempting to edit personal information through the portal to have an internal server error.

Added a check to country_id to ensure that the country_id is a numerical value before casting to an int to avoid this internal server error.

opw-4309159

Forward-Port-Of: odoo/odoo#186374

**Issue** Recruitment-type surveys do not appear in the Participations section, even when participants have completed the survey. Steps to Reproduce: 1. Install hr_recruitment_survey module 2. Open the Surveys app. 3. Create a new survey or open an existing one. 4. Set the survey type to Recruitment. 5. Click on the Participations smart button. Expected behavior: Participants who completed the survey should be listed. Actual behavior: No participants are shown. **Root Cause**

**Issue**
Recruitment-type surveys do not appear in the Participations section, even when participants have completed the survey.

Steps to Reproduce:
1. Install hr_recruitment_survey module 
2. Open the Surveys app.
3. Create a new survey or open an existing one.
4. Set the survey type to Recruitment.
5. Click on the Participations smart button.

Expected behavior: Participants who completed the survey should be listed.
Actual behavior: No participants are shown.

**Root Cause**

https://github.com/odoo/odoo/blob/de935a1b3ad96e24b5fd1bd317c73c12e9b3a08f/addons/survey/models/survey_survey.py#L1090-L1096

Once the smart button is clicked, the action variable is populated through the following record

https://github.com/odoo/odoo/blob/de935a1b3ad96e24b5fd1bd317c73c12e9b3a08f/addons/survey/views/survey_user_views.xml#L153-L168

The record includes a domain filter that restricts the displayed results to specific survey types. Since "recruitment" is not listed among the accepted survey types, it fails the check and is excluded from the results.

**Fix**
Overriding the action_survey_user_input action template in XML to extend the domain was impractical because it replaced the existing domain rather than extending it. This prevented seamless integration with other modules, limiting flexibility. Instead, we opted to extend the domain within the action's returned values, ensuring better modularity and maintainability.

opw-4516112



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

Forward-Port-Of: odoo/odoo#196284

The installation of the demo data of module `industry_fsm_sale` module triggered the sending of an SMS. Now, the SMS API is unavailable during module installation. Forward-Port-Of: odoo/odoo#197495 Forward-Port-Of: odoo/odoo#196671

The installation of the demo data of module `industry_fsm_sale` module triggered the sending of an SMS.
Now, the SMS API is unavailable during module installation.

Forward-Port-Of: odoo/odoo#197495
Forward-Port-Of: odoo/odoo#196671

Publishing the combo demo data on eCommerce makes it easier to test the combo configurator. Forward-Port-Of: odoo/odoo#197501

Publishing the combo demo data on eCommerce makes it easier to test the combo configurator.

Forward-Port-Of: odoo/odoo#197501

https://github.com/odoo/odoo/pull/112800 added a fix to ignore planning done or cancelled workorders. However it introduced an issue where any unfinished workorders before the ignored workorder will also be ignored and cause a traceback in certain workflows. Steps to reproduce ----- 1. Create a manufacturing order, and add 2 workorders 2. Start and finish the 2nd workorder 3. Attempt to add a 3rd workorder 4. Traceback occurs ``` 'date_planned_start': min([workorder.leave_id.date_f

https://github.com/odoo/odoo/pull/112800 added a fix to ignore planning done or cancelled workorders. However it introduced an issue where any unfinished workorders before the ignored workorder will also be ignored and cause a traceback in certain workflows.

Steps to reproduce
-----
1. Create a manufacturing order, and add 2 workorders
2. Start and finish the 2nd workorder
3. Attempt to add a 3rd workorder
4. Traceback occurs
```
    'date_planned_start': min([workorder.leave_id.date_from for workorder in workorders]),
TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'
```

Cause
-----
This early continue added in https://github.com/odoo/odoo/pull/112800 is too eager: https://github.com/odoo/odoo/blob/f19b61b640c6623aad3269d8f0e515b5480e6880/addons/mrp/models/mrp_workorder.py#L525-L526
Although the specified workorder should be ignored, it could potentially have children (`workorder.blocked_by_workorder_ids`) that need to be planned.

Solution
-----
Remove the early continue and keep running `_plan_workorder` on the done/cancelled workorder. All of its children `workorder.blocked_by_workorder_ids` will be correctly planned in the recursive call, and the done/cancelled workorder will still be correctly ignored afterwards in this existing early return:
https://github.com/odoo/odoo/blob/f19b61b640c6623aad3269d8f0e515b5480e6880/addons/mrp/models/mrp_workorder.py#L529-L531
Also backport the fix from https://github.com/odoo/odoo/pull/123802 to handle the null `date_planned_finished` from the ignored workorder.

opw-4497704

Forward-Port-Of: odoo/odoo#197380
Forward-Port-Of: odoo/odoo#195910

[IMP] account: add vat to base document layout view When users try to "send and print" their very first invoice without having set their company first, the wizard will tell them to go fill some of that information first. That behaviour can be annoying (the back and forth before being able to "send and print"). We improve that behaviour by leveraging the fact that before the users can "send and print" their first invoice, there is already the base document layout wizard that asked them

[IMP] account: add vat to base document layout view

When users try to "send and print" their very first invoice without
having set their company first, the wizard will tell them to go fill
some of that information first. That behaviour can be annoying (the
back and forth before being able to "send and print").

We improve that behaviour by leveraging the fact that before the users
can "send and print" their first invoice, there is already the base
document layout wizard that asked them to fill up some information. We
simply add the company information that we need to be filled there
(`vat` and `account_number`). That way if the users correctly filled
what is suggested they avoid the back and forth.

In practice, we want to change this on the base document layout:
- Add the vat field
- Remove the invisible from account_number if qr_code is not selected

task-4486167

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

Forward-Port-Of: odoo/odoo#195815

**Problem**: When pasting text containing line breaks (`\n`), after executing `this.dependencies.dom.insert(modifiedTextFragment);`, the selection collapses to the end of the newly inserted content. At this step, `selection` becomes stale and needs to be updated. **Solution**: Update the selection after inserting the text node. **Steps to Reproduce**: 1. Copy text content with line breaks (`\n`). 2. Select some text in the editor. 3. Paste the copied text. 4. Traceback. opw-448125

**Problem**:
When pasting text containing line breaks (`\n`), after executing `this.dependencies.dom.insert(modifiedTextFragment);`, the selection collapses to the end of the newly inserted content. At this step, `selection` becomes stale and needs to be updated.

**Solution**:
Update the selection after inserting the text node.

**Steps to Reproduce**:
1. Copy text content with line breaks (`\n`).
2. Select some text in the editor.
3. Paste the copied text.
4. Traceback.

opw-4481257

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

Forward-Port-Of: odoo/odoo#196130

Problem with stock valuation rounding. Steps to reproduce: - Create a product with automated valuation in AVCO - Set the product cost to 16.83 - Update the quantity to 10 - Make a purchase order with this product: quantity 10 and unit price 20 - Receive the product - On the product, reduce the quantity to: 10 (-10), then 1 (-9), then 0 (-1) - Check the valuation, it will remain -0.05 with a quantity of 0 This commit improves the previous commit: 795ce67 by using float_compare to ch

Problem with stock valuation rounding.

Steps to reproduce:
- Create a product with automated valuation in AVCO
- Set the product cost to 16.83
- Update the quantity to 10
- Make a purchase order with this product: quantity 10 and unit price 20
- Receive the product
- On the product, reduce the quantity to: 10 (-10), then 1 (-9), then 0 (-1)
- Check the valuation, it will remain -0.05 with a quantity of 0

This commit improves the previous commit:
795ce67 by using float_compare to check if the rounding error should be considered a rounding issue.

opw-4387534

Forward-Port-Of: odoo/odoo#197499

Turns out it's used. To minimize the UI space, setting an activity type and user should be enough to "activate" the feature, no need to check a box. Note: removing the creation of activity at upload, this flow is supposed to work on alias upload (setting unavailable without alias defined). Task-4551761 Forward-Port-Of: odoo/enterprise#78681

Turns out it's used.

To minimize the UI space, setting an activity type and user
should be enough to "activate" the feature, no need to check a 
box.

Note: removing the creation of activity at upload, this flow
is supposed to work on alias upload (setting unavailable 
without alias defined).
 
Task-4551761

Forward-Port-Of: odoo/enterprise#78681

During this forward port the feature error_action was lost: https://github.com/odoo/enterprise/pull/79108 This commit aims to bring it back. Forward-Port-Of: odoo/enterprise#79230

During this forward port the feature error_action was lost: https://github.com/odoo/enterprise/pull/79108

This commit aims to bring it back.

Forward-Port-Of: odoo/enterprise#79230

See commit messages. Task-4510838 Forward-Port-Of: odoo/enterprise#77783

See commit messages.

Task-4510838

Forward-Port-Of: odoo/enterprise#77783

The idea is: 1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each time before the component should be re-rendered and the getter only returns the computed result. It was making the code very hard to work with and very unstable. 2. Move `MrpDisplaySearchModel` `recordCache.ids` into `MrpDisplay` `recordCacheIds`. Why ? Because this array is always used in `MrpD

The idea is:

1. Stop to do a lot of thing in the getter `relevantRecords` because all those operations are done every time this getter is called. To achieve that, relevant records are computed each time before the component should be re-rendered and the getter only returns the computed result. It was making the code very hard to work with and very unstable.

2. Move `MrpDisplaySearchModel` `recordCache.ids` into `MrpDisplay` `recordCacheIds`. Why ? Because this array is always used in `MrpDisplay` so it doesn't do a lot of sense to define it in `MrpDisplaySearchModel`. The only exception is in the `_notify` where the cache is invalidated (TODO: to check if it still relevant.) Also, instead of havin an object with one uniq key who refers to an array (`recordCache.ids`), it will now be an array directly.

3. Make `recordCacheIds` part of the `MrpDisplay` `state`. The purpose of this change is to refresh the app everytime the cache is modified.

Also, this commit fix an issue where the record cache wasn't correctly updated when the selected employee requieres a PIN code. The issue was the cache was invalided before the PIN code was validated, a lot of async methods weren't awaited and the dialog itself wasn't bound to a callback in a way to be able to invalidate cache at the right moment.

OPW-4256568

Forward-Port-Of: odoo/enterprise#77917
Forward-Port-Of: odoo/enterprise#74421

When the user tries to publish a job position on the job board monster, a traceback will appear. Steps to reproduce the error: - Install ``hr_recruitment_integration_monster`` module - Go to Recruitment > Applications > By Job Positions > Click on the dropdown menu of any job position > Configuration (Make sure that the job position is published on the website) - Add Salary Range > Publish on Job Board > Job Board: Monster.com > Post Traceback: ``` AttributeError: 'int' object h

When the user tries to publish a job position on the job board monster,
a traceback will appear.

Steps to reproduce the error:
- Install ``hr_recruitment_integration_monster`` module
- Go to Recruitment > Applications > By Job Positions >
  Click on the dropdown menu of any job position > Configuration
 (Make sure that the job position is published on the website)
- Add Salary Range > Publish on Job Board > Job Board: Monster.com > Post

Traceback:
```
AttributeError: 'int' object has no attribute 'monster_id'
```

https://github.com/odoo/enterprise/blob/245a38f320db56fd22d946471f626adf6cfeb397/hr_recruitment_integration_monster/wizard/hr_recruitment_post.py#L130-L146
Here, ``monster_time_unit`` is integer, it does not have ``monster_id`` attribute.

sentry-6027416420

Forward-Port-Of: odoo/enterprise#73055

When installing the module, do not assign new leave type to the default company, as in multi-company context that default company may not be a UAE based company, preventing users to see/select those new leave types. This commit force no company when creating those new leave types. opw-4353549 Forward-Port-Of: odoo/enterprise#78383

When installing the module, do not assign new leave type to the default company, as in multi-company context that default company may not be a UAE based company, preventing users to see/select those new leave types.

This commit force no company when creating those new leave types.

opw-4353549

Forward-Port-Of: odoo/enterprise#78383

Before this commit, the test was relying in "today's" date for creating the recurring invoices. Since the time period for generating them was too short, the expected deliveries were not being generated. After this commit, we give a fixed date to the start date of the subscriptions and then generate the recurring invoices with a time distance of a month, solving the issue. Issue-from: OPW-4166852 Related PR: odoo/enterprise#73397 Forward-Port-Of: odoo/enterprise#76336

Before this commit, the test was relying in "today's" date for creating the recurring invoices. Since the time period for generating them was too short, the expected deliveries were not being generated.

After this commit, we give a fixed date to the start date of the subscriptions and then generate the recurring invoices with a time distance of a month, solving the issue.

Issue-from: OPW-4166852
Related PR: odoo/enterprise#73397

Forward-Port-Of: odoo/enterprise#76336

Before this commit the class `TestMockedDeliveryUSPS` used `'standard', '-external'` which is the opposite of what it was supposed to do. As a result the tests were run during normal builds, and led to errors when the tests were run without demo data. This commit also removes the reference to demo data to make the tests more robust. Runbot Errors: + https://runbot.odoo.com/odoo/action-573/114550 + https://runbot.odoo.com/odoo/action-573/114551 + https://runbot.odoo.com/odoo/action-573/1

Before this commit the class `TestMockedDeliveryUSPS` used `'standard', '-external'` which is the opposite of what it was supposed to do. As a result the tests were run during normal builds, and led to errors when the tests were run without demo data.

This commit also removes the reference to demo data to make the tests more robust.

Runbot Errors:
+ https://runbot.odoo.com/odoo/action-573/114550
+ https://runbot.odoo.com/odoo/action-573/114551
+ https://runbot.odoo.com/odoo/action-573/114552

Forward-Port-Of: odoo/enterprise#78706

Currently a ``ParseError`` is arising when the user installs the ``hr_recruitment_integration_monster`` module after deleting all types from Employment Types. Steps to reproduce: --- - Install ``hr_contract`` module - Open ``Employment Types`` and delete all types - Now try to install the ``hr_recruitment_integration_monster`` module. Traceback: --- ``` ParseError: while parsing /home/odoo/src/enterprise/18.0/hr_recruitment_integration_monster/data/hr_contract_type_data.xml:8, somew

Currently a ``ParseError`` is arising when the user installs the ``hr_recruitment_integration_monster`` module after deleting all types from Employment Types.

Steps to reproduce:
---
- Install ``hr_contract`` module
- Open ``Employment Types`` and delete all types
- Now try to install the ``hr_recruitment_integration_monster`` module.

Traceback:
---
```
ParseError: while parsing /home/odoo/src/enterprise/18.0/hr_recruitment_integration_monster/data/hr_contract_type_data.xml:8, somewhere inside <record id="hr.contract_type_temporary" model="hr.contract.type">
            <field name="monster_id">2</field>
        </record>
 ```

This commit solves the above issue by using ``noupdate="1"`` and ``forcecreate="False"`` to bypass record creation if it violates checks.

sentry-5731062091

Forward-Port-Of: odoo/enterprise#76782