Click on quick ation button in Chat window header was a bit tedious in desktop. This happens because the clickable area is 24px x 24px. This commit makes it easier by increasing to 28px x 28px, thanks to explicit `p-1` on buttons. This ain't much but this gives less frustration to use chat window quick actions. <img width="601" alt="Screenshot 2025-01-02 at 18 23 47" src="https://github.com/user-attachments/assets/b0c09d0c-906b-43b9-b8f7-6fb954c34998" /> Forward-Port-Of: odoo/odoo#19224

Click on quick ation button in Chat window header was a bit tedious in desktop. This happens because the clickable area is 24px x 24px.

This commit makes it easier by increasing to 28px x 28px, thanks to explicit `p-1` on buttons. This ain't much but this gives less frustration to use chat window quick actions.


<img width="601" alt="Screenshot 2025-01-02 at 18 23 47" src="https://github.com/user-attachments/assets/b0c09d0c-906b-43b9-b8f7-6fb954c34998" />

Forward-Port-Of: odoo/odoo#192241

Skip because test has race conditions, until we have time to properly fix it. runbot-109795 Forward-Port-Of: odoo/odoo#192470

Skip because test has race conditions, until we have time to properly fix it.

runbot-109795

Forward-Port-Of: odoo/odoo#192470

### Commit 1: [FIX] account_peppol: Remove useless div The div is replaced few lines below, so no need to make it visible/invisible. task-no ### Commit 2: [FIX] account_edi_ubl_cii: add belgian EAS translation task-no ### Commit 3: [FIX] account_edi_ubl_cii: fix typo in EAS task-no ### Commit 4: [FIX] account_peppol: clean calls to proxy Before this commit, when calling our Peppol proxy, here is what the call graph would look like (prefixed by the module the method belongs to):

### Commit 1: [FIX] account_peppol: Remove useless div
The div is replaced few lines below, so no need to make it
visible/invisible.

task-no

### Commit 2: [FIX] account_edi_ubl_cii: add belgian EAS translation
task-no

### Commit 3: [FIX] account_edi_ubl_cii: fix typo in EAS
task-no

### Commit 4: [FIX] account_peppol: clean calls to proxy
Before this commit, when calling our Peppol proxy, here is what the call
graph would look like (prefixed by the module the method belongs to):
`account_peppol._call_peppol_proxy`
-> `account_peppol._make_request`
--> `account_peppol._call_peppol_proxy`
---> `account_edi_proxy_client._make_request`

We simplify this to:
`account_peppol._call_peppol_proxy`
-> `account_edi_proxy_client._make_request`

task-no

### Commit 5: [FIX] account_peppol: fix reopening of Print & Send wizard
With previous commit [1], we broke the flow when registering to Peppol
coming from the Print & Send wizard. The Print & Send wizard was not
reopening after successful registration.

task-no

Forward-Port-Of: odoo/odoo#191485

This commit uses the `inset-inline-start` CSS property instead of `left` to account for RTL languages. (No linked task) Forward-Port-Of: odoo/odoo#191342

This commit uses the `inset-inline-start` CSS property instead of `left` to account for RTL languages.

(No linked task)

Forward-Port-Of: odoo/odoo#191342

**Issue:** A warning popup appears incorrectly when a user-defined default is set for the "Quotation Template (Sales Order)" field. This warning is only relevant when the company is changed while creating a quotation. **Steps to reproduce the issue:** 1- Navigate to Settings > Technical > Actions > User-defined Defaults. 2- Create a new User-defined Default for the field "Quotation Template (Sales Order)" with a default value (in JSON format) of 1 . 3- Go to the Sales module. 4- Crea

**Issue:**

A warning popup appears incorrectly when a user-defined default is set for the "Quotation Template (Sales Order)" field. This warning is only relevant when the company is changed while creating a quotation.

**Steps to reproduce the issue:**

1- Navigate to Settings > Technical > Actions > User-defined Defaults.
2- Create a new User-defined Default for the field "Quotation Template (Sales Order)" with a default value (in JSON format) of 1 .
3- Go to the Sales module.
4- Create a new quotation.

