When making a payment from the PoS, the user would always be the Public User. This would cause the payload sent to paypal to be incorrect and the payment to fail. This happens because we are trying to make a payment without any user, so this can be reproduced in other workflows. Like making a donation Steps to reproduce: ------------------- * Setup paypal payment provider * Create a PoS payment method with the paypal provider * Create a PoS order and pay with the paypal payment method

When making a payment from the PoS, the user would always be the Public
User. This would cause the payload sent to paypal to be incorrect and
the payment to fail.
This happens because we are trying to make a payment without any user,
so this can be reproduced in other workflows. Like making a donation

Steps to reproduce:
-------------------
* Setup paypal payment provider
* Create a PoS payment method with the paypal provider
* Create a PoS order and pay with the paypal payment method
> Observation: You get an error saying that something is malformed

Alternative steps to reproduce:
--------------------------------
* Make sure you are not connected on Odoo
* Go to the `donation/pay` url
* Fill out the form and make the payment via paypal
> Observation: You get an error saying that something is malformed

Why the fix:
------------
When using the public user, we cannot provide an email address or a
country code. To fix this we make sure to not send the email address at
all when there is none available. And we send the country code of the
company instead of none.

opw-4446219

Forward-Port-Of: odoo/odoo#198407

We already added an alias to reset odoo on a development branch (odoo-dev), this commit brings the equivalent to reset on a public version on odoo. Task: 4593093 Forward-Port-Of: odoo/odoo#198856

We already added an alias to reset odoo on a development branch (odoo-dev), this commit brings the equivalent to reset on a public version on odoo.

Task: 4593093

Forward-Port-Of: odoo/odoo#198856

In `account.move.line` views, the `account_id` fields that have a `domain` attribute need to filter for `company_ids` in the domain, since the check_company domain is overriden by the domain in the field. We removed these domains in odoo#171079 thinking that check_company=True would automatically add them. But it doesn't, so we must revert that change. Otherwise, the user can select accounts that don't belong to the current invoice / vendor bill / journal entry's company. task-none For

In `account.move.line` views, the `account_id` fields that have a `domain` attribute need to filter for `company_ids` in the domain, since the check_company domain is overriden by the domain in the field.

We removed these domains in odoo#171079 thinking that check_company=True would automatically add them. But it doesn't, so we must revert that change.

Otherwise, the user can select accounts that don't belong to the current invoice / vendor bill / journal entry's company.

task-none

Forward-Port-Of: odoo/odoo#198715
Forward-Port-Of: odoo/odoo#198645

Before this commit, when the user validates a stock picking and that user does not have access to sales app, he will get a traceback if `sale_project_stock` module is installed because the `reinvoiced_sale_order_id` field of the project linked to the picking and that field required the user to have sale access to access to it. This commit adds a sudo to generate eventual SOLs to reinvoice the stock move when the user without any access to Sales validates the stock picking. Steps to reprod

Before this commit, when the user validates a stock picking and that user does not have access  to sales app, he will get a traceback if `sale_project_stock` module is installed because the `reinvoiced_sale_order_id` field of the project linked to the picking and that field required the user to have sale access to access to it.

This commit adds a sudo to generate eventual SOLs to reinvoice the stock move when the user without any access to Sales validates the stock picking.

Steps to reproduce the issue:
----------------------------

1. Create a sales order with a storable product
2. and Service product that creates a task in the Field service project
3. After confirming this SO, a task is created => assign Demo to this task and demo doesn't have Sales access right
4. Login as demo, trying to validate the delivery from this task

opw-4590044

Forward-Port-Of: odoo/odoo#198524

Since merging of this commit [1] formats can be applied on br tag. This doesn't work well if we have line-break br. This commit aims to make sure that format is applied only on brs indicating empty line and not on line-break br. [1]: https://github.com/odoo-dev/odoo/commit/df1dcf1c6bfc94ae8e084b41c1b5cc84b2cc5203 task-4399010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190796

Since merging of this commit [1] formats can be applied on br tag. This doesn't work well if we have line-break br. This commit aims to make sure that format is applied only on brs indicating empty line and not on line-break br.

[1]: https://github.com/odoo-dev/odoo/commit/df1dcf1c6bfc94ae8e084b41c1b5cc84b2cc5203


task-4399010




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

Forward-Port-Of: odoo/odoo#190796

Description of the issue/feature this PR addresses: This PR intends to fix an issue we encountered when you have CL localization installed with other LATAM localizations. The problem is that l10n_cl is modifying the visibility of the field "Document number" to appear when necessary directly on latam_invoice_document view. This make that the field visibility is being changed on other localizations as well when you have both installed. Current behavior before PR: The "Document Number" field

