*: stock Strings within inline templates are not translatable, so we convert these templates into standard templates so that they can be. Task-3761551 Forward-Port-Of: odoo/odoo#159790 Forward-Port-Of: odoo/odoo#158844

*: stock

Strings within inline templates are not translatable, so we convert these templates into standard templates so that they can be. 

Task-3761551

Forward-Port-Of: odoo/odoo#159790
Forward-Port-Of: odoo/odoo#158844

Before that commit, the search defaults were removed from the WithSearch prop context by the WithSearch (search model). Fix that problem brings another one (that we also fix): The search defaults are not filtered when the WithSearch is started with a search model state or updated by its parent. Forward-Port-Of: odoo/odoo#159545 Forward-Port-Of: odoo/odoo#158833

Before that commit, the search defaults were removed from the WithSearch prop context by the WithSearch (search model).

Fix that problem brings another one (that we also fix): The search defaults are not filtered when the WithSearch is started with a search model state or updated by its parent.

Forward-Port-Of: odoo/odoo#159545
Forward-Port-Of: odoo/odoo#158833

The intended behavior to only update tags and no other fields on existing accounts during CoA loading was originally introduced in https://github.com/odoo/odoo/pull/125320 and has recently been broken by commit f2861b9d8d50 (https://github.com/odoo/odoo/pull/155256). This has been recognized because of failing requests in the upgrade platform when it tried to update the `code` field, which lead to excessive recomputations and in turn to MemoryErrors. The problem is that the tests, if the curr

The intended behavior to only update tags and no other fields on existing accounts during CoA loading was originally introduced in https://github.com/odoo/odoo/pull/125320 and has recently been broken by commit f2861b9d8d50 (https://github.com/odoo/odoo/pull/155256). This has been recognized because of failing requests in the upgrade platform when it tried to update the `code` field, which lead to excessive recomputations and in turn to MemoryErrors.

The problem is that the tests, if the current `xmlid` constitutes a record update or a new record[^1], need to be correct, no matter if the code above[^2] managed to update the `xmlid` pointer or not. Thus, restore the previous logic regarding that by only assigning the alternative record to the `account` var if it is not None.

[^1]: https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L312
      and
      https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L314

[^2]: https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L303

Forward-Port-Of: odoo/odoo#159866

### Steps to reproduce: - Go to the project application and click on any project with a task - Hover over the task and click on the "assign button" #### > inactive users can be assigned to the task ### Cause of the issue: Clicking on the "assign button" will call of the `name_search` method on `res.users` to determine which user can be added as a task assignee. Since the domain of the `user_ids` field of the `project.task` model: https://github.com/odoo/odoo/blob/331d8451d9011aff6a

### Steps to reproduce:

- Go to the project application and click on any project with a task
- Hover over the task and click on the "assign button"

#### > inactive users can be assigned to the task

### Cause of the issue:

Clicking on the "assign button" will call of the `name_search` method on `res.users` to determine which user can be added as a task assignee. Since the domain of the `user_ids` field of the `project.task` model:
https://github.com/odoo/odoo/blob/331d8451d9011aff6a8290c473a52fa77b30b358/addons/project/models/project_task.py#L169-L170
is overriden in the view:
https://github.com/odoo/odoo/blob/fcd66ee3321649405cf21bc1d625d71abf3d5819/addons/project/views/project_task_views.xml#L649
inactive users will not be filtered out by the domain. On the other hand, they chould still be filtered out during this call 
because inactive records should automatically be filtered out by the `_where_calc` method, unless explicitely asked for:
https://github.com/odoo/odoo/blob/9134358b579361ef5d7e4da43d4778027564adc9/odoo/models.py#L5389
https://github.com/odoo/odoo/blob/9134358b579361ef5d7e4da43d4778027564adc9/odoo/models.py#L5091-L5093
However, since the `'active_test'` is set to `False` in the context of the the `user_ids` field:
https://github.com/odoo/odoo/blob/331d8451d9011aff6a8290c473a52fa77b30b358/addons/project/models/project_task.py#L169-L170
the inactive records will also not be filtered out by the call of the `_where_calc` method.

#### Note: 