A warning with the title "Warning for the change of your quotation's company" is displayed (see screenshot attached), despite the company not being changed.
The onchange('company_id') method is triggered by the user-defined default for the quotation template.

<img src="https://github.com/user-attachments/assets/5f046310-05b7-48ab-9781-1ba4a36f2beb" width=400 />


opw-4244961

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

Forward-Port-Of: odoo/odoo#192267
Forward-Port-Of: odoo/odoo#184713

to reproduce: ============= - create a leave for an employee of 3 days - create a public holiday that happens to be in the middle of the employee leave - check work entries for the employee on that period -> only work entries of the public holiday are created Problem: ======== - when the public holiday was created, the leave was not split to take into account the public holiday Solution: ========= - split the leave to take into account the public holiday opw-4353988 --- I co

to reproduce:
=============
- create a leave for an employee of 3 days
- create a public holiday that happens to be in the middle of the employee leave
- check work entries for the employee on that period -> only work entries of the public holiday are created

Problem:
========
- when the public holiday was created, the leave was not split to take into account the public holiday

Solution:
=========
- split the leave to take into account the public holiday

opw-4353988

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

Forward-Port-Of: odoo/odoo#192376
Forward-Port-Of: odoo/odoo#191552

Fixes an issue due to the phone number being formatted before the verification that it is actually set. The formatting will now support receiving no phone number, and it won't cause an issue as its existence is checked right after. Also avoid running the account_edi_proxy_client neutralize on malaysian users, as it simply set the type to test. The malaysian edi supports having both a test and production user set on the same db (only one is being use at any given time of course), so that neut

Fixes an issue due to the phone number being formatted before the verification that it is actually set.
The formatting will now support receiving no phone number, and it won't cause an issue as its existence is checked right after.

Also avoid running the account_edi_proxy_client neutralize on malaysian users, as it simply set the type to test. The malaysian edi supports having both a test and production user set on the same db (only one is being use at any given time of course), so that neutralize could result in having two test users, which is not allowed by the constrains.

opw-4352823

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

Forward-Port-Of: odoo/odoo#190685

Currently, a traceback is occurring when the user tries to delete archived product variants. To reproduce this issue: 1) Install sale and enable product variants from configuration 2) Create a product from the variant and archive it 3) Now try to delete the above archived product. Error:- ``` KeyError: 2 ``` When the user archives a product and tries to delete the archived product, we get the `product_ids_by_template_id` as an empty dict. https://github.com/odoo/odoo/blob

Currently, a traceback is occurring when the user tries to delete archived product variants.

To reproduce this issue:

1) Install sale and enable product variants from configuration 
2) Create a product from the variant and archive it
3) Now try to delete the above archived product.

Error:- 
```
KeyError: 2
```

When the user archives a product and tries to delete the archived product, 
we get the `product_ids_by_template_id` as an empty dict.

https://github.com/odoo/odoo/blob/f118a44c5b15163556e3388c5a7daa72119f58f8/addons/product/models/product_product.py#L384-L388

This leads to the above traceback when accessing the product template id from an empty dict
from the below line.

https://github.com/odoo/odoo/blob/f118a44c5b15163556e3388c5a7daa72119f58f8/addons/product/models/product_product.py#L395

sentry-6173505059

Forward-Port-Of: odoo/odoo#191761

Steps to reproduce: initial state: The accounting report "General Ledger" has the filter "unfold all" option activated and this filter can be selected on the report. - Create a new accounting report - Select "Composite Report" - Add the General Ledger as a section - Save -> When navigating to the General Ledger, it no longer has the "unfold all" option selected. Solution provided: If the report is accessible, should not change its fields when being added to a composite rep

Steps to reproduce:

initial state: The accounting report "General Ledger" has the filter "unfold all" option activated and this filter can be selected on the report.

 - Create a new accounting report
 - Select "Composite Report"
 - Add the General Ledger as a section
 - Save

 -> When navigating to the General Ledger, it no longer has the "unfold all" option selected.

 Solution provided:
 If the report is accessible, should not change its fields when being added to a composite report.

 task-4317649


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

