@qrtl ------------------------------- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#194087

@qrtl

-------------------------------

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

Forward-Port-Of: odoo/odoo#194087

When we go to the website preview in the Odoo backend, if the current domain used (to access the backend) is not the same as the one of the previewed website, we redirect the user, and he might have to reconnect. The same is done when using the website switcher. Note: in the first case, the user is warned. We should probably do the same for the second case (?). This is a problem for the Odoo support team. When they connect to a customer database upon user request, the <customer_db_name>.odoo

When we go to the website preview in the Odoo backend, if the current domain used (to access the backend) is not the same as the one of the previewed website, we redirect the user, and he might have to reconnect. The same is done when using the website switcher.
Note: in the first case, the user is warned. We should probably do the same for the second case (?).

This is a problem for the Odoo support team. When they connect to a customer database upon user request, the <customer_db_name>.odoo.com address is used. But as soon as they are using the website app, they are redirected to the real website domains... where they are disconnected and cannot connect themselves.
To fix this issue, we allow setting up a session info parameter to bypass those website redirections. This is not to be done by real users: this will come with bugs (for the support team). Indeed, we are normally redirecting for a reason: many flows rely on using the right domain when visiting a specific website. Depending on what users have in their page, this could also simply make the website preview iframe crash.

task-4069779

Forward-Port-Of: odoo/odoo#194109
Forward-Port-Of: odoo/odoo#193122

In the document layout configurator, the paper format A4 would not be there if the module l10n_be_hr_payroll is installed. This is because in Belgium, some reports need A4 but in the configurator, we only get paperformat not linked to any report. The solution is to remove the domain for this field in the configurator. Since there will be more paper formats, I renamed the newly created formats in the Belgian payroll to differentiate them. Forward-Port-Of: odoo/odoo#183134

In the document layout configurator, the paper format A4 would not be there if the module l10n_be_hr_payroll is installed.

This is because in Belgium, some reports need A4 but in the configurator, we only get paperformat not linked to any report.

The solution is to remove the domain for this field in the configurator.

Since there will be more paper formats, I renamed the newly created formats in the Belgian payroll to differentiate them.

Forward-Port-Of: odoo/odoo#183134

Commit 239e75b1385fa0 removes `colspan="2"` to guess it from the `nolabel` attribute. This is not working because of the `string=` attribute in the `group` tag that makes the DOM having two elements instead of only one. The rule in https://github.com/odoo/odoo/blob/0ba664bace1e6bbb256bd98570866df19d35f401/addons/web/static/src/views/form/form_controller.scss#L474 is not applied. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after

Commit 239e75b1385fa0 removes `colspan="2"` to guess it from the `nolabel` attribute. This is not working because of the `string=` attribute in the `group` tag that makes the DOM having two elements instead of only one. The rule in

https://github.com/odoo/odoo/blob/0ba664bace1e6bbb256bd98570866df19d35f401/addons/web/static/src/views/form/form_controller.scss#L474

is not applied.

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

In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193607 Forward-Port-Of: odoo/odoo#192463

In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice).

This commit aims to give a single and unified way to display them.

ticket-4440711




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

Forward-Port-Of: odoo/odoo#193607
Forward-Port-Of: odoo/odoo#192463

…wnload Current behavior before PR: When using the "Download logs" button, from the IoT box form view, an Internal Server Error is raised every time. ```py Internal Server Error : Log file configuration is not set ``` Description of the issue/feature this PR addresses: New IoT Box images are missing the default `logfile` parameter in their config. This parameter is required for log downloading, and cannot be left empty. The `logfile` parameter has been removed from the `odoo.conf`

…wnload

Current behavior before PR:
 When using the "Download logs" button, from the IoT box form view, an Internal Server Error is raised every time.
```py
Internal Server Error : Log file configuration is not set
```

Description of the issue/feature this PR addresses:
New IoT Box images are missing the default `logfile` parameter in their config. This parameter is required for log downloading, and cannot be left empty.

The `logfile` parameter has been removed from the `odoo.conf` config file in PR #169633. However, it is still explicitly mentioned as `/var/log/odoo/odoo-server.log` in two other files: https://github.com/odoo/odoo/blob/451a956a22015034b8c35bd0d9a860b78442af7f/addons/hw_posbox_homepage/controllers/homepage.py#L74 and
https://github.com/odoo/odoo/blob/451a956a22015034b8c35bd0d9a860b78442af7f/addons/point_of_sale/tools/posbox/overwrite_before_init/etc/init_posbox_image.sh#L28 As such, a fallback to the default `/var/log/odoo/odoo-server.log` is added.

Desired behavior after PR is merged:
The Logs can be downloaded from the IoT box form view without receiving an Internal Server Error.

opw-4443593

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

Forward-Port-Of: odoo/odoo#192986
Forward-Port-Of: odoo/odoo#192867