Description of the issue/feature this PR addresses:
This PR intends to fix an issue we encountered when you have CL localization installed with other LATAM localizations.
The problem is that l10n_cl is modifying the visibility of the field "Document number" to appear when necessary directly on latam_invoice_document view. This make that the field visibility is being changed on other localizations as well when you have both installed.

Current behavior before PR:
The "Document Number" field below "Document Type" should is present on uruguayan electronic invoices (where it should not be).

Desired behavior after PR is merged:
The "Document Number" field is present on chilean invoices as expected and not in uruguayan electronic invoices.

Steps to reproduce the error:
- Install l10n_uy
- On the UY company, go to Customer/Invoices section, create one, select a customer and check that you have an electronic journal selected. The field "Document Number" should not be present.
- Install l10n_cl
- Go to the previously created invoice and check that the field "Document Number" now appears. 

Ticket ADHOC side: 86491
Ticket Odoo side: 4505977


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

Forward-Port-Of: odoo/odoo#195902

Recent commit 27bf2e55810b200563ed6b93b1e22dfda65cf4ea modified the salesperson assignation on ecommerce orders, to avoid assigning any salesperson until the order confirmation. Nevertheless, this commit also disabled the salesteam recomputation on salesman change for ecommerce orders. In some cases (subscription orders), the salesperson might be manually changed on the order and we still want the right salesteam to be assigned on the order, even if it came from the ecommerce. This comm

Recent commit 27bf2e55810b200563ed6b93b1e22dfda65cf4ea modified the salesperson assignation on ecommerce orders, to avoid assigning any salesperson until the order confirmation.

Nevertheless, this commit also disabled the salesteam recomputation on salesman change for ecommerce orders.

In some cases (subscription orders), the salesperson might be manually changed on the order and we still want the right salesteam to be assigned on the order, even if it came from the ecommerce.

This commit adds a hook to allow subscription orders to keep the salesteam recomputation on salesman change for ecommerce orders.

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

Forward-Port-Of: odoo/odoo#195810

Splitting the function `click` on the Pricelist Button to make it inheritable, by creating a new function called `getPricelistList` that will allow filtering them whenever needed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196813 Forward-Port-Of: odoo/odoo#173010

Splitting the function `click` on the Pricelist Button to make it inheritable, by creating a new function called `getPricelistList` that will allow filtering them whenever needed.

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

Forward-Port-Of: odoo/odoo#196813
Forward-Port-Of: odoo/odoo#173010

Before this commit, when push notifications are enabled, receiving a new message in discuss, was not playing the "new-message" sound effect. This happens because when notifying new message, it plays the sound at the very end of processing of notify. However, the notify code was early returning in case it detects that there's push notification handled by service worker. This made sense because out-of-focus service has also some code for the showing of push notification, but this is redundan

Before this commit, when push notifications are enabled, receiving a new message in discuss, was not playing the "new-message" sound effect.

This happens because when notifying new message, it plays the sound at the very end of processing of notify. However, the notify code was early returning in case it detects that there's push notification handled by service worker.

This made sense because out-of-focus service has also some code for the showing of push notification, but this is redundant with the service worker behaviour on receiving the push notifcation.

However, the sound playing is still desirable, even though the service worker lacks this part of feature.

This commit fixes the issue by playing the sound effect of new message early.

Also some users really want no sound at all. This commit also adds a new entry "Message sound" in the Notification settings of Discuss to toggle enabling of new message sound (enabled by default).

By the way, the playing of new message sound should not be dependent on whether the user has focus or not: other messaging apps play the sound regardless of focus which makes more sense.

<img width="653" alt="Screenshot 2025-02-17 at 18 13 26" src="https://github.com/user-attachments/assets/33c40f91-0bb2-42ed-9181-7cbbe0b2e7c6" />

Forward-Port-Of: odoo/odoo#196030

Before this commit, although there is a signature loaded in the draw mode, the signature's isSignatureEmpty flag is true, which affects the logic that handles the sign buttons [enable/disable] state. After this commit, the isSignatureEmpty is handled correctly and the sign buttons' disability logic is clear. task-4466854 Related: https://github.com/odoo/enterprise/pull/77120 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o

Before this commit, although there is a signature loaded in the draw mode, the signature's isSignatureEmpty flag is true, which affects the logic that handles the sign buttons [enable/disable] state.
After this commit, the isSignatureEmpty is handled correctly and the sign buttons' disability logic is clear.

task-4466854
Related: https://github.com/odoo/enterprise/pull/77120

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

Forward-Port-Of: odoo/odoo#193788