Forward-Port-Of: odoo/odoo#188476

Steps to reproduce: - insert a list of timesheets in a spreadsheet - reload the spreadsheet - right click on a list cell - click on "See record" => it's not the correct form view Task: 4444541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192356 Forward-Port-Of: odoo/odoo#192222

Steps to reproduce:
- insert a list of timesheets in a spreadsheet
- reload the spreadsheet
- right click on a list cell
- click on "See record"

=> it's not the correct form view

Task: 4444541


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

Forward-Port-Of: odoo/odoo#192356
Forward-Port-Of: odoo/odoo#192222

The problem was that the decorator would be triggered if Peppol is in demo mode, but also for the requests made by the Italian EDI which does not have the same information which results in a traceback. opw-4421483 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#191375

The problem was that the decorator would be triggered if Peppol is in demo mode, but also for the requests made by the Italian EDI which does not have the same information which results in a traceback.

opw-4421483

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

In this commit: === - Added the `get_session_orders` method to handle session orders. - Updated session closure logic to exclude scheduled orders from being canceled, ensuring better management of such orders. task-4361079 Related: https://github.com/odoo/enterprise/pull/74555 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188563

In this commit:
===
- Added the `get_session_orders` method to handle session orders.
- Updated session closure logic to exclude scheduled orders from being canceled, ensuring better management of such orders.

task-4361079

Related: https://github.com/odoo/enterprise/pull/74555

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

Forward-Port-Of: odoo/odoo#188563

Scenario: - install l10n_ch - go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross => the ch_cross mask (swiss cross that should be in the center) is not in the center Issue: Reportlab QrCodeWidget has a fixed size to 32mm (with mm that is 72(ppi) / 25.4(1mm to inch) so ~2.83 pixels) and to get the widget to the full size, a zoom is applied on the Drawing content (so on the QrCodeWidget). Here are the zoom that are applied for several Drawing size:

Scenario:

- install l10n_ch
- go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross

=> the ch_cross mask (swiss cross that should be in the center) is not
in the center

Issue:

Reportlab QrCodeWidget has a fixed size to 32mm (with mm that is 72(ppi)
/ 25.4(1mm to inch) so ~2.83 pixels) and to get the widget to the full
size, a zoom is applied on the Drawing content (so on the QrCodeWidget).

Here are the zoom that are applied for several Drawing size:

- for 100 pixels: 100 / (32 * mm) => 1.012…
- for 256 pixels: 256 / (32 * mm) => 2.822…
- for 400 pixels: 400 / (32 * mm) => 4.409…

But in the code, the zoom is just hardcoded to mm (~2.83) which
corresponds to a barcode size of mm * 32 * mm => 257.127 pixels which is
kind of good enough for 256 pixels, but wrong for most other size.

In base code we only use 256 x 256 pixels so this is not much of an
issue unless someone want to use it for something else.

Fix:

With this commit, we apply the Drawing zoom (on which we have the
QrCodeWidget) to the ch_cross image.

Note:

Without the fix, the added test only fail on the third assertion for
each loop iteration, the farer we are from 257x257 pixels the bigger
the error is, for example for 256x256:

Result:   (38.45140, 38.45140, 52.25725984251969, 52.25725984251969)
Expected: (38.28288, 38.28288, 52.02823111111111, 52.02823111111111)

opw-4307177

PR NOTE: this could be merged in an higher version, and we could also just not fix this since as far as I can tell, we only need to support 256x256 and with and without the fix there is just one pixel of difference in this case.