Before this commit, if there was a custom one2many field with the same related field as an existing one, it would cause issues in PoS when capturing an order. For example, if there was a custom field in pos.order with a related field of order_id, adding products to the order would not show them in the order summary. opw-4462991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193041

Before this commit, if there was a custom one2many field with the same related field as an existing one, it would cause issues in PoS when capturing an order. For example, if there was a custom field in pos.order with a related field of order_id, adding products to the order would not show them in the order summary.

opw-4462991

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

Forward-Port-Of: odoo/odoo#193041

Issue: ======= Combo product lines in the POS frontend displayed incorrect prices when order from self Order Cause: ======= The `price_unit` was being calculated without considering the `combo_item_id`. For example: price_unit += pos_order_line.combo_price + price_extra_child` Fix: ===== The `combo_item_id` was included in the calculation to ensure accuracy: price_unit += pos_order_line.`combo_item_id`.combo_price + price_extra_child Task-4464002 Forward-Port-Of: odoo/odoo#194

Issue:
=======
Combo product lines in the POS frontend displayed incorrect prices when order from self Order

Cause:
=======
The `price_unit` was being calculated without considering the `combo_item_id`. For example:
price_unit += pos_order_line.combo_price + price_extra_child`

Fix:
=====
The `combo_item_id` was included in the calculation to ensure accuracy: price_unit += pos_order_line.`combo_item_id`.combo_price + price_extra_child

Task-4464002

Forward-Port-Of: odoo/odoo#194182
Forward-Port-Of: odoo/odoo#193356

When you made a downpayment on an order that contained product with fixed amount taxes, the tax would be paid multiple times. Steps to reproduce: ------------------- * Create a tax T1 with a fixed amount of 10€ * Create a product P1 using the tax T1 * Make a sale order and add the product P1 to it * Open PoS and make a downpayment for the sale order (e.g 50%) * You will already pay the 10€ of tax * Now if you make a second downpayment (e.g. 10%) > Observation: You still have the 10€ t

When you made a downpayment on an order that contained product with fixed amount taxes, the tax would be paid multiple times.

Steps to reproduce:
-------------------
* Create a tax T1 with a fixed amount of 10€
* Create a product P1 using the tax T1
* Make a sale order and add the product P1 to it
* Open PoS and make a downpayment for the sale order (e.g 50%)
* You will already pay the 10€ of tax
* Now if you make a second downpayment (e.g. 10%)
> Observation: You still have the 10€ tax to pay

Why the fix:
------------
We match the behavior of sales app, and ignore the fixed price taxes when creating the downpayment lines.

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

Forward-Port-Of: odoo/odoo#186639
Forward-Port-Of: odoo/odoo#182380

Before this commit, the creation of an applicant though `message_new`, It would check for existing candidates but not for the company; however, if the company is different, an error would be raised upon applicant creation and prevent it. This commit adds the company to the candidate check to avoid raising the constraint, and adjusts the said constraint so that it allows linking to candidates with no company set. Forward-Port-Of: odoo/odoo#193769

Before this commit, the creation of an applicant though `message_new`, It would check for existing candidates but not for the company; however, if the company is different, an error would be raised upon applicant creation and prevent it.

This commit adds the company to the candidate check to avoid raising the constraint, and adjusts the said constraint so that it allows linking to candidates with no company set.

Forward-Port-Of: odoo/odoo#193769

When downloading an invoice from the POS on iOS the PoS would be reloaded after closing the download popup. Steps to reproduce: ------------------- * Open PoS on iOS * Make an order and invoice it > Observation: After closing the invoice you are back on the product screen Why the fix: ------------ We open the download invoice popup in a new tab so that the PoS is not reloaded after closing the popup. opw-4471713 Forward-Port-Of: odoo/odoo#194000

When downloading an invoice from the POS on iOS the PoS would be
reloaded after closing the download popup.

Steps to reproduce:
-------------------
* Open PoS on iOS
* Make an order and invoice it
> Observation: After closing the invoice you are back on the product
screen

Why the fix:
------------
We open the download invoice popup in a new tab so that the PoS is not
reloaded after closing the popup.

opw-4471713

Forward-Port-Of: odoo/odoo#194000

Before this commit, markers on the location selector map were misaligned. The misalignment was proportional to the zoom level, as the marker incorrectly used the top-left corner of the anchor as its reference. This commit resolves the issue by defining the correct icon anchor position for markers. Forward-Port-Of: odoo/odoo#193982

Before this commit, markers on the location selector map were misaligned. The misalignment was proportional to the zoom level, as the marker incorrectly used the top-left corner of the anchor as its reference.

This commit resolves the issue by defining the correct icon anchor position for markers.

Forward-Port-Of: odoo/odoo#193982

Currently, for products with variants, the quantities on hand displayed in the product configurator can be incorrect. ### Steps to reproduce * Install `point_of_sale`. * Start the furniture shop POS session. * Click on the Conference Chair; the steel legs are selected by default, and the system displays quantities on hand as 30. * Switch to aluminum legs; the quantity remains 30. * Switch back to steel legs. You should see that the quantity on hand is now 26. This is the actual, cor