## Commit 1: [IMP] account{,_edi_ubl_cii,_peppol}: Misc imps of the Print & Send - "What is Peppol" warning no longer appear on already sent invoices. - Remove the warning related to already existing PDF. This will be improved by the following task [1]. - Remove the warning related to bank accounts, this will be improved in the next commit of this PR. - Align warnings related to absence of EAS/Endpoint. - Move the "Test/Demo mode" warning next to the "by Peppol" label. - Remove the new

## Commit 1: [IMP] account{,_edi_ubl_cii,_peppol}: Misc imps of the Print & Send

- "What is Peppol" warning no longer appear on already sent invoices.
- Remove the warning related to already existing PDF. This will be improved
by the following task [1].
- Remove the warning related to bank accounts, this will be improved
in the next commit of this PR.
- Align warnings related to absence of EAS/Endpoint.
- Move the "Test/Demo mode" warning next to the "by Peppol" label.
- Remove the new "Print" button from draft invoices.

[1]: https://www.odoo.com/odoo/project/967/tasks/4498564
task-4478365
-----------------------------

## Commit 2: [IMP] account_{edi_ubl_cii,peppol}: Stop setting automatically an invoice edi format

In previous refactor[1], we set automatically an invoice EDI format.
This decision was too zealous considering the overall state of e-invoicing
and now cause more frictions than necessary.
We therefore decided to remove the automatic computation of EDI format on
partners.

[1]: https://github.com/odoo/odoo/commit/9e769e1b11f22890e5245859053bc8dd31e42634

task-4478365

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

## Commit 3: [FIX] account: remove partner_bank_id from readonly field of posted moves

In previous PR [1], we made the partner_bank_id field editable on
the invoice form as long as the move is not sent.
There was still a security check in place, let's remove it for this
field.

[1]: https://github.com/odoo/odoo/pull/195069
task-4478365

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

## Commit 4: [IMP] account_edi_ubl_cii: use code ZZZ instead of 30 if no bank account is set

To generate a valid BIS3 format, if we put 30 - credit transfer as payment means,
we need to have a bank account set. If it's not the case, it will raise an error.
We improve the usability by changing that code to ZZZ - mutually defined if no
bank account is provided to the invoice.

This should improve the onboarding flow when no bank account is set yet.

task-4478365

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

## Commit 5: [IMP] account_peppol: expand the countries where we display WhatIsPeppol banner

This list is based on recent usage statistics from OpenPeppol.

task-4478365

Forward-Port-Of: odoo/odoo#198162
Forward-Port-Of: odoo/odoo#196657

Before this commit and since [1], when inserting a banner at the top of the editable, a zero-width space (ZWS) was inserted before the banner to circuvent a Chromium bug that prevents fully selecting the banner with the mouse [2]. This led to the undesirable behavior of having a text node (with a ZWS) as the first child of the editable, creating a line above the banner and allowing for text insertion at the editable's root. This commit replaces the ZWS insertion with an empty paragraph, wh

Before this commit and since [1], when inserting a banner at the top of the editable, a zero-width space (ZWS) was inserted before the banner to circuvent a Chromium bug that prevents fully selecting the banner with the mouse [2].

This led to the undesirable behavior of having a text node (with a ZWS) as the first child of the editable, creating a line above the banner and allowing for text insertion at the editable's root.

This commit replaces the ZWS insertion with an empty paragraph, which can be later be moved around by the user.

[1]: https://github.com/odoo/odoo/commit/a0fcba694a8a23a947ba28d188d6806272627447
[2]: https://issues.chromium.org/issues/40822311

task-4512959

Forward-Port-Of: odoo/odoo#198531
Forward-Port-Of: odoo/odoo#195027

Before this commit, the mailbot was sending the wrong command to trigger the canned response. This commit fixes the command to be sent and updates the translations accordingly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198644

Before this commit, the mailbot was sending the wrong command to trigger the canned response. This commit fixes the command to be sent and updates the translations accordingly.


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

Forward-Port-Of: odoo/odoo#198644

It would help people to be able to search on the Total amount for invoices task-4575021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197744

It would help people to be able to search on the Total amount for invoices

task-4575021




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

Forward-Port-Of: odoo/odoo#197744

Before this commit, editing a message was always saving it with `Enter`, including in Chatter. This is a unintentional regression of https://github.com/odoo/odoo/pull/186084 that made improvements to composer. Sending messages in chatter uses `Ctrl-Enter`, and `Enter` is used to make new lines. In discuss channels, this is the opposite: `Enter` to send a message, and `Shift-Enter` to make new lines. This difference looks strange, but it makes actually sense: `Enter` is the fastest for quic

Before this commit, editing a message was always saving it with `Enter`, including in Chatter. This is a unintentional regression of https://github.com/odoo/odoo/pull/186084 that made improvements to composer.

