Knowledge app automated test tours were consolidated so they start up fewer times and run more efficiently. This reduces internal testing time by about 50 seconds, helping developers validate changes faster without changing the user experience.

Re-grouping smaller tours into larger ones allows saving up on the initial load
of each tour setup, which can be pretty significant.

The measured gained time of the 2 underlying commits together is about 50
seconds (~322 seconds to run all tours before the changes and ~271 after).

Task-3598594

This fixes an incorrect internal document name in the Avalara sales order report setup. The change helps ensure the right report customization is applied and avoids confusion caused by copied naming from another document.

Copy and paste is not our friend if we do not replace all important information.

Cherry picked the commit to be able to easily associate the upgrade branch

This fix updates the point-of-sale IoT transaction status screen so optional information is handled correctly when it is not available. It helps prevent avoidable display or validation issues during payment status checks, improving stability for stores using POS IoT devices.

https://github.com/odoo/odoo/pull/151142

A copied report definition in the Avatax sales integration used the wrong inherited document name. This fix keeps the sales order report setup correctly identified, reducing confusion and helping maintain reliable document customization.

Copy and paste is not our friend if we do not replace all important information.

A little oversight which should be fixed.

Info: @wt-io-it

This update removes an outdated date display option that no longer changes how date and time fields appear. It simplifies processing across several business apps while keeping the visible result the same for users.

Since [this commit](odoo/odoo@b5794e89e1ad29e2a86c7dd) in saas-16.3, the widget date has no more effect on the rendering of a Datetime field.

For Date field, the only impact it has is in list views, where it uses the component instead of formatting the value into a string. This only requires more processing to reach the same result.

This commit therefore removes the use of this widget.

See also: https://github.com/odoo/odoo/pull/151381

This refactor centralizes how accounting entries that are created and immediately reversed are handled, covering accrued income, accrued expenses, and currency revaluation. It reduces duplicated logic and makes the accounting reports code easier to maintain without changing business workflows.

created a mixin for the entries that are created and reversed immediately (accrued incomes, accrued expenses, currency revaluation)

The problem with current code is
* account.multicurrency.revaluation.wizard and account.accrued.orders.wizard are somewhat redundant
* code of account.accrued.orders.wizard is not elegant, as it uses model names and field names from the sale/purchase modules, which it doesn't depend on

task-id: 2632645
community-PR: https://github.com/odoo/odoo/pull/134772

This update removes an unused piece of WhatsApp channel sorting logic because channel ordering is now handled elsewhere in the app. It keeps the codebase simpler without changing the expected user experience.

Channels are now sorted from DiscussAppCategory.

https://github.com/odoo/odoo/pull/152516

**Issue Description**: When creating a subscription product that has time-based pricing and options. The product on the website simply displays a recurring monthly period, rather than the six-month and annual periods as configured. This only happens in 17.0 and higher. The problem was happening because this patch wasn't calling. https://github.com/odoo/enterprise/blob/4c577804b4f6fadb1d606896a3c124909b85ab6b/website_sale_subscription/static/src/js/variant_mixin.js#L14-L28 That's because o

**Issue Description**:
When creating a subscription product that has time-based pricing and options. The product on the website simply displays a recurring monthly period, rather than the six-month and annual periods as configured. This only happens in 17.0 and higher.

The problem was happening because this patch wasn't calling. https://github.com/odoo/enterprise/blob/4c577804b4f6fadb1d606896a3c124909b85ab6b/website_sale_subscription/static/src/js/variant_mixin.js#L14-L28

That's because of the file with the patch needs to be loaded before this one https://github.com/odoo/odoo/blob/bfe857db1dd5408af57f46aa51eae8be82a4c6f9/addons/website_sale/static/src/js/website_sale.js#L15

**Steps to Reproduce**:
1. Create a new subscription product in the `Subscriptions` app.
2. In the `Attributes & Variants` tab, add a new attribute `periods` with values such as `Monthly`, `6 Months`, `Yearly`.
3. In the `Recurring Prices` tab, add each variant of the product (`Monthly`, `6 Months`, `Yearly`) along with their corresponding `Recurring Plan` and `Recurring Price`, then save.
4. Click the `Go to Website` smart button and try to change the product variants.
5. Observe that the product is always labeled as "per month" regardless of the selected variant.

**Proposed Solution**:
To resolve this, ensure that the mixin is patched before its usage. This can be achieved by forcing the load order of the scripts. This adjustment ensures the correct script loading sequence, allowing the patch to apply before the mixin is used.

opw-3654134

Forward-Port-Of: odoo/enterprise#55194

