This update aligns the mobile popover behavior with a simplified underlying structure. It helps keep the interface stable after internal cleanup, without introducing visible changes for users.

The PopoverController/Popover separation added a layer of complexity which doesn't seem to be needed. This commit removes the PopoverController and moves the needed logic to the Popover component.

Community: https://github.com/odoo/odoo/pull/141413

This change simplifies how Odoo's web interface code accesses page navigation information. It is mainly an internal cleanup that should make future development easier and more consistent without changing day-to-day user workflows.

This commit aims at simplifying the way developers can access
router related information in the webclient. Before this commit,
in components, they had to import the hook `useService` and in
the setup do something like `this.router = useService("router")`. In
services, they had to explicitly declare the dependency to the
router service. In any other functions (like helper functions),
it was a bit painful: the function had to take an env (or the
needed information directly) in arguments, which wasn't ideal.

This commit makes accessing router information easier. The router
service has been removed. Instead, we introduce a `router` object
which can be imported directly from everywhere. Something
similar has already been done for the rpc and orm services.

Part of task 3621046

Issue: ====== the display of kiosk mode in phone is broken Steps to reproduce the issue: ============================= - Install hr_attendance - Activate Employee Pin Identification in the settings - Change to phone view - Go to attendances/kiosk mode - Identify Manually - You can't search for employee , scroll employees and see the name of the employees. - Click on any employee, the button back isn't fully shown and clicking on it does nothing. Solution: ========= Display: -

Issue:
======
the display of kiosk mode in phone is broken

Steps to reproduce the issue:
=============================
- Install hr_attendance
- Activate Employee Pin Identification in the settings
- Change to phone view
- Go to attendances/kiosk mode
- Identify Manually
- You can't search for employee , scroll employees and see the name of the employees.
- Click on any employee, the button back isn't fully shown and clicking on it does nothing.

Solution:
=========
Display:
- Added some css for `md` size devices. Back button:
- There click function was missing.