Sending messages in chatter uses `Ctrl-Enter`, and `Enter` is used to make new lines. In discuss channels, this is the opposite: `Enter` to send a message, and `Shift-Enter` to make new lines.

This difference looks strange, but it makes actually sense: `Enter` is the fastest for quick chat messages, whereas `Ctrl-Enter` is more appropriate when making long formatted message, which is generally the case in chatter.

The editing of message in chatter should also use `Ctrl-Enter`, for consistency with posting a new message and also chatter messages are still long when editing them. This commit fixes this issue.

Task-4593105

Before
<img width="854" alt="Screenshot 2025-02-20 at 16 40 22" src="https://github.com/user-attachments/assets/9e9153a5-f67d-492b-9cac-ff74150f2873" />
After
<img width="841" alt="Screenshot 2025-02-20 at 16 40 00" src="https://github.com/user-attachments/assets/e879d0d9-223b-45df-8111-517b02f30377" />

Forward-Port-Of: odoo/odoo#198619

… taxes Bug introduced by https://github.com/odoo/odoo/commit/90949cd56da77da3645922f670f86483d7859c2f See tests in this commit for a concrete use case. opw-4571908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198805

… taxes

Bug introduced by https://github.com/odoo/odoo/commit/90949cd56da77da3645922f670f86483d7859c2f

See tests in this commit for a concrete use case.

opw-4571908

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

Forward-Port-Of: odoo/odoo#198805

As per the [government schema for json](https://einv-apisandbox.nic.in/version1.03/generate-irn.html#requestPayload), the pincode should be in range of 100000 and 999999 but in odoo we only validated string of 6 digit character Before this commit- if a partner with pincode `000000` then no validation error After this commit- if a partner with pincode `000000` invalid pincode validation raises Description of the issue/feature this PR addresses: Current behavior before PR: Desired

As per the [government schema for json](https://einv-apisandbox.nic.in/version1.03/generate-irn.html#requestPayload), the pincode should be in range of 100000 and 999999 but in odoo we only validated string of 6 digit character

Before this commit-
if a partner with pincode `000000` then no validation error

After this commit-
if a partner with pincode `000000` invalid pincode validation raises

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#198853
Forward-Port-Of: odoo/odoo#198302

Before this commit: Steps 1) Install the Turkish localization modules (l10n_tr, l10n_tr_nilvera) 2) Switch to TR company 3) Create a user without administration access 4) Try to open accounting module using the created user => An OwlError is raised with the message `Caused by: TypeError: Cannot read properties of undefined (reading 'raw_value')`, This occurs because the `l10n_tr_nilvera_api_key` field is restricted to admin users. As a result, non-admin users experience a broken journal

Before this commit:
Steps
1) Install the Turkish localization modules (l10n_tr, l10n_tr_nilvera) 
2) Switch to TR company
3) Create a user without administration access
4) Try to open accounting module using the created user

=> An OwlError is raised with the message `Caused by: TypeError: Cannot read properties of undefined (reading 'raw_value')`, This occurs because the `l10n_tr_nilvera_api_key` field is restricted to admin users. As a result, non-admin users experience a broken journal dashboard view due to missing access

After this commit:
The Accounting module and journal dashboard view work correctly for non-admin users

Reproducing the issue in Runbot: https://drive.google.com/file/d/1YIjvoXNDe6atVyzWC1dVU58rDFnoYH7x/view?usp=drive_link

opw-4551932

Forward-Port-Of: odoo/odoo#197520

When you have multiple payment methods that can work on the kiosk, they would all be shown on the kiosk screen. Steps to reproduce: ------------------- * Setup 2 Stripe payment methods * Create a PoS kiosk * Assign one of the methods to the kiosk * Open the kiosk * Create an order and go to the payment screen > Observation: Both payment methods are shown Why the fix: ------------ The payment methods are now filtered based on the payment methods assigned to the kiosk. opw-457464

When you have multiple payment methods that can work on the kiosk, they would all be shown on the kiosk screen.

Steps to reproduce:
-------------------
* Setup 2 Stripe payment methods
* Create a PoS kiosk
* Assign one of the methods to the kiosk
* Open the kiosk
* Create an order and go to the payment screen
> Observation: Both payment methods are shown

Why the fix:
------------
The payment methods are now filtered based on the payment methods assigned to the kiosk.

opw-4574644

Forward-Port-Of: odoo/odoo#198401
Forward-Port-Of: odoo/odoo#198046