If website_menu don't have a url and website_helpdesk module is installed, hence, we checked particular website_menu's url as a result we got the false value for url if it's null, that's why while connecting the database "500 internal server error" is raised as below. To resolve this issue, This PR will help to fetch only those records which have url in website_menu. ``` 500: Internal Server Error [Traceback](https://43.test.upgrade.odoo.com/en#error_traceback) Traceback (most recen

If website_menu don't have a url and website_helpdesk module is installed, hence, we checked particular website_menu's url as a result we got the false value for url if it's null, that's why  while connecting the database 
"500 internal server error" is raised as below.

To resolve this issue, This PR will help to fetch only those records which have 
url in website_menu. 
```
500: Internal Server Error
[Traceback](https://43.test.upgrade.odoo.com/en#error_traceback)
Traceback (most recent call last):
  File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1722, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 133, in retrying
    result = func()
  File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1749, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1866, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/src/odoo/17.0/addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/src/odoo/17.0/odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/src/odoo/17.0/addons/website/controllers/main.py", line 97, in index
    top_menu = request.website.menu_id
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2886, in __get__
    return super().__get__(records, owner)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1206, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1388, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4858, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 101, in determine
    return needle(*args)
  File "/home/odoo/src/odoo/17.0/addons/website/models/website.py", line 181, in _compute_menu
    menus.mapped('is_visible')
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6066, in mapped
    recs = recs._fields[name].mapped(recs)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1280, in mapped
    self.__get__(first(remaining), type(remaining))
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1206, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1388, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4858, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 101, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/17.0/website_helpdesk/models/website.py", line 26, in _compute_visible
    helpdesk_menus = self.filtered(lambda menu: menu.url[:9] == "/helpdesk")
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6089, in filtered
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6089, in <listcomp>
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/enterprise/17.0/website_helpdesk/models/website.py", line 26, in <lambda>
    helpdesk_menus = self.filtered(lambda menu: menu.url[:9] == "/helpdesk")
TypeError: 'bool' object is not subscriptable
```

Forward-Port-Of: odoo/enterprise#55037

Forward-Port-Of: odoo/enterprise#55735

Forward-Port-Of: odoo/enterprise#55735

Steps to reproduce: - Go to planning app at top button are not consistent - Some have rounded edges while others have sharp edge Issue: - planning app > the planning app's top button are not consistent. Some have rounded edges while others have sharp edge. Solution: - adding the bootstrap class 'rounded' to round edges of buttons task-3549328 Forward-Port-Of: odoo/enterprise#55507 Forward-Port-Of: odoo/enterprise#49587

Steps to reproduce:
- Go to planning app at top button are not consistent
- Some have rounded edges while others have sharp edge

Issue:
- planning app > the planning app's top button are not consistent.
  Some have rounded edges while others have sharp edge.

Solution:
- adding the bootstrap class 'rounded' to round edges of buttons

task-3549328

Forward-Port-Of: odoo/enterprise#55507
Forward-Port-Of: odoo/enterprise#49587

**Steps to reproduce:** - Schedule activity on a .pdf document and also on a .png document. - Apply Image/Video filter. (Only the .png file will be visible now) - Select and replace the .png document with another image. **Issue:** - Both .pdf and .png documents are now visible in the view instead of just the image/video type documents. This issue is faced as an empty domain is received by the 'load' method of the activity model. **Fix:** - This PR fixes the issue by passing

**Steps to reproduce:**

- Schedule activity on a .pdf document and also on a .png document. 
- Apply Image/Video filter. (Only the .png file will be visible now) 
- Select and replace the .png document with another image.

**Issue:**

- Both .pdf and .png documents are now visible in the view instead of just the image/video type documents. 
 This issue is faced as an empty domain is received by the 'load' method of the activity model.

**Fix:**

- This PR fixes the issue by passing props in the 'load' method call to ensure that the default data remains 
 as it is, and the existing domain is still applied.

Task: [3718403](https://www.odoo.com/web#id=3718403&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#55716

Before this commit: During the execution of this tour, at a specific step, we are required to click a document to open its preview. But the prompt to close the preview is missing as the preview opens. After this commit: The user is prompted to close the preview. task-3537521 Forward-Port-Of: odoo/enterprise#54920 Forward-Port-Of: odoo/enterprise#48917

Before this commit:
During the execution of this tour, at a specific step, we are required to click a document to open its preview. But the prompt to close the preview is missing as the preview opens.

After this commit:
The user is prompted to close the preview.

task-3537521

Forward-Port-Of: odoo/enterprise#54920
Forward-Port-Of: odoo/enterprise#48917

…rvice tasks Steps to Reproduce: - install website, field service module - in website, click on tasks - open field service tasks Issue: - it does not showing the customer's address anymore only (name, phone and email) is visible. Cause: - there is no such condition ,that the address should be visible. solution: - By default the phone and email will be visible for all the tasks, because those two fields mentioned in portal. To make the address visible only for field service task

…rvice tasks

Steps to Reproduce:
- install website, field service module
- in website, click on tasks
- open field service tasks

Issue:
- it does not showing the customer's address anymore only (name, phone and email) is visible.

Cause:
- there is no such condition ,that the address should be visible.

solution:
- By default the phone and email will be visible for all the tasks, because those two fields mentioned in portal. To make the address visible only for field service tasks we need to give xpath. By giving xpath the issue will be solved

 task-3683976

Forward-Port-Of: odoo/enterprise#54284

*: industry_fsm, industry_fsm_report Previously, the industry_fsm_tour would sometimes fail, it would appear that after transitioning between the webclient and the portal, the tour step would be incorrect when industry_fsm_sale or industry_fsm_report was installed. This is because the modules that define and patch the tour are implicitly asychronous because they import web.legacy_translations_loaded (directly or indirectly). This can cause the module loader to apply these patches after the to

*: industry_fsm, industry_fsm_report

Previously, the industry_fsm_tour would sometimes fail, it would appear that after transitioning between the webclient and the portal, the tour step would be incorrect when industry_fsm_sale or industry_fsm_report was installed. This is because the modules that define and patch the tour are implicitly asychronous because they import web.legacy_translations_loaded (directly or indirectly). This can cause the module loader to apply these patches after the tour_service has been started, and cause the tour to be started without the patches in some circumstances, causing the current step to be inconsistent between the frontend and backend.

This commit fixes that by removing the import of
web.legacy_translations_loaded, which makes the modules synchronous and guarantees that the patches are applied before the tour service starts. This import is no longer necessary since the tour steps is now a function that's only invoked by the tour service after the translations are known to be loaded.

Forward-Port-Of: odoo/enterprise#55395
Forward-Port-Of: odoo/enterprise#55319

With an Ecuador company setup Create and post a bill Hit 'Add witholding' On the witholding line change the withholding tax Issue: base will reset to 0 opw-3690401 Forward-Port-Of: odoo/enterprise#54913

With an Ecuador company setup
Create and post a bill
Hit 'Add witholding'
On the witholding line change the withholding tax

Issue: base will reset to 0

opw-3690401

Forward-Port-Of: odoo/enterprise#54913

With the refactor of the Peruvian electronic invoicing [1], we missed a valid use case where the currency of the SPOT amount must always be PEN and not the same as the currency of the related invoice. [1] 12b9effea5a763483d86477e27c7bc8261bcb4f0 Forward-Port-Of: odoo/enterprise#55323

With the refactor of the Peruvian electronic invoicing [1], we missed a valid use case where the currency of the SPOT amount must always be PEN and not the same as the currency of the related invoice.

[1] 12b9effea5a763483d86477e27c7bc8261bcb4f0

Forward-Port-Of: odoo/enterprise#55323

Fixed wrong dictionary access in salary rule Forward-Port-Of: odoo/enterprise#55647 Forward-Port-Of: odoo/enterprise#55586

Fixed wrong dictionary access in salary rule

Forward-Port-Of: odoo/enterprise#55647
Forward-Port-Of: odoo/enterprise#55586

Forward-Port-Of: odoo/enterprise#55669 Forward-Port-Of: odoo/enterprise#55217

Forward-Port-Of: odoo/enterprise#55669
Forward-Port-Of: odoo/enterprise#55217

**Steps:** - Open Timesheet > All Timesheets -Add values for multiple projects for any employee on a particular date. - Now group by Employee. - Try to change the value for that employee on that particular date. **Issue:** - Traceback occurs and user is unable to change the values for existing timesheets. **Cause:** - 'line.project_id' is expected to be a single record (singleton), but it appears to be a set or a list of records. The allow_timesheets attribute is then attempted to b

**Steps:**
- Open Timesheet > All Timesheets -Add values for multiple projects for any employee on a particular date.
- Now group by Employee.
- Try to change the value for that employee on that particular date.

**Issue:**
- Traceback occurs and user is unable to change the values for existing timesheets.

**Cause:**
- 'line.project_id' is expected to be a single record (singleton), but it appears to be a set or a list of records. The allow_timesheets attribute is then
 attempted to be accessed directly on the set or list, which results in a
ValueError.

**Fix:**
- By incorporating the 'all' function and the explicit iteration over line.project_id, you avoid attempting to access the allow_timesheets attribute directly on the collection, which is what causes the 'singleton error'. This fix correctly handles cases where line.project_id may contain multiple records.

**Task**-3613014

Forward-Port-Of: odoo/enterprise#55596
Forward-Port-Of: odoo/enterprise#51741

These tests are testing the monthly declaration in 2022. As of today, 2022 is no longer a valid year in the wizard, thus causing the tests to fail. In order to ensure that such an issue won't happen again, we will freeze the time for these tests to dec 31 2022, so that the year will always be valid. Forward-Port-Of: odoo/enterprise#55583

These tests are testing the monthly declaration in 2022. As of today, 2022 is no longer a valid year in the wizard, thus causing the tests to fail.

In order to ensure that such an issue won't happen again, we will freeze the time for these tests to dec 31 2022, so that the year will always be valid.

Forward-Port-Of: odoo/enterprise#55583