Currently, for products with variants, the quantities on hand displayed in the product configurator can be incorrect.

### Steps to reproduce

* Install `point_of_sale`.
* Start the furniture shop POS session.
* Click on the Conference Chair; the steel legs are selected by default, and the system displays quantities on hand as 30.
* Switch to aluminum legs; the quantity remains 30.
* Switch back to steel legs.

You should see that the quantity on hand is now 26. This is the actual, correct quantity for steel legs. The originally displayed value of 30 was already incorrect for those legs.

### Cause

The issue arises from how the product's quantities on hand are fetched and updated:

- The `useEffect` hook is used to fetch quantities on hand whenever the product changes.
- However, the function used to retrieve these quantities (`fetchStock`) is wrapped with `useTrackedAsync`, which internally utilizes `useAsyncLockedMethod`.
- The `useAsyncLockedMethod` hook ensures that two calls to `fetchStock` cannot run simultaneously; if `fetchStock` is called while another call is still in progress, the subsequent call is ignored.

This behavior causes the problem. In the product attribute component, the `useEffect` hook is triggered twice in rapid succession when switching attributes. Since the second `fetchStock` call happens before the first completes, it is discarded due to the locking mechanism. As a result, the product changes twice, but the stock fetching process is executed only once, causing a mismatch between the selected product variant and its displayed quantities on hand.

### Fix

The `useTrackedAsync` utility was updated to allow specifying the locking mechanism. Specifically, it now supports an option to keep the last call instead of the first. This change ensures that even when multiple `fetchStock` calls are triggered in quick succession, the most recent call is executed, maintaining synchronization between the product variant and the displayed stock quantities.

opw-4421070

Forward-Port-Of: odoo/odoo#193980

'TestQwebFieldContact' used a demo partner to work, but we want to test independent of demo data. Forward-Port-Of: odoo/odoo#193716

'TestQwebFieldContact' used a demo partner to work, but we want to test independent of demo data.

Forward-Port-Of: odoo/odoo#193716

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

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

Problem --------- When you use a Invoice report with the checkbox "Invoice report" unselected (misconfiguration), you get a traceback. Objective --------- Replace it with an error message instead, saying there's no invoice report configured in the database. Solution --------- Turn the asserts into a if condition that raises a user error. task-4421065 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192920

Problem
---------
When you use a Invoice report with the checkbox "Invoice report" unselected (misconfiguration), you get a traceback.

Objective
---------
Replace it with an error message instead, saying there's no invoice report configured in the database.

Solution
---------
Turn the asserts into a if condition that raises a user error.

task-4421065

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

Forward-Port-Of: odoo/odoo#192920