This PR fixes several issues: - Clicking multiple times on a chat bot answer would lead to multiple messages being posted which could impact the chat bot flow. Disable the buttons once an answer has been selected. - Messages could be shown in an incorrect order when answering the first chat bot question. Ensure thread messages are properly loaded before posting the answer. - Chat window was flickering when persisting a temporary thread (replacing the temporary thread with the created

This PR fixes several issues:
- Clicking multiple times on a chat bot answer would lead to multiple
messages being posted which could impact the chat bot flow. Disable the
buttons once an answer has been selected.

- Messages could be shown in an incorrect order when answering the first
chat bot question. Ensure thread messages are properly loaded before posting
the answer.

- Chat window was flickering when persisting a temporary thread
(replacing the temporary thread with the created one). Ensure the thread
swap occurs when the created thread is fully ready, thus matching the
temporary thread visual and avoiding flickering.

task-4589418

Examples with slow 4g

| Before | After |
| ------------- | ------------- |
| ![chrome-capture-2025-2-20](https://github.com/user-attachments/assets/306e82f5-999d-421d-bfe0-3cf7958b6657)|![chrome-capture-2025-2-20 (1)](https://github.com/user-attachments/assets/e8e9d902-41df-4235-b26a-aa16c8ae0e2f) |

Forward-Port-Of: odoo/odoo#198280

In this commit: =============== taxed_lst_unit_price gives an error as this method got changed by getTaxedlstUnitPrice() so replaced taxed_lst_unit_price by getTaxedlstUnitPrice() Runbot error:110614,110615 Forward-Port-Of: odoo/odoo#198254

In this commit:
===============

taxed_lst_unit_price gives an error as this method got changed by getTaxedlstUnitPrice()
so replaced taxed_lst_unit_price by getTaxedlstUnitPrice()

Runbot error:110614,110615

Forward-Port-Of: odoo/odoo#198254

odoo/odoo#192897 introduced a new bug when trying to access the replenishment view without administrator rights due to a call to `ir.config.parameter` method `get_param` without sudo rights. opw-4583651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198233 Forward-Port-Of: odoo/odoo#198174

odoo/odoo#192897 introduced a new bug when trying to access the replenishment view without administrator rights due to a call to `ir.config.parameter` method `get_param` without sudo rights.

opw-4583651


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

Forward-Port-Of: odoo/odoo#198233
Forward-Port-Of: odoo/odoo#198174

The previous [fix](https://github.com/odoo/odoo/pull/195449) did not cover all cases. ### Steps to reproduce: - Go to Accounting > Reports > Aged Receivable - Unfold any customer shown, click on the three dots next to an invoice, and select "View Journal Entry" - On the Journal Entry, add the something to Customer Reference - Go back to the report, you should see the invoice name and Customer reference are shown twice ### Cause: The bug appeared in this commit (https://github.com/odoo

The previous [fix](https://github.com/odoo/odoo/pull/195449) did not cover all cases.

### Steps to reproduce:
- Go to Accounting > Reports > Aged Receivable
- Unfold any customer shown, click on the three dots next to an invoice, and select "View Journal Entry"
- On the Journal Entry, add the something to Customer Reference
- Go back to the report, you should see the invoice name and Customer reference are shown twice

### Cause:
The bug appeared in this commit (https://github.com/odoo/odoo/commit/eb872c09897eb9edd5b6e5b9e8171fa6764be3dc) when computing the line display_name, if there is a move name, a reference and `line_name`.

The variable `line_name` already include the reference: `name = f'{line.move_id.ref} - {line.move_id.payment_reference}'` (https://github.com/odoo/odoo/commit/a6cbb7c2d3538d57dc8498f0dacf4566ea1492e7)

So `line_name` is different from `move_name` and the result is: `line.move_id.name (line.move_id.ref) line.move_id.ref - line.move_id.payment_reference`

### Solution:
The previous fix prevents `line_name` from having the same string twice. But it does not fix the issue when the invoice name and Customer reference are different.

This commit checks if `move_name` and `move_ref` are included in `line_name` before adding it to the display name.

This is not optimal as it makes this code dependent on the format of `line_name`.

opw-4492298

Forward-Port-Of: odoo/odoo#196570

Before this commit, it wasn't possible to filter products by category when searching. This functionality was available in previous versions but was removed during refactoring. opw-4439314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196881 Forward-Port-Of: odoo/odoo#193503

Before this commit, it wasn't possible to filter products by category when searching. This functionality was available in previous versions but was removed during refactoring.

opw-4439314

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

Forward-Port-Of: odoo/odoo#196881
Forward-Port-Of: odoo/odoo#193503

Before this commit, the payment smart button included payments for cancelled orders, even though those payments were not captured. This caused discrepancies as it inaccurately reflected payments for orders that were not finalized. opw-4487386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196900 Forward-Port-Of: odoo/odoo#194191

Before this commit, the payment smart button included payments for cancelled orders, even though those payments were not captured. This caused discrepancies as it inaccurately reflected payments for orders that were not finalized.

opw-4487386

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

Forward-Port-Of: odoo/odoo#196900
Forward-Port-Of: odoo/odoo#194191

__Current behavior before commit:__ If an unexpected error that has no body is thrown inside `printHtml`, the popup shows "undefinedDo you want to print using the web printer?" and nothing is written in the console, making it impossible to troubleshoot. __Description of the fix:__ Don't print "undefined" in the popup if the error has no body but write the error in the console. opw-4322339 Forward-Port-Of: odoo/odoo#197383 Forward-Port-Of: odoo/odoo#194985

__Current behavior before commit:__
If an unexpected error that has no body is thrown inside `printHtml`, the popup shows "undefinedDo you want to print using the web printer?" and nothing is written in the console, making it impossible to troubleshoot.

__Description of the fix:__
Don't print "undefined" in the popup if the error has no body but write the error in the console.

opw-4322339

Forward-Port-Of: odoo/odoo#197383
Forward-Port-Of: odoo/odoo#194985

Steps to reproduce: 1) Install Click & Collect 2) Configure a standard delivery to deliver only to Belgium and publish 3) Unpublish the others 4) Go to /shop page add a storable product 5) Proceed to /checkout add two addresses one with US country, the other with Belgium 6) Try to click on US partner then on Belgium then again on US 7) Observe traceback After this commit we skip the check in _canEnableMainButton if a radio element is not found. Forward-Port-Of: odoo/odoo#197721