![a](https://github.com/user-attachments/assets/f38e26ee-a129-4fd1-ae92-a9768274dbbb)

Forward-Port-Of: odoo/odoo#192091

The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/odoo#181460 Forward-Port-Of: odoo/odoo#157028

The confirmation page wasn't displayed and the order wasn't sent to the
preparation display when confirming an order with a total of 0.

Now the confirmation page is displayed and the order is send to the
preparation display when the order is confirmed regardless of the total
amount.

Forward-Port-Of: odoo/odoo#181460
Forward-Port-Of: odoo/odoo#157028

The "remaining" value of a budget should be the difference between the amount spent and the amount forecast, not the other way around. Task-4331872 Forward-Port-Of: odoo/enterprise#75767 Forward-Port-Of: odoo/enterprise#73742

The "remaining" value of a budget should be the difference between the amount spent and the amount forecast, not the other way around.

Task-4331872

Forward-Port-Of: odoo/enterprise#75767
Forward-Port-Of: odoo/enterprise#73742

changing position of engine block and salary block in vehicle models view task-4351672 Forward-Port-Of: odoo/enterprise#74597

changing position of engine block and salary block in vehicle models view

task-4351672

Forward-Port-Of: odoo/enterprise#74597

- When the type of identification of vendor is 'RUC' the code should be 01 because is purchase - The "tipoComprobante" tag has to be '41' instead '01' according the schema of DIMM (government's software to validate ATS report) Forward-Port-Of: odoo/enterprise#73194

- When the type of identification of vendor is 'RUC' the code should be 01 because is purchase
- The "tipoComprobante" tag has to be '41' instead '01' according the schema of DIMM (government's software to validate ATS report)

Forward-Port-Of: odoo/enterprise#73194

### Steps to reproduce the issue: - Employee > open your favorite employee > HR Settings tab - Add a Badge Id say: 111 - Go to the shopfloor > extends the employee panel on the left - Scan the badge of your employee #### Expected behavior: The corresponding employee is added to the employee panel on the left and is set as the session owner. If you had clicked on the `+ Add operator` button before the scan, the dialog should be closed. #### Current behavior: TypeError: Cannot re

### Steps to reproduce the issue:

- Employee > open your favorite employee > HR Settings tab
- Add a Badge Id say: 111
- Go to the shopfloor > extends the employee panel on the left
- Scan the badge of your employee

#### Expected behavior:

The corresponding employee is added to the employee panel on the left and is set as the session owner. If you had clicked on the `+ Add operator` button before the scan, the dialog should be closed.

#### Current behavior:

TypeError: Cannot read properties of undefined (reading 'isShown') at `MrpDisplay._onBarcodeScanned`

### Cause of the issue:

Once the scanned barcode is parsed and match a given employee in the `_onBarcodeScanned`, this call checks that a `SelectionPopup` is shown (representing the search dialog) and if so close it: https://github.com/odoo/enterprise/blob/e6bb5d2dcd1042ae6269487056babceca34b8655/mrp_workorder/static/src/mrp_display/mrp_display.js#L170-L177 Then, the session owner is set to the scanned employee. However, the `SelectionPopup` has been removed in saas-17.3 by Commit 209b0840df4d3de184dcba6cbc09539ec191a43a:
https://github.com/odoo/enterprise/pull/56927/commits/209b0840df4d3de184dcba6cbc09539ec191a43a#diff-119404910b34efb326dbe84735b8ca63c16391841da9a7a85e5f61f790b25bd6L26-L31 and has been replaced by a regular dialog of the dialogService. It should therefore be closed in a similar way to how its done in the `selectEmployee` of the `useConnectedEmployee`:
https://github.com/odoo/enterprise/blob/e6bb5d2dcd1042ae6269487056babceca34b8655/mrp_workorder/static/src/mrp_display/hooks/employee_hooks.js#L76

opw-4405585
---

Forward-Port-Of: odoo/enterprise#75820

Fix a small issue with the test where the batch is created before the freeze time, causing the batch date & name to be wrong. Forward-Port-Of: odoo/enterprise#76425

Fix a small issue with the test where the batch is created before the freeze time, causing the batch date & name to be wrong.

Forward-Port-Of: odoo/enterprise#76425

Forward-Port-Of: odoo/enterprise#76430

Forward-Port-Of: odoo/enterprise#76430

Steps to reproduce - Activate developer mode - Go to Accounting -> Configuration -> Accounting Reports - Create a composite report with 2 existing reports that have the "filter_unfold_all" activated, i.e. "Balance Sheet" and "Profit and Loss" - Create a menu item in the action of the report - Open the report - Press the filter "Unfold All" - Press the "PDF" button -> Results: the pdf has no line unfolded while they should (the web UI works as expected) Reason of the issue

Steps to reproduce
 - Activate developer mode
 - Go to Accounting -> Configuration -> Accounting Reports
 - Create a composite report with 2 existing reports that
 have the "filter_unfold_all" activated, i.e. "Balance Sheet" and "Profit and Loss"
 - Create a menu item in the action of the report
 - Open the report
 - Press the filter "Unfold All"
 - Press the "PDF" button

 -> Results: the pdf has no line unfolded while they should (the web UI works as expected)

 Reason of the issue:
 In the dispatch_report_action() function, the get_options() was wrong and unnecessary. This function
 is first called on the first section, then called on the composite report with its own options.
 This led to use the options of the composite report which does not have the filter_unfold_all field
 set to True.

 This also handles the case where a composite report has reports A and B, A having the
 filter_unfold_all while B doesn't have it. The expected result when printing it is
 that only report A has unfolded lines.

 task-4317649

Forward-Port-Of: odoo/enterprise#74826

**: enhancements, ubereats This commit introduces several enhancements to the Point of Sale UrbanPiper module to meet the specific requirements for the US and UK regions. In this commit: === - Added store timing configuration for `pos.config` to enable flexible operational hours. - Implemented handling of the option toggle. - Added the access code in order information for Uber Eats to streamline order identification. - Included delivery address on the receipt. - Added a delivery ide

**: enhancements, ubereats
This commit introduces several enhancements to the Point of Sale UrbanPiper
module to meet the specific requirements for the US and UK regions.

In this commit:
===
- Added store timing configuration for `pos.config` to enable flexible
operational hours.
- Implemented handling of the option toggle.
- Added the access code in order information for Uber Eats to streamline order
identification.
- Included delivery address on the receipt.
- Added a delivery identifier in the POS order backend view.
- Introduced functionality to handle scheduled (future) orders.
- Include the order number in the invoice as it is essential for accurately
locating and referencing order details.
- Implemented functionality for self-delivery orders, allowing shop/restaurant
to update the order status as dispatched and completed to ensure accurate
tracking and status updates.
- Implemented functionality to send updates for the external order reference,
ensuring seamless synchronization and accurate tracking across systems.
- For the US & UK region, addressed an issue with UrbanPiper requiring the
entire product catalog. Added logic to differentiate between regions and ensure
the entire product catalog is sent when necessary.

For the US and UK regions, these features are mandatory before going live.
Implementing them in 18.0 ensures that the module meets regional requirements,
avoids delays in deployment, and maintains compatibility with existing stable
releases.

task-4361079


Related: https://github.com/odoo/odoo/pull/188563

Forward-Port-Of: odoo/enterprise#74555

The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/enterprise#70674 Forward-Port-Of: odoo/enterprise#58348

The confirmation page wasn't displayed and the order wasn't sent to the
preparation display when confirming an order with a total of 0.

Now the confirmation page is displayed and the order is send to the
preparation display when the order is confirmed regardless of the total
amount.

Forward-Port-Of: odoo/enterprise#70674
Forward-Port-Of: odoo/enterprise#58348

Before this commit: ====================== - HTTP errors were not handled for UrbanPiper requests. - Calling `response.json()`​  raise a traceback After this commit: ====================== - Enhanced error handling using `raise_for_status()` to notify users of any errors. - Added a check for `fiscal_position` during configuration. task-4447233 Forward-Port-Of: odoo/enterprise#76436

Before this commit:
======================
- HTTP errors were not handled for UrbanPiper requests.
- Calling `response.json()`​  raise a traceback

After this commit:
======================
- Enhanced error handling using `raise_for_status()` to notify users of any errors.
- Added a check for `fiscal_position` during configuration.

task-4447233

Forward-Port-Of: odoo/enterprise#76436