Prior to version 17.0, the flow worked "as expected" since the context set in the `user_ids` was not properly taken into account and inactive records were therefore filtered out by the call of this `_where_calc` method. Thanks to commit c3e497f this context is now relevant.

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

Forward-Port-Of: odoo/odoo#158824

The issue: A new fix has been introduced to solve the mimtype issue with creating an XML file: https://github.com/odoo/odoo/pull/124507 since the attachment create_uid now is the SUPERUSER_ID, when a user with the accounting role (not admin) tried to register a payment on any account.move type (invoice, credit note...) an access error is thrown The fix: remove the unused attachment as sudo opw-3787008 Forward-Port-Of: odoo/odoo#158881

The issue:
A new fix has been introduced to solve the mimtype issue with creating an XML file: https://github.com/odoo/odoo/pull/124507
since the attachment create_uid now is the SUPERUSER_ID, when a user with the accounting role (not admin) tried to register a payment on any account.move type (invoice, credit note...) an access error is thrown

The fix:
remove the unused attachment as sudo

opw-3787008

Forward-Port-Of: odoo/odoo#158881

Currently we assume that all imported invoices are incoming (i.e. bills). This was i.e. done since the tax agency only sends users bills. But some clients import invoices from other software (i.e. onboarding/starting). After this PR we decide whether the invoice is outgoing or ingoing and import the invoice correctly in either case. Link: https://www.odoo.com/web#model=project.task&id=3650355 task-3650355 Forward-Port-Of: odoo/odoo#160021 Forward-Port-Of: odoo/odoo#151139

Currently we assume that all imported invoices are incoming (i.e. bills).
This was i.e. done since the tax agency only sends users bills.

But some clients import invoices from other software (i.e. onboarding/starting).

After this PR we decide whether the invoice is outgoing or ingoing and
import the invoice correctly in either case.

Link: https://www.odoo.com/web#model=project.task&id=3650355
task-3650355

Forward-Port-Of: odoo/odoo#160021
Forward-Port-Of: odoo/odoo#151139

When an expression had no figure type, the condition "expression.figure_type != 'string'" was true and so we tried to round the value. But when the value is None, the code will crash. Now if the expression has no figure type we get the column type of the expression, but it can happen that an expression is not link to a column. If that's the case we don't round the expression. task: 3776104 Forward-Port-Of: odoo/enterprise#59314 Forward-Port-Of: odoo/enterprise#57913

When an expression had no figure type, the condition "expression.figure_type != 'string'" was true and so we tried to round the value. But when the value is None, the code will crash.

Now if the expression has no figure type we get the column type of the expression, but it can happen that an expression is not link to a column. If that's the case we don't round the expression.

task: 3776104

Forward-Port-Of: odoo/enterprise#59314
Forward-Port-Of: odoo/enterprise#57913

Purpose ======= Speed up the time taken to compute the available slots for resources in the front-end. Specifications ============== While waiting for a slot computation improvement, reducing the time taken to compute the available slots for large number of people. Changing the table booking max schedule days from 60 to 14. related: https://github.com/odoo/enterprise/pull/59101 Task-3826475 Forward-Port-Of: odoo/enterprise#59361

Purpose
=======
Speed up the time taken to compute the available slots for resources in the front-end.

Specifications
==============
While waiting for a slot computation improvement, reducing the time taken to
compute the available slots for large number of people.
Changing the table booking max schedule days from 60 to 14.

related: https://github.com/odoo/enterprise/pull/59101

Task-3826475

Forward-Port-Of: odoo/enterprise#59361

This fix resolves an access error that prevented non-admin users from using the UPS shipping method when creating sales orders. The issue occurred when the system needed to request a new access token to communicate with UPS, which previously required administrator privileges. Now, non-admin users like sales representatives can successfully add UPS delivery options to orders.

follow up to https://github.com/odoo/enterprise/pull/58895

Steps to reproduce:
- Install ups_rest
- Configure the new ups shipping method as admin
- Create an SO and try to add ups delivery as demo
- Access error

Bug:
if a new acces token is requested we need sudo accesn to update the carrier access token

opw-3771840

Forward-Port-Of: odoo/enterprise#59811