Steps to reproduce:
1) Install Click & Collect
2) Configure a standard delivery to deliver only to Belgium and publish
3) Unpublish the others
4) Go to /shop page add a storable product
5) Proceed to /checkout add two addresses one with US country, the other
  with Belgium
6) Try to click on US partner then on Belgium then again on US
7) Observe traceback

After this commit we skip the check in _canEnableMainButton if a radio element is not found.

Forward-Port-Of: odoo/odoo#197721

Problem: The complementary information were not displayed on the form view of a rule in a route. These informations are supposed to change depending on the Supply Method that has been selected, but since version 18, they always displayed the same information. The suffix, which is used to give information depending on the Supply Method, is not being used anymore and needs to be displayed again. Steps to reproduce: - Go to a route in Inventory and pick a rule - With Pull From set as Action,

Problem:
The complementary information were not displayed on the form view of a rule in a route. These informations are supposed to change depending on the Supply Method that has been selected, but since version 18, they always displayed the same information. The suffix, which is used to give information depending on the Supply Method, is not being used anymore and needs to be displayed again. 

Steps to reproduce:
- Go to a route in Inventory and pick a rule
- With Pull From set as Action, change the Supply Method
- The helper on the right won't change but it should

Fix:
The suffix was added to the message that has to be displayed.

opw-4511907

Forward-Port-Of: odoo/odoo#197741

Design Themes: https://github.com/odoo/design-themes/pull/1049 Enterprise: https://github.com/odoo/enterprise/pull/79833

Design Themes: https://github.com/odoo/design-themes/pull/1049
Enterprise: https://github.com/odoo/enterprise/pull/79833

Steps to reproduce: -------------------------- - Start db without demo data. - Click on furniture shop. Issue: -------- - There will be a TB while loading the furniture scenario. Cause: --------- - The user used in demo data doesn't have an email and it tries to post message in chatter. Fix: ----- - We have assigned a demo email to the user to avoid TB and also have the logs in chatter. Task: 4486094 Forward-Port-Of: odoo/odoo#194057

Steps to reproduce:
--------------------------
- Start db without demo data.
- Click on furniture shop.

Issue:
--------
- There will be a TB while loading the furniture scenario.

Cause:
---------
- The user used in demo data doesn't have an email and it tries to post message in chatter.

Fix:
-----
- We have assigned a demo email to the user to avoid TB and also have the logs in chatter.

Task: 4486094

Forward-Port-Of: odoo/odoo#194057

This commit will add a protection for the removal of bank and cash accounts. task: 4392444 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197271 Forward-Port-Of: odoo/odoo#190529

This commit will add a protection for the removal of bank and cash accounts.

task: 4392444




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

Forward-Port-Of: odoo/odoo#197271
Forward-Port-Of: odoo/odoo#190529

Before this commit, a pairing code is fetched once upon startup, displayed for 5 minutes, and then cleared. After this commit, the code timeout is extended to 10 minutes, and will be refreshed 2 times automatically. task-4586979 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198166

Before this commit, a pairing code is fetched once
upon startup, displayed for 5 minutes, and then
cleared.

After this commit, the code timeout is extended to
10 minutes, and will be refreshed 2 times
automatically.

