Starting from version 18.0, `check_access_rule()` is deprecated. This **PR** updates the code to use `check_access()` instead. Forward-Port-Of: odoo/odoo#214490

Starting from version 18.0, `check_access_rule()` is deprecated. This **PR** updates the code to use `check_access()` instead.

Forward-Port-Of: odoo/odoo#214490

In this PR, we fixed the creation of a new None stage each time when we move an application to the existing None stage (stage_id = false). ## Description of the issue/feature this PR addresses: In the Kanban view of the application dashboard, when a user moves an application to the "None" stage (which corresponds to stage_id = False) and refreshes the page, a new stage labeled "None" is incorrectly created. The issue arose from the way we were updating the many2one field for stage_id. Speci

In this PR, we fixed the creation of a new None stage each time when we move an application to the existing None stage (stage_id = false).

## Description of the issue/feature this PR addresses:
In the Kanban view of the application dashboard, when a user moves an application to the "None" stage (which corresponds to stage_id = False) and refreshes the page, a new stage labeled "None" is incorrectly created.
The issue arose from the way we were updating the many2one field for stage_id. Specifically, we were setting the value as:
`{ id: false, display_name: "None" }`

This object was interpreted by the model layer as an instruction to create a new related record (i.e., a new stage) with the name "None", which is unintended.

## Fix:
We adjusted the logic so that if the targetGroup.value is falsy (i.e., null, undefined, or false), we now explicitly pass false instead of constructing an object. This correctly unsets the many2one field without triggering record creation.
This ensures:
- If a valid stage is selected, we pass the appropriate { id, display_name } object.
- If "None" is selected, we pass false to unset the stage_id, avoiding the creation of a phantom stage.