This fix resolves a system crash that occurred in the Journal Report when processing taxes with distribution lines set to zero percent. The system was attempting a division by zero calculation, which has now been corrected by ignoring zero percent distribution lines. This ensures the accounting reports generate successfully without errors.

The issue:
Go to Accounting > Reporting > Journal Report, if you have a tax with a distribution invoice/refund line that has a zero percent line, this will cause a Division By Zero traceback

The fix:
Ignore the lines with the zero percent

opw-3785700

Forward-Port-Of: odoo/enterprise#58444

This fix corrects an issue where non-subscription items added to subscription orders were incorrectly displaying duration information on invoices, making them appear as if they were temporary items to be returned. The fix ensures that duration labels only appear for actual subscription-based items, improving invoice clarity and accuracy.

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

Steps
-----
1. Create a subscription SO;
2. confirm, invoice, and upsell;
3. on upsell, add a non-subscription item;
4. create invoice.

Issue
-----
On the invoice, the non-subscription item gets labeled with a duration, as if it's supposed to be returned afterwards.

Cause
-----
When preparing invoice lines, the conditional checks whether the line has a subscription item, or the order is an upsell. The latter part was added in c8b79afe1bf2971a7ac7709e7165b863969d6a3d to store subscription id, start_date and end_date on upsell invoice lines.

Solution
--------
Add an additional conditional to format the description, only displaying duration for items that are subscription-based.

opw-3687626

Forward-Port-Of: odoo/enterprise#59684
Forward-Port-Of: odoo/enterprise#58303

Fixed a display issue where the operator licence field was not visible in the customer form. The field was positioned incorrectly within a tax information section, making it hidden from users. The field has been repositioned to be properly visible and accessible.

Open customer form view
Issue : Name for the field 'l10n_mx_edi_operator_licence' is not visible

This occurs because the xpath position the field after the vat which is
inside a div made to show the Tax information

opw-3819273

This fix restores the intended behavior where only account tags are updated when loading an existing Chart of Accounts, preventing unnecessary updates to other fields like account codes. A recent change had broken this logic, causing the system to attempt updating account codes during upgrades, which led to excessive processing and memory errors. This fix ensures smooth Chart of Accounts updates without performance degradation.

The intended behavior to only update tags and no other fields on existing accounts during CoA loading was originally introduced in https://github.com/odoo/odoo/pull/125320 and has recently been broken by commit f2861b9d8d50 (https://github.com/odoo/odoo/pull/155256). This has been recognized because of failing requests in the upgrade platform when it tried to update the `code` field, which lead to excessive recomputations and in turn to MemoryErrors.

The problem is that the tests, if the current `xmlid` constitutes a record update or a new record[^1], need to be correct, no matter if the code above[^2] managed to update the `xmlid` pointer or not. Thus, restore the previous logic regarding that by only assigning the alternative record to the `account` var if it is not None.

[^1]: https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L312
      and
      https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L314

[^2]: https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L303

Forward-Port-Of: odoo/odoo#159866

This update allows users to download electronic invoices (UBL format) even when Peppol configuration details are not set up. Previously, users were blocked from downloading these files if their company or customer was missing Peppol identifiers. Now the system will show a warning banner instead, making the invoicing process more flexible while still alerting users to complete their Peppol setup when needed.

This reverts commit ed651c93ca23c25f7cc3431b62be8f131b3ac9b6. With that commit, the users will have to empty eas/endpoint fields in order to see the checkbox and then they'll see a usererror when trying to download the ubl file.

We will fix it differently, showing the checkbox at all times (if edi format is set) and allowing to download the UBL file regardless of the eas/endpoint fields.



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

Forward-Port-Of: odoo/odoo#159553

A recent fix for XML file creation was causing accounting users (non-administrators) to encounter access errors when registering payments. This update removes unnecessary administrative privileges from an unused attachment, allowing accounting users to complete payment registration without errors.

The issue:
A new fix has been introduced to solve the mimtype issue with creating an XML file: https://github.com/odoo/odoo/pull/124507
since the attachment create_uid now is the SUPERUSER_ID, when a user with the accounting role (not admin) tried to register a payment on any account.move type (invoice, credit note...) an access error is thrown

The fix:
remove the unused attachment as sudo

opw-3787008

Forward-Port-Of: odoo/odoo#158881