Before:
=====
before (320 x 832)
![before_320_832](https://github.com/odoo/odoo/assets/61123610/9081c133-d030-40bc-a677-c557f9c69c9b)
before (768 x 832)
![before_768_832](https://github.com/odoo/odoo/assets/61123610/c36508fd-48cc-4307-9286-c319b572d0d6)

After:
====
after (320 x 832)
![after_320_832](https://github.com/odoo/odoo/assets/61123610/03143ea8-4930-4871-84a0-6a5aa7e6bc76)
after (768 x 832)
![after_768_832](https://github.com/odoo/odoo/assets/61123610/a907d3b5-1bc8-45da-872b-fa1e27ea97e4)

opw-3645708

Forward-Port-Of: odoo/odoo#147830

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

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

Forward-Port-Of: odoo/odoo#147832

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

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

Incorporate German Loredo (xmglord) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148009

Incorporate German Loredo (xmglord) as Vauxoo's contributor.

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

Forward-Port-Of: odoo/odoo#148009

Adds a new COA for large businesses in China to better support their needs out of the box. Also implements new taxes for the same large businesses. 3202831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145879

Adds a new COA for large businesses in China to better support their needs out of the box. Also implements new taxes for the same large businesses.


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

Forward-Port-Of: odoo/odoo#145879

Description of the issue/feature this PR addresses: When replenishing a product with a route buy selected on the product form but no vendor added, we fall into an endless loop because the default_get sets the route, which triggers the onchange that return a warning. This will again call the default_get and the loop never ends. The onchange is useless as it's only goal is to display the warning, and as the field is required on the form, the user will not be able to submit it. opw-36537

Description of the issue/feature this PR addresses:

When replenishing a product with a route buy selected on the product form but no vendor added, we fall into an endless loop because the default_get sets the route, which triggers the onchange that return a warning. This will again call the default_get and the loop never ends.

The onchange is useless as it's only goal is to display the warning, and as the field is required on the form, the user will not be able to submit it.


opw-3653714


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

Forward-Port-Of: odoo/odoo#148044

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

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

Create a branch under the main company Select an internal user and keep only this branch on the fields "Allowed companies" and "Default Company" Access with the user Create an invoice Add a product Issue: user will be blocked by error """ Access Error Due to security restrictions, you are not allowed to access 'Companies' (res.company) records. Records: YourCompany (id=1) User: Marc Demo (id=6) This restriction is due to the following rules: - company rule employee Note:

Create a branch under the main company
Select an internal user and keep only this branch on the fields
"Allowed companies" and "Default Company"
Access with the user
Create an invoice
Add a product

Issue: user will be blocked by error
"""
Access Error

Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.

Records: YourCompany (id=1)
User: Marc Demo (id=6)

This restriction is due to the following rules:
- company rule employee

Note: this might be a multi-company issue.

Contact your administrator to request access if necessary.
"""

This occurs because the accounting info is taken from the parent company,
but the branch user has no access to the parent company records

opw-3627439

Forward-Port-Of: odoo/odoo#148028
Forward-Port-Of: odoo/odoo#147270

Description of the issue/feature this PR addresses: - When using safe_eval on this dict, "true" raises a NameError while "True" is interpreted properly. At the same time, this is more consistent with the rest of the code. - Affects 16.0+ - This doesn't cause an error when entering the view in Odoo as the interpreter for that is indifferent to `true` or `True` but it causes issues when a `safe_eval` is run on it Replicatable in an Odoo Shell ![Captura desde 2024-01-03 18-06-34](https://

Description of the issue/feature this PR addresses:

- When using safe_eval on this dict, "true" raises a NameError while "True" is interpreted properly.
At the same time, this is more consistent with the rest of the code.
- Affects 16.0+
- This doesn't cause an error when entering the view in Odoo as the interpreter for that is indifferent to `true` or `True` but it causes issues when a `safe_eval` is run on it

Replicatable in an Odoo Shell
![Captura desde 2024-01-03 18-06-34](https://github.com/odoo/odoo/assets/47854752/85f98b9a-a95f-4b27-812a-6b5a753bc22b)

Current behavior before PR:

```
ValueError: <class 'NameError'>: "name 'true' is not defined" while evaluating
"{'no_open': true, 'color_field': 'color'}"
```

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#148106
Forward-Port-Of: odoo/odoo#147988

When we copy a sales order we were taking margins from the past which have a high probability of not being valid anymore. Now, once we copy a sales order, no past value is copied and the purchase price is computed as new so we get the current margin values. cc @Tecnativa TT46721 check @pedrobaeza @sergio-teruel --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148156 Forward-Port-Of: odoo/odoo#147137

When we copy a sales order we were taking margins from the past which have a high probability of not being valid anymore.

Now, once we copy a sales order, no past value is copied and the purchase price is computed as new so we get the current margin values.

cc @Tecnativa TT46721

check @pedrobaeza @sergio-teruel 

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

Forward-Port-Of: odoo/odoo#148156
Forward-Port-Of: odoo/odoo#147137

This commit simply replaces the shortcut for the action_done_schedule_next buttons from alt+q to alt+z in the activity view dialog because the alt+q shortcut is already used for the Save/Schedule buttons. This was already done in https://github.com/odoo/odoo/pull/145738 but the wizard which appeared in 17.0 hadn't been corrected. opw-3565747 Forward-Port-Of: odoo/odoo#148160

This commit simply replaces the shortcut for the action_done_schedule_next buttons from alt+q to alt+z in the activity view dialog because the alt+q shortcut is already used for the Save/Schedule buttons. This was already done in https://github.com/odoo/odoo/pull/145738 but the wizard which appeared in 17.0 hadn't been corrected.

opw-3565747

Forward-Port-Of: odoo/odoo#148160

Since the commit odoo/odoo@0d99f4b9d9de404fea44ecf5480ec3b07c2b0fd6 , the header buttons with display="always" can't be invisible. The invisible attribute is ignored for this type of button in list view and kanban view. This commit fixes this issue by adding t-if that will evaluate the invisible attribute. 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 g

Since the commit odoo/odoo@0d99f4b9d9de404fea44ecf5480ec3b07c2b0fd6 , the header buttons with display="always" can't be invisible. The invisible attribute is ignored for this type of button in list view and kanban view.

This commit fixes this issue by adding t-if that will evaluate the invisible attribute.

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

Before, the websocket client was built manually, using string concatenation. Now, urllib.parse() is used to appropriately adapt the database URL. This update enhances security. Forward-Port-Of: odoo/odoo#144303

Before, the websocket client was built manually, using string concatenation.
Now, urllib.parse() is used to appropriately adapt the database URL. This update enhances security.

Forward-Port-Of: odoo/odoo#144303

Steps ===== - Install module project - Open the form view of a project - Set a planned date - Click anywhere on the page to remove the focus from the date picker Issue ===== The chosen date disappeared without any explanation to the user Cause ===== odoo#123268 introduced some changes related to the planned dates of projects. 1. the write method is modified to avoid the write of only a start/end date (both date should be set or none of them) 2. a required is added on the start

Steps
=====
- Install module project
- Open the form view of a project
- Set a planned date
- Click anywhere on the page to remove the focus from the date picker

Issue
=====
The chosen date disappeared without any explanation to the user

Cause
=====
odoo#123268 introduced some changes related
to the planned dates of projects.
1. the write method is modified to avoid the write of only a start/end date (both date should be set or none of them)
2. a required is added on the start date field in the form view of project
3. an onchange is added to avoid to have one of both field set and not the other

This last change is problematic as it overrides the required behavior of the date fields.

On top of that, https://github.com/odoo/odoo/pull/143509 changed the behavior of the datepicker widget that only display the full range by default if both fields are required (which is not the case here if they are empty).

The combination of those changes have the consequence that the planned date field is unusable in the form view of projects.

Fix
===
The onchange being only useful in form view, it is deprecated as the required attribute is sufficient for this use case and provide the user warnings if he forget a field. On top of that a required attribute is also set on the end date field.

task-3628069

Forward-Port-Of: odoo/odoo#145167

Does a couple of small fixes - Removes some leftover post-quantitypocalypse field references that don't exist anymore for the reception report. - Also fix another bug where the unassign was keeping the incorrect link in the batch picking assign => individual picking unassign (wrong in stable too, but no one has complained since it's a rare use case so can be back-ported later if needed) - Removes obsolete `force_detailed_view` context reference from tests --- I confirm I have signed

Does a couple of small fixes

- Removes some leftover post-quantitypocalypse field references that don't exist anymore for the reception report.

- Also fix another bug where the unassign was keeping the incorrect link in the batch picking assign => individual picking unassign (wrong in stable too, but no one has complained since it's a rare use case so can be back-ported later if needed)

- Removes obsolete `force_detailed_view` context reference from tests

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

Forward-Port-Of: odoo/odoo#147815

Issue - Admin unable to change related user on employee profile due to restricted access to bank account. Steps to reproduce 1- In the Employee app, go to the HR settings tab of an employee. 2- Remove the related user from this profile. 3- Set that removed user as the related user on a different employee profile and save (expect no error). 4- Attempt to revert back to the original user. 5- Encounter an access error. resolution - Added sudo() in the browse operation to prevent

Issue

- Admin unable to change related user on employee profile due to restricted access to bank account.

Steps to reproduce

1- In the Employee app, go to the HR settings tab of an employee.
2- Remove the related user from this profile.
3- Set that removed user as the related user on a different employee profile and save (expect no error).
4- Attempt to revert back to the original user.
5- Encounter an access error.

resolution

- Added sudo() in the browse operation to prevent access errors.

opw-3578412

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

Forward-Port-Of: odoo/odoo#147993
Forward-Port-Of: odoo/odoo#144467

Steps to reproduce: 1) Install and enable the "Onsite" payment provider; 2) As a public user, add product(s) to your cart; 3) Try to pay with the "Onsite" provider. -> Internal Server Error Cause of the issue: In the log, the cause of the issue is an AccessError, specifying that we tried to read the field `transaction_ids` on a `sale.order` without having the necessary access rights. This shouldn't happen, since the payment & ecommerce flows are executed in sudo mode, after m

Steps to reproduce:

1) Install and enable the "Onsite" payment provider;
2) As a public user, add product(s) to your cart;
3) Try to pay with the "Onsite" provider.

-> Internal Server Error

Cause of the issue:

In the log, the cause of the issue is an AccessError,
specifying that we tried to read the field `transaction_ids`
on a `sale.order` without having the necessary access rights.

This shouldn't happen, since the payment & ecommerce flows
are executed in sudo mode, after making sure that the cart
belongs to the customer.

After investigation, pending payment transactions trigger
1) the sending of a mail to the customer
2) the first mail generation will request the report assets
3) the generation of the report assets will create an
   attachment and commit the transaction
4) committing the transaction will trigger a global
   flush of the environment, forcing the computation
   of pending mail wizard fields, with a different
   environment than the sudoed one initiating the sending
   of the mail.

This will lead to security errors as we try to access
`sale.order` fields content without having the rights
for it.

Standard fields being already in the cache, it will
be noticed when trying to read the `transaction_ids`
field.

Solution:

Manually prefetch the `transaction_ids` content with
the sudoed environment, since the records cache is
shared between the environments (until a more global
fix is found and deployed).

Introduced by https://github.com/odoo/odoo/pull/121376

opw-3628753

Forward-Port-Of: odoo/odoo#147148

Before this commit, the link preview in the Link Dialog would not be updated after changes on the label input field, depending on other actions to be updated (e.g. picking a different type of link/button or changing the URL input field). This commit makes sure the link preview reacts to changes on the label input field. task-3580621 Forward-Port-Of: odoo/odoo#148084 Forward-Port-Of: odoo/odoo#140763

Before this commit, the link preview in the Link Dialog would not be updated after changes on the label input field, depending on other actions to be updated (e.g. picking a different type of link/button or changing the URL input field).

This commit makes sure the link preview reacts to changes on the label input field.

task-3580621

Forward-Port-Of: odoo/odoo#148084
Forward-Port-Of: odoo/odoo#140763

Although it is not a common case, it could happen that some loops are created in reconciliation. This test is added to make sure all implementations still work in that case. It was added after an optimization on the code was attempted to use `UNION ALL` instead of `UNION` in `_update_matching_number` Forward-Port-Of: odoo/odoo#148093

Although it is not a common case, it could happen that some loops are created in reconciliation.
This test is added to make sure all implementations still work in that case. It was added after an optimization on the code was attempted to use `UNION ALL` instead of `UNION` in `_update_matching_number`

Forward-Port-Of: odoo/odoo#148093

…r lines This is needed for a specific global invoice flow in l10n_mx_edi. task: 3638126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146313

…r lines

This is needed for a specific global invoice flow in l10n_mx_edi.

task: 3638126

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

Forward-Port-Of: odoo/odoo#146313

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

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

*: hr_attendance, survey, website_sale This commit fixes all found occurrences of such a case: ```xml <t t-set="classes">some_classes</t> ``` => CSS classes being marked for translation by mistake. A breaking case was found via task-3636009, where the arabic language has a translated class on some element which makes some JS crash because of it. Steps to reproduce (only for 17.0): - Create a website with the "Arabic" language as the default language - Go to the shop page in Arabic

*: hr_attendance, survey, website_sale

This commit fixes all found occurrences of such a case:
```xml
<t t-set="classes">some_classes</t>
```
=> CSS classes being marked for translation by mistake.

A breaking case was found via task-3636009, where the arabic language has a translated class on some element which makes some JS crash because of it.
Steps to reproduce (only for 17.0):
- Create a website with the "Arabic" language as the default language
- Go to the shop page in Arabic
- If you are in grid view, click on the "switch to list view" button and if you are in list view, click on the "switch to grid view" button
=> Crash

Note that commit [1] already did something similar a while ago (but more generically than this commit). In this commit here, broken occurrences were found using this regex:
```
<t\s+t-set=["']\w+lass(es)?["']\s*>
```

[1]: https://github.com/odoo/odoo/commit/98678199a32b3ba9af999f76980a6110546ec0fc

task-3636009

Forward-Port-Of: odoo/odoo#147688
Forward-Port-Of: odoo/odoo#147490

Issue Description: ================== The system currently resets the expected duration in the Work Order tab of a Manufacturing Order (MO) to the default Bill of Materials (BOM) value after 'Produce All' is used. This occurs despite any manual duration adjustments. This issue can be traced back to the dependencies of the compute method involved in this process. Specifically: 1. The `qty_production` field in `mrp_workorder.py` is a related field https://github.com/odoo/odoo/blob/2e5da1130f4

Issue Description:
==================
The system currently resets the expected duration in the Work Order tab of a Manufacturing Order (MO) to the default Bill of Materials (BOM) value after 'Produce All' is used. This occurs despite any manual duration adjustments. This issue can be traced back to the dependencies of the compute method involved in this process. Specifically:

1. The `qty_production` field in `mrp_workorder.py` is a related field https://github.com/odoo/odoo/blob/2e5da1130f4a7056f746a4cce6ba75bf699dbe62/addons/mrp/models/mrp_workorder.py#L44
2. When marking the MO as done, we write on this related field https://github.com/odoo/odoo/blob/780dded71cc725d75a0739e6c7bf4ceab5850581/addons/mrp/models/mrp_production.py#L1886
3. This action triggers a call to the compute method https://github.com/odoo/odoo/blob/2e5da1130f4a7056f746a4cce6ba75bf699dbe62/addons/mrp/models/mrp_workorder.py#L324 leading to the unexpected change in the expected duration value.

Steps to Reproduce:
===================
1. Create a Manufacturing Order (MO) with a product that has a BOM.
2. In the Work Order tab of the MO, input a custom expected duration different from the BOM's default duration.
3. Сomplete all product validation steps.
3. Click 'Produce All' on the MO.
4. Observe the reset of the expected duration to the default BOM value in the Work Order tab.

Proposed Solution:
==================
Implement a change to prevent the re-calculation of `duration_expected` in the Work Order tab once the work order's state is set to 'done' or 'cancel', ensuring that any custom duration set prior to executing 'Produce All' is maintained.

opw-3608185

Forward-Port-Of: odoo/odoo#146843

Purpose ======= When we open an email that has been encapsulated in the notification email, we still search the partner based on that email (which make no sens). Instead, in that case, we show an error saying that it's the notification email. Task-3557545 Forward-Port-Of: odoo/odoo#148073 Forward-Port-Of: odoo/odoo#139002

Purpose
=======
When we open an email that has been encapsulated in the notification
email, we still search the partner based on that email (which make no
sens). Instead, in that case, we show an error saying that it's the
notification email.

Task-3557545

Forward-Port-Of: odoo/odoo#148073
Forward-Port-Of: odoo/odoo#139002

Version: -------- - 16.0+ Steps to reproduce: ------------------- 1. Go to Timesheets / Configuration / Settings; 2. set encoding method to Days / Half-Days; 3. go to sales and create a sales order; 4. sell a service that will create project on sale; 5. confirm and go to the generated project's settings. Issue: ------ The Allocated Days displayed is one-eighth of what's expected. Cause: ------ On project creation, it was using `timesheet_encode_uom_id` to calculate `allocate

Version:
--------
- 16.0+

Steps to reproduce:
-------------------
1. Go to Timesheets / Configuration / Settings;
2. set encoding method to Days / Half-Days;
3. go to sales and create a sales order;
4. sell a service that will create project on sale;
5. confirm and go to the generated project's settings.

Issue:
------
The Allocated Days displayed is one-eighth of what's expected.

Cause:
------
On project creation, it was using `timesheet_encode_uom_id` to calculate `allocated_hours`. Hence, if timesheets are being encoded in days, it also tries to encode the project's `allocated_hours` as days, dividing the quantity by eight.

Solution:
---------
It should use `project_time_mode_id` as UoM instead, which is hardcoded to hours.

opw-3614995

Forward-Port-Of: odoo/odoo#148183
Forward-Port-Of: odoo/odoo#147009

[[FIX] website: allow restricted editor to optimize SEO](https://github.com/odoo/odoo/pull/147981/commits/3ce4ada5c1442bfcd0b8e3531f71826f0d464234) Originally, restricted editors don't have the rights to edit the SEO of a record. It was probably a bad idea as they can already edit the record itself and can change the name / description of the record in the page. Changing the SEO seems to be very similar. Also, for our internal needs, we need our HR people (which are restricted edit

[[FIX] website: allow restricted editor to optimize SEO](https://github.com/odoo/odoo/pull/147981/commits/3ce4ada5c1442bfcd0b8e3531f71826f0d464234) 

Originally, restricted editors don't have the rights to edit the SEO of
a record.

It was probably a bad idea as they can already edit the record itself
and can change the name / description of the record in the page.
Changing the SEO seems to be very similar.

Also, for our internal needs, we need our HR people (which are
restricted editor with rights on jobs position) to be able to edit the
SEO of their jobs. And we don't want to grant them the full editor
right.

Note:
- We already have a `data-can-optimize-seo` attribute set on the HTML
  tag if one is logged in, but this is just about knowing if the record
  has SEO-mixin capability, it does not check the rights for a given
  record.
- In master, one day, we would like to have the "Edit" button shown only
  when something can be edited for restricted editor (to not be able to
  enter edit mode to then not be able to edit anything). The same would
  be nice here: optimize seo menu could only be shown if you have the
  right, but we don't want to do an extra RPC each time for now.
- We keep the info shown in readonly mode so the restricted user can see
  it and ask for a change to someone else if needed

Forward-Port-Of: odoo/odoo#147981

The dates in the customer statements header is using the format 'Y'. This is an issue as the capital Y is using the ISO year-week calendar, leading to the wrong year being displayed in the report during some weeks. To reproduce on runbot, simply open the partner ledger on 2024 and print. The end date should be 31/12/2024 but formatted as 31/12/2025 Forward-Port-Of: odoo/enterprise#53529

The dates in the customer statements header is using the format 'Y'.
This is an issue as the capital Y is using the ISO year-week calendar,
leading to the wrong year being displayed in the report during some weeks.

To reproduce on runbot, simply open the partner ledger on 2024 and print. The end date should be 31/12/2024 but formatted as 31/12/2025

Forward-Port-Of: odoo/enterprise#53529

*: documents, stock_barcode See community commit for details. task-3636009 Forward-Port-Of: odoo/enterprise#53463 Forward-Port-Of: odoo/enterprise#53381

*: documents, stock_barcode

See community commit for details.

task-3636009

Forward-Port-Of: odoo/enterprise#53463
Forward-Port-Of: odoo/enterprise#53381

**[FIX] l10n_mx_edi: Fix management of negative lines** Bug: When there were 2 lines with exactly the same amount, one line with 0 amount was reported on the CFDI. Improvement: When dealing with multiple negative lines, put the lines having the same amount first. **[FIX] l10n_mx_edi_pos: Fix management of pos order refunds for global invoice** - Create a pos order - Refund the pos order - Try to create a global invoice for both: UserError => We don't allow refund on GI so in that

**[FIX] l10n_mx_edi: Fix management of negative lines**
Bug:
When there were 2 lines with exactly the same amount, one line with 0 amount was reported on the CFDI.

Improvement:
When dealing with multiple negative lines, put the lines having the same amount first.

**[FIX] l10n_mx_edi_pos: Fix management of pos order refunds for global invoice**

- Create a pos order
- Refund the pos order
- Try to create a global invoice for both: UserError
=> We don't allow refund on GI so in that case, the user is stuck and can't send the refund to the government.

To fix this, the refunded lines are added to the order like order lines part of the present order.

**[IMP] l10n_mx_edi[_pos]: Remove 'l10n_mx_edi.manage_invoice_negative_lines' config parameter**

Since we have now the global invoice, we have to manage the negative lines on the POS.
Otherwise, nobody is able to make a refund.

**[FIX] l10n_mx_edi_pos: Mock unexpected call to web-service in not external test**

Since the pos orders are paid and invoiced, the CFDI is created automatically.
No need to call the send & print wizard.

task: 3638126

Forward-Port-Of: odoo/enterprise#52787

Since odoo/odoo#140898 the pickings detailed operation view has been moved to a smart button instead of showing in a picking tab. This included the removal of the `force_detailed_view` context since there was no longer a detailed view to force show. This commit removes some leftover references to this context within tests. Forward-Port-Of: odoo/enterprise#53536

Since odoo/odoo#140898 the pickings detailed operation view has been moved to a smart button instead of showing in a picking tab. This included the removal of the `force_detailed_view` context since there was no longer a detailed view to force show. This commit removes some leftover references to this context within tests.

Forward-Port-Of: odoo/enterprise#53536

Steps ===== - install industry_fsm - create a task in a fsm project Issue ===== The planned date field is not displayed as a range as it should. Cause ===== https://github.com/odoo/enterprise/pull/40866 introduces an onchange on planned_date_begin and date_deadline that prevents to leave one of the field empty while the other is set. https://github.com/odoo/odoo/pull/143509 changes the behavior of the daterange widget and display it as a single field if it is not required. Fix

Steps
=====
- install industry_fsm
- create a task in a fsm project

Issue
=====
The planned date field is not displayed as a range as it should.

Cause
=====
https://github.com/odoo/enterprise/pull/40866 introduces an onchange on planned_date_begin and date_deadline that prevents to leave one of the field empty while the other is set.

https://github.com/odoo/odoo/pull/143509 changes the behavior of the daterange widget and display it as a single field if it is not required.

Fix
===
A change to the daterange widget is introduced to force the display as a range (see community pr).

task-3628069
related-https://github.com/odoo/odoo/pull/145167

Forward-Port-Of: odoo/enterprise#52280

Forward-Port-Of: odoo/enterprise#53623 Forward-Port-Of: odoo/enterprise#53554

Forward-Port-Of: odoo/enterprise#53623
Forward-Port-Of: odoo/enterprise#53554

Translations may introduce whitespace into the text of some buttons. The text of the buttons may then contain a linebreak. This i.e. concerns the buttons in the "Manual Operations" tab that are visible when a non-liquidity line is selected and has a partner set: "Client:", "Payable:" below the partner. Reproduce 1. Select French language 2. Go to the bank reconciliation widget and select an unmatched statement line. 3. On the right side: Select any line that is not the liquidity line

Translations may introduce whitespace into the text of some buttons. The text of the buttons may then contain a linebreak. This i.e. concerns the buttons in the "Manual Operations" tab that are visible when a non-liquidity line is selected and has a partner set: "Client:", "Payable:" below the partner.

Reproduce
  1. Select French language
  2. Go to the bank reconciliation widget and select an unmatched statement line.
  3. On the right side: Select any line that is not the liquidity line
  4. Ensure that the "Manual Operations" tab is selected
  5. Ensure that a partner is set and the 2 buttons below the partner are visible.
  6. The 2 buttons contain linebreaks.

Forward-Port-Of: odoo/enterprise#53574
Forward-Port-Of: odoo/enterprise#52027

This commit fixes a bug where the export button would take into account elements that are useless to print (such as discuss tabs). Now we added a scss rule inside the `knowledge_print.scss` file to remove any element that is not inside of the action_manager => all of the discuss containers, the editor toolbar, etc. task-3653295 Forward-Port-Of: odoo/enterprise#53573

This commit fixes a bug where the export button would take into account elements that are useless to print (such as discuss tabs).

Now we added a scss rule inside the `knowledge_print.scss` file to remove any element that is not inside of the action_manager => all of the discuss containers, the editor toolbar, etc.

task-3653295

Forward-Port-Of: odoo/enterprise#53573

Settings -> Accounting -> Signature Certificates Add a new valid certificate (.pfx) with the password Save Issue: Error "The certificate signature_key_file is invalid: Invalid base64-encoded string: number of data characters (5) cannot be 1 more than a multiple of 4" will appear. This occurs because after the record is created the binary field will return the size instead of data opw-3658503 Forward-Port-Of: odoo/enterprise#53584

Settings -> Accounting -> Signature Certificates
Add a new valid certificate (.pfx) with the password
Save

Issue: Error "The certificate signature_key_file is invalid:
Invalid base64-encoded string: number of data characters (5)
cannot be 1 more than a multiple of 4" will appear.
This occurs because after the record is created the binary field will
return the size instead of data

opw-3658503

Forward-Port-Of: odoo/enterprise#53584

Forward-Port-Of: odoo/enterprise#52884 Forward-Port-Of: odoo/enterprise#52440

Forward-Port-Of: odoo/enterprise#52884
Forward-Port-Of: odoo/enterprise#52440

This PR is the fix for 17.0+ that solves the two problems explained in the PRs: https://github.com/odoo/enterprise/pull/51878 https://github.com/odoo/enterprise/pull/52102 opw-3573163 Forward-Port-Of: odoo/enterprise#52330

This PR is the fix for 17.0+ that solves the two problems explained in the PRs:
https://github.com/odoo/enterprise/pull/51878
https://github.com/odoo/enterprise/pull/52102

opw-3573163

Forward-Port-Of: odoo/enterprise#52330