Current behavior before PR:
![screen-capture](https://github.com/user-attachments/assets/b6463875-c274-429d-9a2b-6a044946d9ef)


Desired behavior after PR is merged:
![chrome-capture-2025-6-17](https://github.com/user-attachments/assets/f4cb13bf-5f15-4b3e-908b-7732dad525f2)

 Task: 4873853

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

Forward-Port-Of: odoo/odoo#214605

## Version 18.0+ ## Issue Carousel images are not zoomable on product's website view ## Steps to reproduce - Select any product and move to `Sales` tab: - Add 1 image under `ECOMMERCE MEDIA` section. - Click `Go to website` and open edit mode: - Select the main image in the view; - In the editor, change the `Image Zoom` value for `Pop-up on Click`; - Save and close the editor. - Click on the main image to display the carousel: - Hover the current image and t

## Version
18.0+

## Issue
Carousel images are not zoomable on product's website view

## Steps to reproduce
- Select any product and move to `Sales` tab:
  - Add 1 image under `ECOMMERCE MEDIA` section.
  - Click `Go to website` and open edit mode:
    - Select the main image in the view;
    - In the editor, change the `Image Zoom` value for `Pop-up on Click`;
    - Save and close the editor.
  - Click on the main image to display the carousel:
    - Hover the current image and try to zoom in or out *(using the mouse wheel or equivalent action on trackpad)*

opw-4831912

Forward-Port-Of: odoo/odoo#213933

This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. To do so, the test listens on the connection with a selector. However, the loop condition is incorrect and exits after the first select timeout. As a result, if the test takes more than 5 seconds, it fails. This commit fixes the loop condition to continue until the stop event is set. runbot-116746,161035,223589,7747

This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch.

To do so, the test listens on the connection with a selector. However, the loop condition is incorrect and exits after the first select timeout. As a result, if the test takes more than 5 seconds, it fails. This commit fixes the loop condition to continue until the stop event is set.

runbot-116746,161035,223589,77470

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#214737

Prior to this commit, when validating a Scrap Order for a product with insuficient quantity, a wizard was shown to confirm the order as you would end up with a negative quantity in your warehouse. However, the view did not properly displayed quant_ids which allows seeing the current quantity for this product on the current warehouse as this compute field was not triggered during the first onchange call. When confirming the popup, the quant_ids could barely be seen before closing. The ide

Prior to this commit, when validating a Scrap Order for a product with
insuficient quantity, a wizard was shown to confirm the order as you
would end up with a negative quantity in your warehouse. However,
the view did not properly displayed quant_ids which allows seeing the
current quantity for this product on the current warehouse as this
compute field was not triggered during the first onchange call.
When confirming the popup, the quant_ids could barely be seen
before closing.
The idea is to make so that quand_ids can be seen as expected before
any confirmation/cancelation.

Forward-Port-Of: odoo/odoo#211152

The `_set_duration` inverse method of `mrp.workorder` is ignoring microsecond variations when computing the `date_start `of a workorder productivity record. This method uses the current time as the end date but does not remove microseconds from it. This causes a intermittent error when running the `test_labor_cost_balancing_with_cost_share`, because the computed duration (around 0.03 hours or 1.8 seconds) can vary slightly depending on the microseconds captured by `datetime.now()`. This fluc

The `_set_duration` inverse method of `mrp.workorder` is ignoring microsecond variations when computing the `date_start `of a workorder productivity record. This method uses the current time as the end date but does not remove microseconds from it.

This causes a intermittent error when running the
`test_labor_cost_balancing_with_cost_share`, because the computed duration (around 0.03 hours or 1.8 seconds) can vary slightly depending on the microseconds captured by `datetime.now()`. This fluctuation results in a 1- or 2-second difference, which breaks the test.

To fix it, we simply set the microsseconds of the end date to zero.

This bug was introduced in:
https://github.com/odoo/odoo/pull/211853

Runbot failure example:
https://runbot.odoo.com/odoo/runbot.build.error/226657

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

Forward-Port-Of: odoo/odoo#214381

This commit update the finished move quantity of a production of a serial tracked product to 1 when set the quantity producing (always to 1 in case of a serial tracked product) This is mainly mandatory in case the production need to process quality checks. Task : 4575193 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 commit update the finished move quantity of a production of a serial tracked product to 1 when set the quantity producing (always to 1 in case of a serial tracked product) This is mainly mandatory in case the production need to process quality checks.

Task : 4575193

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#206109

Before this commit: we have basic test for the url autocomplete in the linkpopover, but we miss the case for the page anchors After this commit: we added the page anchor test, also updated the icon path to the one inside website module Related PR: https://github.com/odoo/odoo/pull/187091 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214707

Before this commit: we have basic test for the url autocomplete in the linkpopover, but we miss the case for the page anchors

After this commit: we added the page anchor test, also updated the icon path to the one inside website module

Related PR: https://github.com/odoo/odoo/pull/187091



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

Forward-Port-Of: odoo/odoo#214707

Prior to this change, when users cancelled their payment, they remained stuck on their previous order. It was not possible to cancel the order from the basket page. This change allows the user to cancel the order from the shopping cart page. taskId: 4830007 Forward-Port-Of: odoo/odoo#213071 Forward-Port-Of: odoo/odoo#212140

Prior to this change, when users cancelled their payment, they remained stuck on their previous order. It was not possible to cancel the order from the basket page.

This change allows the user to cancel the order from the shopping cart page.

taskId: 4830007

Forward-Port-Of: odoo/odoo#213071
Forward-Port-Of: odoo/odoo#212140

In migration scripts, while loading the chart of accounts, we should always initiate with parent companies to avoid creating duplicate chart records. When a new account is added and the chart is loaded from the child company before the parent (due to sequence, name ordering), the account will be created for both companies. Sometimes resulting into singleton error from [here](https://github.com/odoo/enterprise/blob/saas-18.3/account_reports/models/chart_template.py#L31). With this commit, t

In migration scripts, while loading the chart of accounts, we should always initiate with parent companies to avoid creating duplicate chart records.

When a new account is added and the chart is loaded from the child company before the parent (due to sequence, name ordering), the account will be created for both companies. Sometimes resulting into singleton error from [here](https://github.com/odoo/enterprise/blob/saas-18.3/account_reports/models/chart_template.py#L31).

With this commit, the COA for Colombian-based companies will now be loaded hierarchically — i.e. parent company first — ensuring proper inheritance and avoiding redundant account or journal creation.

Community PR - #182706 
UPG - [2982418](https://upgrade.odoo.com/odoo/upgrade.request/2982418)

Traceback faced:

```python
Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-18.3/odoo/service/server.py", line 1396, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'])
  File "<decorator-gen-6>", line 2, in new
  File "/home/odoo/src/odoo/saas-18.3/odoo/tools/func.py", line 83, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/saas-18.3/odoo/orm/registry.py", line 167, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-18.3/odoo/modules/loading.py", line 487, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/saas-18.3/odoo/modules/migration.py", line 220, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/src/odoo/saas-18.3/odoo/modules/migration.py", line 257, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/src/odoo/saas-18.3/addons/l10n_co/migrations/1.0/end-migrate_update_taxes.py", line 8, in migrate
    env['account.chart.template'].try_loading('co', company)
  File "/home/odoo/src/odoo/saas-18.3/addons/account/models/chart_template.py", line 160, in try_loading
    return self._load(template_code, company, install_demo, force_create)
  File "/home/odoo/src/odoo/saas-18.3/addons/account/models/chart_template.py", line 244, in _load
    self._load(template_code, subsidiary, install_demo, force_create)
  File "/home/odoo/src/odoo/saas-18.3/addons/account/models/chart_template.py", line 227, in _load
    self._post_load_data(template_code, company, template_data)
  File "/home/odoo/src/enterprise/saas-18.3/account_reports/models/chart_template.py", line 29, in _post_load_data
    'account_tax_return_journal_id': closing_journal.id,
  File "/home/odoo/src/odoo/saas-18.3/odoo/orm/fields_misc.py", line 117, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.journal(28, 29)
```

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#214488

Logs were rotating after 2 days, but not above a certain filesize, which could lead to saturation of `/var`, which size is limited to 192MB. We now rotate above 100M. Forward-Port-Of: odoo/odoo#214629

Logs were rotating after 2 days, but not above a certain filesize, which could lead to saturation of `/var`, which size is limited to 192MB.

We now rotate above 100M.

Forward-Port-Of: odoo/odoo#214629

Before this commit, when using discuss call, using some usb camera would lead to wrong camera settings: ``` aspectRatio: 1.7777777777777777 frameRate: 20, height: 360, resizeMode: "crop-and-scale", width: 640, ``` This happens because of the camera config constraints that are not well understood by some usb cameras, such as `max` for width and height. Another problem is that `frameRate` was set to 30 but a camera can stream 30.0003 frames per seconds which is slightly higher. Becaus

Before this commit, when using discuss call, using some usb camera would lead to wrong camera settings:

```
aspectRatio: 1.7777777777777777
frameRate: 20,
height: 360,
resizeMode: "crop-and-scale",
width: 640,
```

This happens because of the camera config constraints that are not well understood by some usb cameras, such as `max` for width and height.
Another problem is that `frameRate` was set to 30 but a camera can stream 30.0003 frames per seconds which is slightly higher. Because of the 30 value, it forces camera to stream a much lower framerate. Also somehow the camera panics and crop the content when this is not wanted.

This commit fixes the issue by simplifying constraints to only asking for explicit width. This is well understood by many cameras and it just works. Framerate is managed by camera and bandwidth constraints, aspect-ratio has no reason to be limited by constraints and instead the source decides and call view managed the layout like it does now.

With the same usb camera that give the results before, with the new contraints this become:

```
aspectRatio: 1.7777777777777777
frameRate: 30.000030517578125
height: 720
resizeMode: "none"
width: 1280
```

Forward-Port-Of: odoo/odoo#214886

Steps to Reproduce: - Install `website_sale_stock` and enable the Reorder from portal feature. - Place an order from `/shop` that includes one or more combo products. - Navigate to `/my/orders` and attempt to reorder the same. - Combo products are broken into separate lines rather than shown as a single combo. - Stock information for the combo is not available, as the items are treated independently. Issue: - Combo products are displayed as separate lines in reorder modal - Also stock

Steps to Reproduce:
- Install `website_sale_stock` and enable the Reorder from portal feature.
- Place an order from `/shop` that includes one or more combo products.
- Navigate to `/my/orders` and attempt to reorder the same.
- Combo products are broken into separate lines rather than shown as a single combo.
- Stock information for the combo is not available, as the items are treated independently.

Issue:
- Combo products are displayed as separate lines in reorder modal
- Also stock management of combo products is not there

Cause:
- The `/my/orders/reorder_modal_content` controller route lacks logic to handle combo products. The reorder modal builds the cart lines assuming all items are standalone, disregarding combo grouping and related stock aggregation.

Solution:
- Extend the `/my/orders/reorder_modal_content` route logic to correctly identify and process combo products as single bundled entities.
- Update the reorder modal in `website_sale_stock` to incorporate combo-specific stock handling, ensuring accurate availability feedback for the entire combo.
- This ensures that the reorder experience mirrors the original order composition and improves stock visibility for bundled products.

opw-4731014
Affected Version-18.0

Forward-Port-Of: odoo/odoo#214426
Forward-Port-Of: odoo/odoo#209234

* STEP TO REPRODUCE: Have 2 company (1 is Default San Francisco the other is VN company),Start enviroment in VN company -> config an online payment method with Demo/Wire Transfer -> Start session and create pos order with no customer then Validate -> Customer scan QR code using mobile (not logged in) -> 403 forbidden error, read the log said: Sorry, Public user for VN company (id=10) doesn't have 'read' access to: User (res.users) * REASON: when request.env.ref('base.public_user') it will get

* STEP TO REPRODUCE: Have 2 company (1 is Default San Francisco the other is VN company),Start enviroment in VN company -> config an online payment method with
Demo/Wire
Transfer -> Start session and create pos order with no customer then Validate -> Customer scan QR code using mobile (not logged in) -> 403 forbidden error, read the log said: Sorry, Public user for VN company (id=10) doesn't have 'read' access to: User (res.users)
* REASON: when request.env.ref('base.public_user') it will get public user from San Francisco company while the request user is Public User of VN company, the record rule prevent that
* SOLUTION: Fix by using method _get_public_user() in res.company, this
commit also move _get_public_user() from website to base module so other
modules can use it

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#214583
Forward-Port-Of: odoo/odoo#193881

The goal of this commit is to fix the `website_form_editor_tour` tour that is failing undeterministically. The tour fails because this flow happens; - The user types something ("A") as input and clicks somewhere else to commit its change. - The DOM is updated with the new value. - The user types something else ("B") on the same input. - The options are rebuild with the DOM value. -> "A" is displayed in the option input and "B" is lost. This is a know issue and it has been decided to no

The goal of this commit is to fix the `website_form_editor_tour` tour that is failing undeterministically. The tour fails because this flow happens;
- The user types something ("A") as input and clicks somewhere else to commit its change.
- The DOM is updated with the new value.
- The user types something else ("B") on the same input.
- The options are rebuild with the DOM value.

-> "A" is displayed in the option input and "B" is lost.

This is a know issue and it has been decided to not fix it in stable as the behavior seems really unlikely to happen with human behavior and the issue is not critical.

Although it is not optimal, the tour is fixed by adding delays before doing further steps.

runbot-64572

Forward-Port-Of: odoo/odoo#213417
Forward-Port-Of: odoo/odoo#213197

In 540e4243f4 we modified the `_aggregate_base_line_tax_details` method so that base lines without any taxes are no longer automatically grouped under the `None` / `null` grouping key and are instead also passed to the grouping function which evaluates a grouping key for them. As part of this improvement, all existing grouping functions needed to be adapted to explicitly return `None` or `null` for base lines with no tax. We forgot to modify the grouping function which computes the tax tot

In 540e4243f4 we modified the `_aggregate_base_line_tax_details` method so that base lines without any taxes are no longer automatically grouped under the `None` / `null` grouping key and are instead also passed to the grouping function which evaluates a grouping key for them.

As part of this improvement, all existing grouping functions needed to be adapted to explicitly return `None` or `null` for base lines with no tax.

We forgot to modify the grouping function which computes the tax totals summary in JS.

task-none

Forward-Port-Of: odoo/odoo#214843
Forward-Port-Of: odoo/odoo#214710

- The "Clear" button is only accessible by "group_stock_manager" but without a group attached, "stock_user" can still see it and operate it, resulting in an unnecessary permission error, confusing the user. Current behavior before PR:  

- The "Clear" button is only accessible by "group_stock_manager" but without a group attached, "stock_user" can still see it and operate it, resulting in an unnecessary permission error, confusing the user.


Current behavior before PR:

![Screenshot 2025-06-10 at 1 07 41 PM](https://github.com/user-attachments/assets/26922c7f-ff81-430e-af51-a5badeafcbec)

![Screenshot 2025-06-10 at 1 09 01 PM](https://github.com/user-attachments/assets/93b3dee2-e9d0-448e-b26b-9353e4120877)








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

Forward-Port-Of: odoo/odoo#214142
Forward-Port-Of: odoo/odoo#213508

Creating a post using default values in context was bypassing the karma check when adding link or image. This no-so-sexy solution just ensure that whatever the way the post is created (using or not default values in context), the check is properly executed. Task-4114387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197325

Creating a post using default values in context was bypassing the karma check when adding link or image.

This no-so-sexy solution just ensure that whatever the way the post is created (using or not default values in context),
the check is properly executed.

Task-4114387


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

Forward-Port-Of: odoo/odoo#197325

- Prevent duplicate user conflict during official mode activation in multi-branch setups - Handle scenario where branches of the same company use the same Partita IVA (VAT number) or codice fiscale - Avoid "An user already exist in the database" error by validating user association logic - The branch should affect the same record in the db the will have the same proxy user Task [link](https://www.odoo.com/odoo/project/967/tasks/4737181) task-4737181 Forward-Port-Of: odoo/odoo#211060 Forw

- Prevent duplicate user conflict during official mode activation in multi-branch setups
- Handle scenario where branches of the same company use the same Partita IVA (VAT number) or codice fiscale
- Avoid "An user already exist in the database" error by validating user association logic
- The branch should affect the same record in the db the will have the same proxy user

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

Forward-Port-Of: odoo/odoo#211060
Forward-Port-Of: odoo/odoo#209120

In order to satisfy certification requirements from the LNE, we implement the following: - A product is weighed at e.g. 200g and added to the order - Another product is weighed. The weight must change from 200g before the user is allowed to add the item. - This should also happen even if another non-weighed product is added in-between. task-4859589 Enterprise PR: https://github.com/odoo/enterprise/pull/87296 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.

In order to satisfy certification requirements from the LNE, we implement the following:
- A product is weighed at e.g. 200g and added to the order
- Another product is weighed. The weight must change from 200g before the user is allowed to add the item.
- This should also happen even if another non-weighed product is added in-between.

task-4859589

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

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

Forward-Port-Of: odoo/odoo#214887
Forward-Port-Of: odoo/odoo#213537

runbot-112917 runbot-112998 Follow up of https://github.com/odoo/odoo/pull/214559 The issue is still happening after the previous fix, because the issue does not only happen with the `last_interest_dt` of the member, but also with the `last_interest_dt` of the channel. Forward-Port-Of: odoo/odoo#215015

runbot-112917
runbot-112998

Follow up of https://github.com/odoo/odoo/pull/214559

The issue is still happening after the previous fix, because the issue does not only happen with the `last_interest_dt` of the member, but also with the `last_interest_dt` of the channel.

Forward-Port-Of: odoo/odoo#215015

This commit fixes a race condition in one of Hoot's internal tests. The fix simplifies the failing test since the previous manipulations were redundant and fragile. runbot [223471](https://runbot.odoo.com/odoo/runbot.build.error/223471) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214869

This commit fixes a race condition in one of Hoot's internal tests.

The fix simplifies the failing test since the previous manipulations were redundant and fragile.

runbot [223471](https://runbot.odoo.com/odoo/runbot.build.error/223471)

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

Forward-Port-Of: odoo/odoo#214869

**Current behavior before PR:** Clicking "Cancel" or "Save" in the composer would unintentionally cause the page to scroll. **Desired behavior after PR is merged:** This default behavior is now prevented in `onClickCancelOrSaveEditText`. **task**-[4826935](https://www.odoo.com/odoo/my-tasks/4826935) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214532

**Current behavior before PR:**

Clicking "Cancel" or "Save" in the composer
would unintentionally cause the page to scroll.

**Desired behavior after PR is merged:**

This default behavior is now prevented
in `onClickCancelOrSaveEditText`.

**task**-[4826935](https://www.odoo.com/odoo/my-tasks/4826935)

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

Forward-Port-Of: odoo/odoo#214532

There are some rare cases there's a chat bubble but no thread, e.g. when the thread is deleted and/or data hasn't be fetched (yet). These cases should assume no thread for a short time instead of following crash: ``` TypeError: Cannot read properties of undefined (reading 'importantCounter') ``` Forward-Port-Of: odoo/odoo#214524

There are some rare cases there's a chat bubble
but no thread, e.g. when the thread is deleted and/or data hasn't be fetched (yet).

These cases should assume no thread for a short time instead of following crash:

```
TypeError: Cannot read properties of undefined (reading 'importantCounter')
```

Forward-Port-Of: odoo/odoo#214524

When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025). Currently, such a date is assigned to week 1 of 2024 in a spreadsheet pivot, which is false and also messes up the group by of the first week of 2024. Technically, it's an issue with the date formatting "WW/YYYY" because the two parts are decorellated. Following the ISO calendar rules, the year of

When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025). Currently, such a date is assigned to week 1 of 2024 in a spreadsheet pivot, which is false and also messes up the group by of the first week of 2024.

Technically, it's an issue with the date formatting "WW/YYYY" because the two parts are decorellated.
Following the ISO calendar rules, the year of the date is obviously 2024 but the week of 12/30/2024 is 1 only because we consider it part of 2025. Since both parts of the information are gathered independently, we end up with this misleading formatted value.

Task-4853825

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#213757
Forward-Port-Of: odoo/odoo#213302

**Note: issue discovered in saas-18.3** **Step to reproduce:** - In mobile view, create a quotation (version saas-18.3) - Trying to change the quantity or view the product a traceback will be received **Traceback** ``` Uncaught Promise > Cannot read properties of undefined (reading 'activeFields') Occured on localhost:9000 on 2019-03-11 09:30:00 GMT TypeError: Cannot read properties of undefined (reading 'activeFields') at http://localhost:9000/web/assets/debug/web.assets_unit_t

**Note: issue discovered in saas-18.3**

**Step to reproduce:**
- In mobile view, create a quotation (version saas-18.3)
- Trying to change the quantity or view the product a traceback will be received

**Traceback**
```
Uncaught Promise > Cannot read properties of undefined (reading 'activeFields')
Occured on localhost:9000 on 2019-03-11 09:30:00 GMT
TypeError: Cannot read properties of undefined (reading 'activeFields')
    at http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:82391:75
    at async openRecord (http://localhost:9000/web/assets/debug/web.assets_unit_tests_setup.js:106172:18)
```

**Issue:**
fieldDependencies of widget are evaluated by `addFieldDependencies` function.
now if a field of type "x2many" is added as fieldDependencies, and field is not present in the form,
examples : [sol_product_many2one](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale/static/src/js/sale_product_field.js#L409)  and [qty_at_date_widget](https://github.com/odoo/odoo/blob/saas-18.3/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L119)

the `related` key is not added for such fields by `addFieldDependencies` function
https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/utils.js#L52-L76
which is required, when opening the subview here
https://github.com/odoo/odoo/blob/b092750d2a595ac6d4bb6402c0b78db5db6d4dce/addons/web/static/src/model/relational_model/static_list.js#L227-L233

**opw-4858035**

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

Forward-Port-Of: odoo/odoo#214496

The main changes are in the community PR odoo/odoo#213537. This commit simply adds a call in the `scale_service.js` override to ensure the new behaviour is also enabled in Enterprise. task-4859589 Forward-Port-Of: odoo/enterprise#87994 Forward-Port-Of: odoo/enterprise#87296

The main changes are in the community PR odoo/odoo#213537.

This commit simply adds a call in the `scale_service.js` override to ensure the new behaviour is also enabled in Enterprise.

task-4859589

Forward-Port-Of: odoo/enterprise#87994
Forward-Port-Of: odoo/enterprise#87296

### Steps to reproduce: - Install PoS mexican localization - Navigate to PoS and create an order with a discount line - Go to back end and try to refund this order - Notice an error pops-up ### Cause: This is happening because when refunding an order we are checking if every line has positive price but since discount lines will have negative value it trigger the validation error. https://github.com/odoo/enterprise/blob/78bcd2e0b9296ad124ea1c3157a884fa6e62999a/l10n_mx_edi_pos/model

### Steps to reproduce:
	- Install PoS mexican localization
	- Navigate to PoS and create an order with a discount line
	- Go to back end and try to refund this order
	- Notice an error pops-up

### Cause:
This is happening because when refunding an order we are checking if every line has positive price but since discount lines will have negative value it trigger the validation error.

https://github.com/odoo/enterprise/blob/78bcd2e0b9296ad124ea1c3157a884fa6e62999a/l10n_mx_edi_pos/models/pos_order.py#L286

### Fix:
We check if the order lines are positive but after filtering the discount lines out

opw-4528737

Forward-Port-Of: odoo/enterprise#87773
Forward-Port-Of: odoo/enterprise#84331

before this PR: split horizontally is ticked by default on Balance Sheet. after this PR: split horizontally is unticked by default. Task Id: 4836667 Forward-Port-Of: odoo/enterprise#86779

before this PR: split horizontally is ticked by default on Balance Sheet.
after this PR: split horizontally is unticked by default.
Task Id: 4836667

Forward-Port-Of: odoo/enterprise#86779

Current Behavior: When validating a SEPA Direct Debit batch payment, Odoo automatically attempts to send a pre-notification email using the email template account_sepa_direct_debit.email_template_sdd_pre_notification. If this template is missing (e.g. deleted or unlinked), the process fails with a ValueError: External ID not found, and the batch cannot be validated. Expected Behavior: If the template is missing, no pre-notification email should be sent, but the batch validation shoul

Current Behavior:

When validating a SEPA Direct Debit batch payment, Odoo automatically attempts to send a pre-notification email using the email template account_sepa_direct_debit.email_template_sdd_pre_notification.

If this template is missing (e.g. deleted or unlinked), the process fails with a ValueError: External ID not found, and the batch cannot be validated.

Expected Behavior:

If the template is missing, no pre-notification email should be sent, but the batch validation should still proceed without error. The process must not raise a traceback or prevent validation.

task-4815699

Forward-Port-Of: odoo/enterprise#86278

In case of 'quantity' control per quality point. If a complete stock move line is sent to a failure location. The stock move was not split. We could have a stock move line going to a location that is not child of the location of the corresponding move. This can lead issues in case of push_rules or stock valuation. Task: 4575193 Forward-Port-Of: odoo/enterprise#81275

In case of 'quantity' control per quality point. If a complete stock move line is sent to a failure location. The stock move was not split. We could have a stock move line going to a location that is not child of the location of the corresponding move. This can lead issues in case of push_rules or stock valuation.

Task: 4575193

Forward-Port-Of: odoo/enterprise#81275

This PR removes uneccessary error log which didnt give any information but was saturating logs with the error messages such as: 2025-05-08 09:32:03,242 1212 ERROR ? odoo.addons.hw_drivers.iot_handlers.drivers.SerialBlackBoxDriver: <class 'str'> Forward-Port-Of: odoo/enterprise#85023

This PR removes uneccessary error log which didnt give any information but was saturating logs with the error messages such as:

2025-05-08 09:32:03,242 1212 ERROR ? odoo.addons.hw_drivers.iot_handlers.drivers.SerialBlackBoxDriver: <class 'str'>

Forward-Port-Of: odoo/enterprise#85023