In this PR: - Introduced a new "Slovenian 01 (SI0125-1235-8403)" format for payment references, following Slovenia’s Model 01 standard. This format is selectable in Sales journals (Advanced Settings) and set as the default for Slovenian companies. task-4805083 Forward-Port-Of: odoo/odoo#211608

In this PR:
- Introduced a new "Slovenian 01 (SI0125-1235-8403)" format for payment references, following Slovenia’s Model 01 standard. This format is selectable in Sales journals (Advanced Settings) and set as the default for Slovenian companies.

task-4805083

Forward-Port-Of: odoo/odoo#211608

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

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

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

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#213537

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#214710

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

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

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

- 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

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#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#87296

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