The `test_01_online_payment_with_multi_table` fails in runbot when running in "no-demo" mode. This is because it's not using the correct setup for testing restaurant configs. We ensure, in this commit, that the test uses the correct setup for testing by inheriting from the pos_restaurant's TestFrontendCommon. The total amount in the tour is adjusted because the test product from the default setup has no tax. Runbot Error: [111171](https://runbot.odoo.com/odoo/runbot.build.error/111171) Fo

The `test_01_online_payment_with_multi_table` fails in runbot when running in "no-demo" mode. This is because it's not using the correct setup for testing restaurant configs.

We ensure, in this commit, that the test uses the correct setup for testing by inheriting from the pos_restaurant's TestFrontendCommon. The total amount in the tour is adjusted because the test product from the default setup has no tax.

Runbot Error: [111171](https://runbot.odoo.com/odoo/runbot.build.error/111171)

Forward-Port-Of: odoo/odoo#193194

Fix issue that was always displaying popup "The session is being closed by another user. The page will be reloaded." each time you close a session. Now the `login_number` is correctly send in the context and can then be used inside `close_session_from_ui` correctly. task-id: 4485659 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.co

Fix issue that was always displaying popup "The session is being closed by another user. The page will be reloaded." each time you close a session. Now the `login_number` is correctly send in the context and can then be used inside `close_session_from_ui` correctly.

task-id: 4485659

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

## Commit 1: ### [FIX] account: Batch invoice sending when partner on "Download" Context: In 18.0, all batch/multiple invoice sending are processed asynchronously, we never directly download the generated PDF/XML files. The sending method that is used depends on what is set on the partner. Problem: If you set your partner to "Download" by default, in the batch Send & Print, it will display "You are about to send: x invoice(s) Download". While it's actually not downloading, only gen

## Commit 1: 
### [FIX] account: Batch invoice sending when partner on "Download"

Context:
In 18.0, all batch/multiple invoice sending are processed asynchronously, we never directly
download the generated PDF/XML files. The sending method that is used depends on what is
set on the partner.

Problem:
If you set your partner to "Download" by default, in the batch Send & Print, it
will display "You are about to send: x invoice(s) Download". While it's actually
not downloading, only generating. In 18.1 we changed this to "Manual" which is better but
doesn't go well in a sentence.

Solution:
Let's align everything to "Manually" in batch sending to avoid confusion.

Before:
![image](https://github.com/user-attachments/assets/9048c5bd-0e5f-4c25-a816-3c941bec7fce)

After:
![image](https://github.com/user-attachments/assets/8a4201f4-e4be-4c0d-b801-83815b337352)


opw-4315079

## Commit 2: 
###[IMP] l10n_it_edi: Add possibility to download in batch XML FatturaPA
Context:
In 18.0, when sending invoices in batch, we never download a zip of all generated
files (PDF, XML) since we always process invoices asynchronously with the partner's
sending method set on the partner's form.

Problem:
It's no longer possible to retrieve all XML Fattura PA at once.

Solution:
Add a button under the "Print/Download" button to download them all.

opw-4315079

## Commit 3:
### [FIX] l10n_it_edi: Fix error message display in Print & Send
The italian error dict does not comply to the default format expected
by the generic Print & Send. It displays the key of the error
instead of the message.
Before:
![it_error_msg_pre](https://github.com/user-attachments/assets/22707d0d-95b4-4b74-b31f-b4bc3ba334fd)
After:
![it_error_msg_post](https://github.com/user-attachments/assets/e32eef16-14d5-4462-96cc-c8e5ede5feb7)

task-no

Forward-Port-Of: odoo/odoo#192473

Versions -------- - saas-17.4+ Steps ----- 1. Create a new quotation template; 2. add a header which uses the `date_order` field; 3. configure the mapping from this form field to the record field; 4. print the quotation template. Issue ----- The datetime is formatted as "Jan 16, 2025, 5:59:26 PM", which is different from how dates are formatted, or how datetimes are usually formatted elsewhere in Odoo. Additionally, it may also be too long to fit in the form field. Cause --

Versions
--------
- saas-17.4+

Steps
-----
1. Create a new quotation template;
2. add a header which uses the `date_order` field;
3. configure the mapping from this form field to the record field;
4. print the quotation template.

Issue
-----
The datetime is formatted as "Jan 16, 2025, 5:59:26 PM", which is different from how dates are formatted, or how datetimes are usually formatted elsewhere in Odoo.

Additionally, it may also be too long to fit in the form field.

Cause
-----
The `format_datetime` function is used without a `dt_format` specified, falling back on the default `'medium'`: https://github.com/odoo/odoo/blob/cbd5531697954ec62d79e0eec2c00bd61cd8b0e4/odoo/tools/misc.py#L1399

Solution
--------
In order to get the format defined for the relevant locale in Odoo, `dt_format=False` should be specified in the `format_datetime` call: https://github.com/odoo/odoo/blob/cbd5531697954ec62d79e0eec2c00bd61cd8b0e4/odoo/tools/misc.py#L1427-L1430

opw-4414688

Forward-Port-Of: odoo/odoo#194113
Forward-Port-Of: odoo/odoo#194016

For Belgium, combination of taxes and their deductibility are many. While our system of Distribution lines can be used in many cases, it's not easy or intuitive to configure, even for advanced accountants. This commit aims at making sure: - The most useful taxes are active by default - We provide a few examples of the most commonly used Deductible taxes as well as examples of specific cases (Deductible IntraCom taxes). task-id 4417039 Forward-Port-Of: odoo/odoo#194183 Forward-Port-Of: o

For Belgium, combination of taxes and their deductibility are many. While our system of Distribution lines can be used in many cases, it's not easy or intuitive to configure, even for advanced accountants.

This commit aims at making sure:
- The most useful taxes are active by default
- We provide a few examples of the most commonly used Deductible taxes as well as examples of specific cases (Deductible IntraCom taxes).

task-id 4417039

Forward-Port-Of: odoo/odoo#194183
Forward-Port-Of: odoo/odoo#191350

On smaller screen, the statbuttons are grouped in a dropdown (the "lightning" icon) and displayed in two columns. But when only one button is present, it leaves a weird empty cell next to it. This commit fixes it by adding an exception in CSS when only one button is present to remove the useless column and center it. Note: this change doesn't affect the empty cell when an odd number of buttons are displayed. task-4491705 Forward-Port-Of: odoo/odoo#194083

On smaller screen, the statbuttons are grouped in a dropdown (the
"lightning" icon) and displayed in two columns.

But when only one button is present, it leaves a weird empty cell next
to it.

This commit fixes it by adding an exception in CSS when only one button
is present to remove the useless column and center it.

Note: this change doesn't affect the empty cell when an odd number of
buttons are displayed.

task-4491705

Forward-Port-Of: odoo/odoo#194083

**Problem**: When `lot['lot_record'].product_id.valid_ean` is `False`, the `final_barcode` variable retains the value from the previous iteration. This leads to incorrect concatenation with the current `lot['name']` when `lot['lot_record'].product_id.tracking == 'lot'`. **Solution**: Reset the `final_barcode` variable at the start of each iteration. **Steps to Reproduce**: 1. Go to Inventory > Settings and enable "Print GS1 Barcodes for Lots & Serial Numbers". 2. Navigate to Inventory

**Problem**:
When `lot['lot_record'].product_id.valid_ean` is `False`, the `final_barcode` variable retains the value from the previous iteration. This leads to incorrect concatenation with the current `lot['name']` when `lot['lot_record'].product_id.tracking == 'lot'`.

**Solution**:
Reset the `final_barcode` variable at the start of each iteration.

**Steps to Reproduce**:
1. Go to Inventory > Settings and enable "Print GS1 Barcodes for Lots & Serial Numbers".
2. Navigate to Inventory > Products > Lots/Serial Numbers.
3. Select all records and click Print > Lot/Serial Number (ZPL).
4. Observe that some barcodes incorrectly include the previous barcode as a prefix.

opw-4437745

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

Forward-Port-Of: odoo/odoo#193519
Forward-Port-Of: odoo/odoo#192651

In the forward port #190318 while fixing conflict, a new empty file from another projet was accedentally sled in the commit. This commit removes this empty useless file. Forward-Port-Of: odoo/odoo#193907

In the forward port #190318 while fixing conflict, a new empty file from another projet was accedentally sled in the commit. This commit removes this empty useless file.

Forward-Port-Of: odoo/odoo#193907

Have the edited document in an iframe. Spawn the Powerbox, Scroll the powerbox. Without letting the mouse out of the powerbox, try to hover a command Before this commit, this did not work. It was because of a piece of code that prevents selection of commands during scrolling, probably to avoid re-renders. After this commit, this use case works as expected. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:

Have the edited document in an iframe.
Spawn the Powerbox, Scroll the powerbox.

Without letting the mouse out of the powerbox, try to hover a command

Before this commit, this did not work. It was because of a piece of code that prevents selection of commands during scrolling, probably to avoid re-renders.

After this commit, this use case works as expected.

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

Issue: when the website has a domain `get_base_url` return the domain if the record calling it has a company set on it - call the function with an empty object to get the database url instead Task: 3903743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193951 Forward-Port-Of: odoo/odoo#193182

Issue: when the website has a domain `get_base_url` return the domain if the record calling it has a company set on it

- call the function with an empty object to get the database url instead

Task: 3903743



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

Forward-Port-Of: odoo/odoo#193951
Forward-Port-Of: odoo/odoo#193182

When a user disconnects, a message is sent on the bus. If another device is active, he will correct the user status. However, it can happen that this message is lost. For instance, when the bus table is cleared while the user is disconnected. Other parts of the code will update the user status, but the status will never be corrected. This PR react to the user status changes to solve this issue. opw-4484966 Description of the issue/feature this PR addresses: Current behavior before PR

When a user disconnects, a message is sent on the bus. If another device is active, he will correct the user status. However, it can happen that this message is lost. For instance, when the bus table is cleared while the user is disconnected. Other parts of the code will update the user status, but the status will never be corrected.

This PR react to the user status changes to solve this issue.

opw-4484966

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

Before this commit, when dragging participant cards on mobile they will get dragged off screen. 1. Open discuss on mobile 2. Get into a call 3. Move the participant cards -> they will disappear This happens because the `drag` function gets called without checking if the participant card is in the inset state (the state in which it can be moved around). This commit fixes the issue by checking that the component is in that state before being able to drag it. task-4491597 Forward-Port-Of

Before this commit, when dragging participant cards on mobile they will get dragged off screen.
1. Open discuss on mobile
2. Get into a call
3. Move the participant cards -> they will disappear

This happens because the `drag` function gets called without checking if the participant card is in the inset state (the state in which it can be moved around).
This commit fixes the issue by checking that the component is in that state before being able to drag it.

task-4491597

Forward-Port-Of: odoo/odoo#194075

This is distracting for end users, restrict it to the discuss app. Also reduce its style so this feels less aggressive. Forward-Port-Of: odoo/odoo#194166

This is distracting for end users, restrict it to the discuss app. Also reduce its style so this feels less aggressive.

Forward-Port-Of: odoo/odoo#194166

Before this commit, when some conversations were open in chat windows and the full composer was open in a chatter, the content of full composer message composition could be duplicated in other conversation composers. Steps to reproduce: - open a discuss conversation in chat window - open a form view with chatter - quickly perform these actions in a 5 seconds window: - type something in composer of discuss chat window - clear content in composer of discuss chat window - open basic

Before this commit, when some conversations were open in chat windows and the full composer was open in a chatter, the content of full composer message composition could be duplicated in other conversation composers.

Steps to reproduce:
- open a discuss conversation in chat window
- open a form view with chatter
- quickly perform these actions in a 5 seconds window:
  - type something in composer of discuss chat window
  - clear content in composer of discuss chat window
  - open basic composer of chatter then type something
  - open the full composer
- wait about 5 seconds, then open a new browser tab with the same URL
=> the chat window of discuss conversation contains the full composer text content

This happens because when some content is typed in the non-full composer, the text content is regularly saved in local storage so that content is not lost on page reload.

The saving is debounced 5 seconds whenever the user types something.

The full composer must also be saved & restored in chatter, as this is also a frequent point of typing long messages and content may be lost without the save & restore feature.
The code to handling it was poorly written and forgot to assume there could be more than 1 composer open at once: whenever a save content in composer is in progress, it was simply checking whether a full composer is open, and if so it was simply saving the full composer content.

This explains the problem in the scenario above: when typing in discuss conversation in chat window, the save content is triggered after 5 seconds. The opening of full composer disrupts the discuss conversation composer content saving by not saving the discuss conversation composer but instead the full composer content in it.

This commit fixes the issue by enforcing debounce saving to save the content in the current composer. The full composer was never intended to be implied in the debounced save content, only the basic composer is. The full composer saving content works differently: whenever the full composer is closed in non-discard way the save of full composer in basic composer must happen.

Task-4485021

![Jan-16-2025 12-38-38](https://github.com/user-attachments/assets/1637bebe-e3e0-41f5-8cdf-24f3264b4318)

Forward-Port-Of: odoo/odoo#193936

Before this commit, during a discuss call while sharing screen and enabling camera, the inset card (= small video stream preview in bottom right of call view of the participant, either camera or screen-sharing depending on other stream being main active) was flickering. This happens because each rendering of the call view re-renders the inset, which leads to the perceived flickers from stream being re-rendered. The main cause of re-render comes from `setInset()` that is invoked whenever th

Before this commit, during a discuss call while sharing screen and enabling camera, the inset card (= small video stream preview in bottom right of call view of the participant, either camera or screen-sharing depending on other stream being main active) was flickering.

This happens because each rendering of the call view re-renders the inset, which leads to the perceived flickers from stream being re-rendered.

The main cause of re-render comes from `setInset()` that is invoked whenever the `visibleMainCards` getter is called with inset, which is triggered on renderings like mouse-hovering on call view to display the call actions. Even when the inset card is unchanged, `setInset()` produces another object, which forces OWL to re-render the inset component.

This commit fixes the issue by having `setInset` reusing the inset data object if the inset to render refers to the same inset session.

Task-4484908

Forward-Port-Of: odoo/odoo#194103

Before this commit, if the user alters the grid view to have this kind of ranges: ```xml <range name="month" string="Month" span="month" step="month"/> ``` the `step="month"` will not be used to load the data for the grid view and will continue to load data per day (when this range is the current one in the grid view). This commit makes sure the step is correctly used to fetch the data for each columns displayed in the grid view (in this case only one column for the whole month should b

Before this commit, if the user alters the grid view to have this kind of ranges:

```xml
<range name="month" string="Month" span="month" step="month"/>
```
the `step="month"` will not be used to load the data for the grid view and will continue to load data per day (when this range is the current one in the grid view).

This commit makes sure the step is correctly used to fetch the data for each columns displayed in the grid view (in this case only one column for the whole month should be displayed).

Forward-Port-Of: odoo/enterprise#75056

Steps: - Install the hr_payroll module - Open the payslip form view - click on print --- Description of the issue/feature this PR addresses: When the schedule pay on a contract is set to anything other than `Monthly` (e.g., bi-weekly), the PDF report incorrectly displays `Monthly`. This happens because the report only considers the wage type (monthly or hourly) and does not take the schedule pay into account. --- Fix: This PR addresses the issue by including the schedule pay type

Steps:
- Install the hr_payroll module
- Open the payslip form view
- click on print

 --- 
Description of the issue/feature this PR addresses:
When the schedule pay on a contract is set to anything other than `Monthly` (e.g., bi-weekly), the PDF report incorrectly displays `Monthly`. This happens because the report only considers the wage type (monthly or hourly) and does not take the schedule pay into account.

 ---
Fix:
This PR addresses the issue by including the schedule pay type in the PDF report when the wage type is set to `Monthly`.

task-4332531

Forward-Port-Of: odoo/enterprise#75342

In the document layout configurator, the paper format A4 would not be there if the module l10n_be_hr_payroll is installed. This is because in Belgium, some reports need A4 but in the configurator, we only get paperformat not linked to any report. The solution is to remove the domain for this field in the configurator. Since there will be more paper formats, I renamed the newly created formats in the Belgian payroll to differentiate them. Forward-Port-Of: odoo/enterprise#71649

In the document layout configurator, the paper format A4 would not be there if the module l10n_be_hr_payroll is installed.

This is because in Belgium, some reports need A4 but in the configurator, we only get paperformat not linked to any report.

The solution is to remove the domain for this field in the configurator.

Since there will be more paper formats, I renamed the newly created formats in the Belgian payroll to differentiate them.

Forward-Port-Of: odoo/enterprise#71649

In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 Forward-Port-Of: odoo/enterprise#77130 Forward-Port-Of: odoo/enterprise#76522

In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice).

This commit aims to give a single and unified way to display them.

ticket-4440711

Forward-Port-Of: odoo/enterprise#77130
Forward-Port-Of: odoo/enterprise#76522

… technical In Odoo 18 > Benchmark dashboard does not show the correct balance per account type when the language is not English. The problem is we have a =_t(value) function that translate the technical name (C30:C47) opw-4484934 Task: 4484934 Forward-Port-Of: odoo/enterprise#77163

… technical

In Odoo 18 > Benchmark dashboard does not show the correct balance per account type when the language is not English.

The problem is we have a =_t(value) function that translate the technical name (C30:C47)

opw-4484934
Task: 4484934

Forward-Port-Of: odoo/enterprise#77163

When validating the payment CFDI in multicurrency scenario (invoice in USD, payment in MXN), we should provide the official convertion rate in the equivalenciaDR xml attribute. However, this is not always possible due to rounding: PACs with lower error tolerance (Quadrum) will not validate the payment Steps to reproduce: - With an MX company setup - Set the following rates for USD - Date 1: 0.049905678268 - Date 2: 0.049073733284 - Create an invoice in date1 of 6368.40 USD (5490.00 w

When validating the payment CFDI in multicurrency scenario (invoice in USD, payment in MXN), we should provide the official convertion rate in the equivalenciaDR xml attribute. However, this is not always possible due to rounding: PACs with lower error tolerance (Quadrum) will not validate the payment

Steps to reproduce:
- With an MX company setup
- Set the following rates for USD
  - Date 1: 0.049905678268
  - Date 2: 0.049073733284
- Create an invoice in date1 of 6368.40 USD (5490.00 with 16% tax)
- Register a full payment in date 2 in company currency (129772.07 MXN) Issue: Payment CFDI will not validate when using Quadrum PAC with error

```
Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de los
importes de las bases registrados en los documentos relacionados donde el impuesto del
documento relacionado sea igual al campo ImpuestoP de este elemento y la TasaOCuotaDR
del documento relacionado sea igual al campo TasaOCuotaP de este elemento.
```

This occurs because when computing cfdi values we take the invoice (rounded) amounts and recompute the amount in mxn using the official currency rate. While doing so, due to rounding, we accumulate imprecision, the final computation might be off by a cent or two and PACs with a lower error tolerance (Quadrum) will not be able to validate the cfdi.

A solution is to internally use the computed rate, while we provide the official currency rate in the xml

opw-4357985

Forward-Port-Of: odoo/enterprise#76987
Forward-Port-Of: odoo/enterprise#76333

- Install `web_studio` and `l10n_ke_edi_oscu` - Open the report editor from anywhere - Search for report_invoice - Open it - Traceback This is caused by the div inside the table, this is incorrect in HTML See https://html.spec.whatwg.org/multipage/tables.html#the-table-element replace with a tr/td opw-4369019 Forward-Port-Of: odoo/enterprise#77132

- Install `web_studio` and `l10n_ke_edi_oscu`
    - Open the report editor from anywhere
    - Search for report_invoice
    - Open it
    - Traceback

This is caused by the div inside the table, this is incorrect in HTML

See https://html.spec.whatwg.org/multipage/tables.html#the-table-element

replace with a tr/td

opw-4369019

Forward-Port-Of: odoo/enterprise#77132

In this PR: - Refactored error handling for better clarity and organization. - Grouped errors by section and invoice for structured reporting. - Added clickable invoice links in error messages for easy navigation. - Scheduled detailed activities for invoices with errors. - Enhanced code readability and maintainability. This ensures clearer error reports, efficient activity creation, and easier future updates. Forward-Port-Of: odoo/enterprise#76880

In this PR:
- Refactored error handling for better clarity and organization.
- Grouped errors by section and invoice for structured reporting.
- Added clickable invoice links in error messages for easy navigation.
- Scheduled detailed activities for invoices with errors.
- Enhanced code readability and maintainability.

This ensures clearer error reports, efficient activity creation, and easier
future updates.

Forward-Port-Of: odoo/enterprise#76880

## Description Following 9a8777b4b96367597418cdc1c1ffc7ea3264113f, the criteria on the `move_type` of the invoices used in `sale.commission.report` was changed from `'out_invoice'` to `'out_invoice' AND 'out_refund'`, but the respective index `account_move_invoice_user_id_date_idx` partial clause hasn't been updated, leading to Postgres not being able to use the index, leading to a performance regression. We're updating both custom indexes partial clause to match the invoice `move_type` conditi

## Description
Following 9a8777b4b96367597418cdc1c1ffc7ea3264113f, the criteria on the `move_type` of the invoices used in `sale.commission.report` was changed from `'out_invoice'` to `'out_invoice' AND 'out_refund'`, but the respective index `account_move_invoice_user_id_date_idx` partial clause hasn't been updated, leading to Postgres not being able to use the index, leading to a performance regression. We're updating both custom indexes partial clause to match the invoice `move_type` condition used in the reporting.

## Benchmark
On a large database with millions of invoices and customers

| Timings (hot) | Before | After |
|---------------|--------|-------|
| 1 read_group  | 40s    | 1s    |
| full load     | 225s   | 6s    |

## Reference
task-4448879

Forward-Port-Of: odoo/enterprise#76723

When a user create the first payment initiation with Ponto he need to do the KYC of Ponto. The issue is that today we initiate the payment and then start the process of KYC. Following that the first payment is always in error, because it was initiated before the KYC. In this commit, we create the payments only if the KYC is done. task-4476856 Forward-Port-Of: odoo/enterprise#77052

When a user create the first payment initiation with Ponto he need to do the KYC of Ponto. The issue is that today we initiate the payment and then start the process of KYC. Following that the first payment is always in error, because it was initiated before the KYC.

In this commit, we create the payments only if the KYC is done.

task-4476856

Forward-Port-Of: odoo/enterprise#77052

Currently, an error occurs when opening a preview of an invoice without an invoice date Step to produce: - Install the `l10n_ec_edi` module (with demo data). - Change a current company to 'EC Company', which has an 'Ecuador' country. - Create a new invoice, add a customer name, payment terms, and invoice line, save the record, - Click on the 'Preview' button (ensure that the invoice has no date). ```TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'``` An err

Currently, an error occurs when opening a preview of an invoice without an invoice date

Step to produce:

- Install the `l10n_ec_edi` module (with demo data).
- Change a current company to 'EC Company', which has an 'Ecuador' country.
- Create a new invoice, add a customer name, payment terms, and invoice line, save the record,
- Click on the 'Preview' button (ensure that the invoice has no date).

```TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'```

An error occurs when the system attempts to calculate payment term days at [1], with using an invoice date, but it is not available.

Link [1]: https://github.com/odoo/enterprise/blob/26aa95079af2a868c2991c7f19daee5328d5bb01/l10n_ec_edi/models/account_move.py#L440C22-L440C93

To resolve this issue, Provide a default day zero(0) for the payment term, if invoice date is not available.

Sentry-6015854429

Forward-Port-Of: odoo/enterprise#76881
Forward-Port-Of: odoo/enterprise#72864

*: frontdesk, hr_contract_salary, hr_referral Issue: when the website has a domain `get_base_url` return the domain if the record calling it has a company set on it - call the function with an empty object to get the database url instead Task: 3903743 Forward-Port-Of: odoo/enterprise#77256 Forward-Port-Of: odoo/enterprise#76888

*: frontdesk, hr_contract_salary, hr_referral

Issue: when the website has a domain `get_base_url` return the domain if the record calling it has a company set on it

- call the function with an empty object to get the database url instead

Task: 3903743

Forward-Port-Of: odoo/enterprise#77256
Forward-Port-Of: odoo/enterprise#76888

When the user clicks on the ``Process now`` button, a traceback will appear. Steps to reproduce the error: - Install ``l10n_ec_edi`` module > Switch to EC Company - Create a new invoice > Add Payment Method (SRI) > Confirm - Go to Configuration > Settings > SRI Connection > enable ``Use production servers`` > Save - Go back to the invoice > Request EDI Cancellation > Process now Traceback: ``` File "home/odoo/src/enterprise/18.0/l10n_ec_edi/models/account_edi_format.py", line 525, i

When the user clicks on the ``Process now`` button,
a traceback will appear.

Steps to reproduce the error:
- Install ``l10n_ec_edi`` module > Switch to EC Company
- Create a new invoice > Add Payment Method (SRI) > Confirm
- Go to Configuration > Settings > SRI Connection > enable ``Use production servers`` > Save
- Go back to the invoice > Request EDI Cancellation > Process now

Traceback:
```
File "home/odoo/src/enterprise/18.0/l10n_ec_edi/models/account_edi_format.py", line 525, in _l10n_ec_get_authorization_status_new
    response_auth_list = response['autorizaciones'] and response['autorizaciones']['autorizacion'] or []
TypeError: 'NoneType' object is not subscriptable
```

https://github.com/odoo/enterprise/blob/2e1af04e36fcbdcd11e3a7e2994673b2c4a5cf85/l10n_ec_edi/models/account_edi_format.py#L525
When there is any kind of connection error, the ``response`` will be ``None``,
which will result in the above traceback.

sentry-6199991614

Forward-Port-Of: odoo/enterprise#76614