task-4586979

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

Forward-Port-Of: odoo/odoo#198166

The `rollback` decorator does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. Forward-Port-Of: odoo/odoo#198500

The `rollback` decorator does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test).

This is unlikely to trigger odoo/odoo#71395 but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us.

Forward-Port-Of: odoo/odoo#198500

Description of the issue/feature this PR addresses: from [this commit](https://github.com/odoo/odoo/pull/129029/commits/4a070832), the docstring of `_xmlid_lookup` incorrectly states that the method returns `(id, res_model, res_id)`, while in reality, it only returns `(res_model, res_id)`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198719

Description of the issue/feature this PR addresses: from [this commit](https://github.com/odoo/odoo/pull/129029/commits/4a070832), the docstring of `_xmlid_lookup` incorrectly states that the method returns `(id, res_model, res_id)`, while in reality, it only returns `(res_model, res_id)`.



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

Forward-Port-Of: odoo/odoo#198719

Currently if the display isn't plugged in on boot the Raspberry Pi 4 never receives its EDID and if plugged after boot will not display the image on screen. This PR adds a default display configuration of 1080p 60Hz which is active and allows the RPI to send image to display even if it's connected after boot task-4587121 Forward-Port-Of: odoo/odoo#198750

Currently if the display isn't plugged in on boot the Raspberry Pi 4 never receives its EDID and if plugged after boot will not display the image on screen. This PR adds a default display configuration of 1080p 60Hz which is active and allows the RPI to send image to display even if it's connected after boot

task-4587121

Forward-Port-Of: odoo/odoo#198750

Couldn't: - read measurements from scales, - validate, skip, pass or fail quality checks with a footswitch. Tasks: 4432802 Forward-Port-Of: odoo/enterprise#79990 Forward-Port-Of: odoo/enterprise#76341

Couldn't:
- read measurements from scales,
- validate, skip, pass or fail quality checks with a footswitch.

Tasks: 4432802

Forward-Port-Of: odoo/enterprise#79990
Forward-Port-Of: odoo/enterprise#76341

### Steps to reproduce: - Install 'l10n_ch' and switch to a Swiss company - Go in Payroll app - Create a contract, go to its payslip - Click on "Create Payment Report" - Select SEPA as Report Format - The generated XML uses pain.001.001.09 but should use pain.001.001.03.ch.02 ### Cause: pain.001.001.03.ch.02 became a payment_method since this [commit](https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e). But in the payroll app there is only the option to

### Steps to reproduce:
- Install 'l10n_ch' and switch to a Swiss company
- Go in Payroll app
- Create a contract, go to its payslip
- Click on "Create Payment Report"
- Select SEPA as Report Format
- The generated XML uses pain.001.001.09 but should use pain.001.001.03.ch.02

### Cause:
pain.001.001.03.ch.02 became a payment_method since this [commit](https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e). But in the payroll app there is only the option to choose SEPA and by doing this it uses the 'sepa_ct' payment method: https://github.com/odoo/enterprise/blob/033b3f7773e0dd41cb1dfcc5542d19b22f5fe609/hr_payroll_account_iso20022/wizard/hr_payroll_payment_report_wizard.py#L26

### Solution:
Add a new value to choose from other than SEPA for the Report Format and make this format use the payment method iso20022_ch.

opw-4437968

Forward-Port-Of: odoo/enterprise#79971
Forward-Port-Of: odoo/enterprise#79858

…eneral info The Book keeper was not able to see the General info of bank accounts and so on - The problem was that there was an xpath that overwrite the groups - I was not able to remove the view file as it will affect our database and that may affect the system. - We may need to remove that file in the master Task-4567218 X-original-commit: 68f6c1f9fd3ff6762c98e1a405ade035129efce0 Forward-Port-Of: odoo/enterprise#80008

…eneral info

The Book keeper was not able to see the General info of bank accounts and so on

- The problem was that there was an xpath that overwrite the groups
- I was not able to remove the view file as it will affect our database and that may affect the system.
- We may need to remove that file in the master

Task-4567218

X-original-commit: 68f6c1f9fd3ff6762c98e1a405ade035129efce0

Forward-Port-Of: odoo/enterprise#80008

### Before this commit: When clicking on any budget, even if there was only one budget line, the list view opened with all budget.line records, regardless of the associated budget. ### After this commit: - When there are one or multiple budget line records in a budget, the form view of that budget will be opened. **task-4195738** Forward-Port-Of: odoo/enterprise#79928 Forward-Port-Of: odoo/enterprise#73799

### Before this commit:
When clicking on any budget, even if there was only one budget line, the list view opened with all budget.line records, regardless of the associated budget.

### After this commit:
- When there are one or multiple budget line records in a budget, the form view of that budget will be opened.

**task-4195738**

Forward-Port-Of: odoo/enterprise#79928
Forward-Port-Of: odoo/enterprise#73799

These fields shouldn't have a namespace. Removing them indeed makes the validation with the xsd succeed. We also clean the xml, by removing whitespaces. Forward-Port-Of: odoo/enterprise#79347 Forward-Port-Of: odoo/enterprise#79200

These fields shouldn't have a namespace.
Removing them indeed makes the validation with the xsd succeed.
We also clean the xml, by removing whitespaces.

Forward-Port-Of: odoo/enterprise#79347
Forward-Port-Of: odoo/enterprise#79200

Before this commit, after using the split tool new documents are created and should be automatically selected but aren't. This commit fix this issue. Task-4555273 Forward-Port-Of: odoo/enterprise#78692

Before this commit, after using the split tool new documents are created and should be automatically selected but aren't. This commit fix this issue.

Task-4555273

Forward-Port-Of: odoo/enterprise#78692

**Issue:** BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab. **Steps to Reproduce:** 1. Install Accounting, Sales, eCommerce, and l10n_br_avatax modules. 2. Switch company settings from YourCompany to BR Company. 3. Navigate to Products > Sales Tab. 4. Fiscal information fields appear under the "Ecommerce Shop" group. Expected Behavior: BR fiscal product fields should be displayed inside a specific

**Issue:**
BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab.

**Steps to Reproduce:**
1. Install Accounting, Sales, eCommerce, and l10n_br_avatax modules.
2. Switch company settings from YourCompany to BR Company.
3. Navigate to Products > Sales Tab.
4. Fiscal information fields appear under the "Ecommerce Shop" group.

Expected Behavior: BR fiscal product fields should be displayed inside a specific section inside the accounting group.

Actual Behavior: BR fiscal product fields are incorrectly placed in the Ecommerce Shop group.

**Root Cause**

The issue occurs because the code mistakenly modifies the Extra Info group, adds eCommerce-related fields inside it, and then renames it to Ecommerce Shop. This causes the Extra Info group to disappear, leading to fiscal information being displayed incorrectly.

**Fix**
To avoid modifying a module unrelated to Brazilian taxes, which might have a broader impact, the existing behaviour is left unchanged. Instead, a new section has been added within the accounting tab to display the necessary information. This ensures that only the l10n_br_avatax module is modified.



Opw-4533760

Forward-Port-Of: odoo/enterprise#79245

Steps to reproduce: - Let's consider an helpdesk team HT - Let's consider a working calendar WC with flexible hours and no working hours - Set an SLA policy on HT and set WC as SLA schedule - Create a ticket in HT Bug: A traceback was raised because the function plan_hours was called in _compute_deadline with no deadline Expected behavior: With WC in flexible hours, a deadline is computed according to the SLA policies With WC not in flexible hours and not working hours, no dead

Steps to reproduce:

- Let's consider an helpdesk team HT
- Let's consider a working calendar WC with flexible hours and no working hours
- Set an SLA policy on HT and set WC as SLA schedule
- Create a ticket in HT

Bug:

A traceback was raised because the function plan_hours was called in _compute_deadline with no deadline

Expected behavior:

With WC in flexible hours, a deadline is computed according to the SLA policies With WC not in flexible hours and not working hours, no deadline is computed (bad configuration)

opw:4563223

Forward-Port-Of: odoo/enterprise#79674

Community: https://github.com/odoo/odoo/pull/198562 Design Themes: https://github.com/odoo/design-themes/pull/1049

Community: https://github.com/odoo/odoo/pull/198562
Design Themes: https://github.com/odoo/design-themes/pull/1049

This PR will add new reports for the danish localisation. The new reports are a minimal version of what was already there since we received some comments that for a lot of companies the report has too much details. Also when doing the PR, we saw that some name in the old reports where not well formatted and so not consistent with the rest of the reports. This PR will also re-export the translation. Forward-Port-Of: odoo/enterprise#72879

This PR will add new reports for the danish localisation. The new reports are a minimal version of what was already there since we received some comments that for a lot of companies the report has too much details. 

Also when doing the PR, we saw that some name in the old reports where not well formatted and so not consistent with the rest of the reports. 

This PR will also re-export the translation.

Forward-Port-Of: odoo/enterprise#72879

The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will

The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test).

This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us.

For `web_gantt` the savepoint is closed but not on all paths (if `ValueError` is raised the savepoint is never rolled back let alone closed), the manual use is also rather unnecessary as we can just rollback around the relevant method call, none of the later mess interacts with the cursor / connection.

Forward-Port-Of: odoo/enterprise#79797