Steps to reproduce: - Install Contacts, Sales, Accounting and l10n_de - Configure DIN5008 as document layout in the settings - Install German language - Create a contact with German as language (e.g. German Contact) - Create a SO with German Contact as customer - Create an invoice from the SO - Add a Customer Reference ("Other Info" tab) on the invoice - Confirm and print the invoice Issue: On the printed invoice, both "Source" (i.e. the SO) and "Reference" (i.e. Customer Reference)

Steps to reproduce:
- Install Contacts, Sales, Accounting and l10n_de
- Configure DIN5008 as document layout in the settings
- Install German language
- Create a contact with German as language (e.g. German Contact)
- Create a SO with German Contact as customer
- Create an invoice from the SO
- Add a Customer Reference ("Other Info" tab) on the invoice
- Confirm and print the invoice

Issue:
On the printed invoice, both "Source" (i.e. the SO) and "Reference" (i.e. Customer Reference) labels are translated with the same German term: "Referenz".

Solution:
Translation team suggested to use "Verweis" to translate "Source" in German.

opw-3821069




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

Forward-Port-Of: odoo/odoo#162559
Forward-Port-Of: odoo/odoo#162381

### Steps to reproduce the issue: 1. Create a Storable Product and give it a UOM 2. Create an On Hand stock in a certain location 3. Go to Barcode and create a new Internal Transfer 4. Add the Product and with any quantity and click on Confirm (not Validate) 5. Edit the line of the Product (pencil icon), change the quantity and the UOM and click on Confirm 6. Validate the Transfer 7. Go back to the Product and click on the "On Hand" or the "Update Quantity" button 8. The reserved quant

### Steps to reproduce the issue:

1. Create a Storable Product and give it a UOM
2. Create an On Hand stock in a certain location
3. Go to Barcode and create a new Internal Transfer
4. Add the Product and with any quantity and click on Confirm (not Validate)
5. Edit the line of the Product (pencil icon), change the quantity and the UOM and click on Confirm
6. Validate the Transfer
7. Go back to the Product and click on the "On Hand" or the "Update Quantity" button
8. The reserved quantity is not null

### Explanation:

When you change `stock.move.line.product_uom_id`, `stock.quant.reserved_quantity` (using `product.product.uom_id`) is not changed to reflect the new `uom.uom.factor`. You then have two routes:

- In `stock_barcode`, `stock.move.line.product_uom_id` changes first, `stock.move.line.quantity` change is triggered through `stock.move.line._inverse_qty_done` afterwards.
https://github.com/odoo/enterprise/blob/d04b69ba03877a9b4aae82fb061dca23b1bfc4bc/stock_barcode/models/stock_move_line.py#L58-L61
When calling `stock.move.line._synchronize_quant`, `stock.move.line.quantity_product_uom` will use the new `stock.move.line.product_uom_id` while `stock.quant.reserved_quantity` still reflects the old `uom.uom.factor`.
https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/stock_move_line.py#L421-L422

(e.g.: going from `1 Dozens` to `2 Units` would give you `1.09 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`)

- There is a similar issue in _Inventory > Transfers > Internal_, where `stock.move.line.product_uom_id` changes at the same time instead. In that case, the whole operation will be done using the previous `stock.move.line.product_uom_id`, and changing `stock.move.line.product_uom_id` before changing `stock.move.line.quantity` would cause the same issue as in `stock_barcode`.

(e.g.: going from `1 Dozens` to `2 Units` would give you `2 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`)

### Suggested fix:

The fix is made to be as simple as possible, the two conditions will be reduced to simple assignations:

- The first one will be `product_uom_id`, with which `uom.uom._compute_quantity` will be called.
- The second condition will be `quantity`, which will be set in a `vals.get` in the `qty` parameter of the compute.

To make everything uniform, there will be no exception where `stock.move.line.quantity_product_uom` is used.

opw-3798046

Forward-Port-Of: odoo/odoo#162380
Forward-Port-Of: odoo/odoo#160656

Steps to reproduce ================== - Create two new storable products tracked by USN - Create a new RFQ with one of the created product - Confirm the order - Open the receipt - Add a new line with the other product - Click on the open move button in the new line - Add a new SN - Save & close => Cannot read properties of undefined (reading 'resId') Cause of the issue ================== When calling openRecord, if the record is dirty, it is saved before proceeding. After

Steps to reproduce
==================

- Create two new storable products tracked by USN
- Create a new RFQ with one of the created product
- Confirm the order
- Open the receipt
- Add a new line with the other product
- Click on the open move button in the new line
- Add a new SN
- Save & close

=> Cannot read properties of undefined (reading 'resId')

Cause of the issue
==================

When calling openRecord, if the record is dirty, it is saved before proceeding.

After saving, we call super.openRecord with the old record. Since that record is no longer linked to the root record (the stock.picking), when we try to save it, it won't match an existing id.

Solution
========

If the record is new, we don't save as there would be no way of knowing which of the returned line would come from this one.

If we are opening an existing record, we find the new datapoint by matching it's ID.

opw-3777615

Forward-Port-Of: odoo/odoo#162425

When a portal user is created (e.g. through the `auth_signup` module), an unnecessary write is done on the `write_date` of the default digest. This `write` is unnecessary since a portal user is never subscribed to the default digest. In case of a high signup frequency, it can cause concurrent transaction errors. We avoid writing if no internal user is being created. Forward-Port-Of: odoo/odoo#162230

When a portal user is created (e.g. through the `auth_signup` module),
an unnecessary write is done on the `write_date` of the default digest.
This `write` is unnecessary since a portal user is never subscribed to
the default digest.

In case of a high signup frequency, it can cause concurrent transaction
errors.

We avoid writing if no internal user is being created.

Forward-Port-Of: odoo/odoo#162230

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

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

Task-3761551

Forward-Port-Of: odoo/odoo#162106
Forward-Port-Of: odoo/odoo#160238

Problem: When we are in the form view of a product variant, the smart button "Extra Price" shows the number of pricelists for this variant including the archived ones Steps to reproduce: - Install "Sales" app and activate the pricelists - Create a product and some variants - Create at least one pricelist for a variant - Archive at least one of these pricelist - Go on the form view of the variant and take a look at the smart button which shows the number of pricelists including the archi

Problem:
When we are in the form view of a product variant, the smart button "Extra Price" shows the number of pricelists for this variant including the archived ones

Steps to reproduce:
- Install "Sales" app and activate the pricelists
- Create a product and some variants
- Create at least one pricelist for a variant
- Archive at least one of these pricelist
- Go on the form view of the variant and take a look at the smart button which shows the number of pricelists including the archived ones

Cause:
The domain that filters the pricelists doesn't take in consideration whether the pricelist is active

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

Forward-Port-Of: odoo/odoo#160876

When changing `groupby` we want to also update `user_groupby` to avoid raising `_validate_groupby_no_child` or `_validate_formula`. It can always be set independently after. Detected while upgrading `account_financial_report_it_sp` because `<field name="groupby" eval="False"/>` was set in the data but `user_groupby` was never updated. (but the constraint was triggered because of the write) Note that the constraint was not fired when needed either. Forward-Port-Of: odoo/odoo#160301

When changing `groupby` we want to also update `user_groupby` to avoid raising `_validate_groupby_no_child` or `_validate_formula`. It can always be set independently after.

Detected while upgrading `account_financial_report_it_sp` because `<field name="groupby" eval="False"/>` was set in the data but `user_groupby` was never updated. (but the constraint was triggered because of the write)

Note that the constraint was not fired when needed either.

Forward-Port-Of: odoo/odoo#160301

Issue ----- The activities summaries displayed by the misc. operations view in the accounting app take up the entire screen and span across the card if the activity summary is too long. Steps ----- - Open the Accounting App. - Create a new entry from 'Miscellaneous Operations'. - Add an activity with a long summary. - Go back the dashboard. The summary will try to span the entire width. Cause ----- The activities are displayed with a field tag in the kanban view. The

Issue
-----

The activities summaries displayed by the misc. operations  view in the accounting
app take up the entire screen and span across the card if the activity summary
is too long.

Steps
-----

 - Open the Accounting App.
 - Create a new entry from 'Miscellaneous Operations'.
 - Add an activity with a long summary.
 - Go back the dashboard. The summary will try to span the entire width.

Cause
-----

The activities are displayed with a field tag in the kanban view. The field tag
refers to the activities js component as a widget. Due the use of a widget attribute,
the template generates a div with class: "o_field_widget". This class is defined
to have a css "display" attribe with a default value of "inline-block". Using "inline-block"
causes the activity row to take up the whole width.

opw-3839992

Forward-Port-Of: odoo/odoo#160167

Actually if a server is not configured we can click on it and we are redirect to not reachable page With this commit it is not possible to click if server is not configured 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#162372

Actually if a server is not configured we can click on it and we are redirect to not reachable page

With this commit it is not possible to click if server is not configured

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

The patch function was changed at commit [1]. This introduced a call to `Object.hasOwn` which is the preferred way to check if an Object has a property as its own. However, after multiple user reports, it seems like a significant amount of user and website visitors still use browsers that do not have Object.hasOwn implemented. This commit introduces a fallback to Object.prototype.hasOwnProperty for browsers that do not have Object.hasOwn implemented. [1]: https://github.com/odoo/odoo/commi

The patch function was changed at commit [1]. This introduced a call to `Object.hasOwn` which is the preferred way to check if an Object has a property as its own. However, after multiple user reports, it seems like a significant amount of user and website visitors still use browsers that do not have Object.hasOwn implemented.

This commit introduces a fallback to Object.prototype.hasOwnProperty for browsers that do not have Object.hasOwn implemented.

[1]: https://github.com/odoo/odoo/commit/04fddc19d4aedd8105e0fda5582288c2bb1833fe

opw-3824593

Forward-Port-Of: odoo/odoo#160758

When the iot run without server we display an certificate error. This error is useless because we can't get a certificate without server. Some customer a worry about this error With this commit we hide this comment if we not connected to a Odoo server 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-

When the iot run without server we display an certificate error.

This error is useless because we can't get a certificate without server.

Some customer a worry about this error

With this commit we hide this comment if we not connected to a Odoo server

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

Current behavior: When generating a sale report for multiple pos sessions, the payment name is not clear which session it belongs to. Steps to reproduce: - Open PoS and make some sales - Close the session, and do the first step again. - Go in reporting and generate the report for a period that includes the two sessions. - In the payments table you will see the payment name, but you won't know which session it belongs to. opw-3684937 --- I confirm I have signed the CLA and read the P

Current behavior:
When generating a sale report for multiple pos sessions, the payment name is not clear which session it belongs to.

Steps to reproduce:
- Open PoS and make some sales
- Close the session, and do the first step again.
- Go in reporting and generate the report for a period that includes the two sessions.
- In the payments table you will see the payment name, but you won't know which session it belongs to.

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

Forward-Port-Of: odoo/odoo#160369

Currently restarts of the odoo server do not happen at the end of the installation of all components. The devices are therefore not detected. With this commit we restart the server when all the components have been installed 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#162362

Currently restarts of the odoo server do not happen at the end of the installation of all components. The devices are therefore not detected.

With this commit we restart the server when all the components have been installed

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

Steps to reproduce: - Set warehouse to two-steps reception - Create a BoM using a MTO (buy) component - Create a MO for 2 units of that BoM - Produce 1 and create a backorder - Open the Overview Issue: When there is a backorder (or if the MO is splitted), then when browsing the dests through `_rollup_move_dests()`, at some point it will branch into two differents path, related to each backorders. This will raise a traceback, as we only expected a single MO at that point. To avoid thi

Steps to reproduce:
- Set warehouse to two-steps reception
- Create a BoM using a MTO (buy) component
- Create a MO for 2 units of that BoM
- Produce 1 and create a backorder
- Open the Overview

Issue:
When there is a backorder (or if the MO is splitted), then when browsing the dests through `_rollup_move_dests()`, at some point it will branch into two differents path, related to each backorders. This will raise a traceback, as we only expected a single MO at that point.

To avoid this, we made the `_rollup_move_dests()` method batchable, so we can fetch all moves linked to a manufacturing order in a single call, avoiding this issue.

Note: For consistency sake, updated the `_rollup_move_origs()` method to be batchable as well, to avoid confusion when using one or the other.

opw-3849252

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

Forward-Port-Of: odoo/odoo#161790
Forward-Port-Of: odoo/odoo#161537

**Current behavior:** Adding an attachment to a mail template record associated with the survey invite wizard will not cause the attachment to populate the relevant field when actually sending a new survey invite email. **Expected behavior:** The attachments linked in the email template which is used by the survey invite wizard will appear in the form when sending a survey invite. **Steps to reproduce:** 1. In settings, go to the email templates management page 2. Select the Sur

**Current behavior:**
Adding an attachment to a mail template record associated with
the survey invite wizard will not cause the attachment to
populate the relevant field when actually sending a new survey
invite email.

**Expected behavior:**
The attachments linked in the email template which is used by
the survey invite wizard will appear in the form when sending a
survey invite.

**Steps to reproduce:**
1. In settings, go to the email templates management page

2. Select the Survey: Invite template and upload some
     attachment

3. Go to the Survey application and click on one of the surveys
     listed, observe the lack of attachments despite having the
     email template with the attachment selected

**Cause of the issue:**
The survey invite wizard never uses its template's attachments
to modify/update its own attachment_ids field.

**Fix:**
Make the attachment_ids field a stored computed field.

opw-3709830

Forward-Port-Of: odoo/odoo#162273
Forward-Port-Of: odoo/odoo#152728

Some parts of the translation were missing and Romanian isn't available as a language in Transifex for this version. Therefore we add it in now. English grammar mistakes of original string are left untouched. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162418

Some parts of the translation were missing and Romanian isn't available as a language in Transifex for this version. Therefore we add it in now. English grammar mistakes of original string are left untouched.

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

Forward-Port-Of: odoo/odoo#162418

When registering payment for customer invoices and vendor bills at the same time, a misleading error message appears"You can't register payments for journal eithers being both inbound and outbound". Replacing it with a clear message "You can't register payments for both inbound and outbound moves at the same time." Task id: 3638740 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162224 Forward-Port-Of: odoo/odoo#16210

When registering payment for customer invoices and vendor bills at the same time, a misleading error message appears"You can't register payments for journal eithers being both inbound and outbound".

Replacing it with a clear message "You can't register payments for both inbound and outbound moves at the same time."

Task id: 3638740

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

Forward-Port-Of: odoo/odoo#162224
Forward-Port-Of: odoo/odoo#162101

**Steps to reproduce:** 1- Create an allocation with validity date (e.g. 01-01-2024 -> 30-06-2024) and another one starts after the first one (e.g. 01-07-2024 -> 31-12-2024) 2- Go to Time off module and select a date in the second allocation's period 3- Click on the Time off type dropdown menu 4- You will see the first allocation displayed not the second one **Current behavior before PR:** The display name of some leaves gets computed in a wrong way. This is happening because aft

**Steps to reproduce:**
	1- Create an allocation with validity date (e.g. 01-01-2024 -> 30-06-2024)
	 and another one starts after the first one (e.g. 01-07-2024 -> 31-12-2024)
	2- Go to Time off module and select a date in the second allocation's period
	3- Click on the Time off type dropdown menu
	4- You will see the first allocation displayed not the second one

**Current behavior before PR:**
The display name of some leaves gets computed in a wrong way.
This is happening because after fetching the right allocation
we compute the display name but this time we don't have
the 'default_date_from' in context so since
it became one of the fields that triggers '_compute_leaves'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L218:L219
we compute the leaves once again but the target_date will be none
and it will get assigned with today's date in 'get_allocation_data'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L380:L381

**Desired behavior after PR is merged:**
This has been solved by saving the date attribute in the context
with another name as when computing the display_name we call sudo so clean_context()
removes the 'default_' context keys. Now when it gets removed we are
going to have the same value but with another name.

opw-3797696

Forward-Port-Of: odoo/odoo#159917

Steps: - Install sale apps. - Upload a header file from settings with xyz.pdf for example. Issue: - Header/Footer file is not updated according to uploaded file name. Cause: - Header/Footer file name in setting is related and readonly is should not be readonly in order to update header file name. Fix: - Make settings header/footer file not readonly to set proper updated file names. task-3620555 Forward-Port-Of: odoo/odoo#152007

Steps:
- Install sale apps.
- Upload a header file from settings with xyz.pdf for
example.

Issue:
- Header/Footer file is not updated according to uploaded
file name.

Cause:
- Header/Footer file name in setting is related and
readonly is should not be readonly in order to update
header file name.

Fix:
- Make settings header/footer file not readonly to
set proper updated file names.

task-3620555

Forward-Port-Of: odoo/odoo#152007

Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund. Steps to reproduce: ------------------- * Setup a rounding method with

Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund.

Steps to reproduce:
-------------------
* Setup a rounding method with a precision of 5.0
* Create a product with a price of 138.0
* Open the POS and add the product to the order
* Pay the order with 2 payments, one bank of 55 and one cash that will be rounded to 80.
* Validate the order
* Go in the backend and refund the order
* The refund will be rounded to 135.0

Why the fix:
------------
The new behavior after this fix:
* When refunding the entire original order, the amount to refund should be equal to what the customer paid on the original order (thus taking into account the rounding).
* When doing a partial refund, the amount that should be refunded correspond to the base price of the article(s) selected.

The issue was about the fact that refunds differed in prices compared to the original order. With this fix, there could still be a difference in the prices if a customer comes multiple times to do a partial refund and end up refunding the total order. This difference exists only if the original order was paid with rounding and will be maximum the rounding defined.

Since this is a rare event, we consider this difference to be acceptable.

Post-fixup:
-----------
The function `_get_rounded_amount()` was modified as we are not computing cash rounding when refunding anymore.

opw-3701574

Forward-Port-Of: odoo/odoo#162280
Forward-Port-Of: odoo/odoo#161564

Steps to reproduice: -go to myprofile with hr installed -go to resume page -> skills title is duplicated Reason: The no_label attribute is set to True but the widget will still display a label. Expected behavior: The label should only be displayed once Fix: Remove the effectless no_label attribute and remove the separator task: 3815381 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158051

Steps to reproduice:
-go to myprofile with hr installed
-go to resume page
-> skills title is duplicated

Reason:
The no_label attribute is set to True but the widget will still display a label.

Expected behavior:
The label should only be displayed once

Fix:
Remove the effectless no_label attribute and remove the separator

task: 3815381

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

Forward-Port-Of: odoo/odoo#158051

Product domains were not considered when computing the min amount to reach to get a discount. For example, if you created a discount with a minimum amount of 100 for product "X", the discount would have been applied, even if the amount for "X" was less than 100, as long as the total amount of the SO was at least 100. After this fix, only products that match the domain will be considered when computing the amount that should be compared to the discount's min amount. opw-3626345 Forward

Product domains were not considered when computing the min amount to reach to get a discount. For
example, if you created a discount with a minimum amount of 100 for product "X", the discount
would have been applied, even if the amount for "X" was less than 100, as long as the total amount
of the SO was at least 100.

After this fix, only products that match the domain will be considered when computing the amount
that should be compared to the discount's min amount.

opw-3626345

Forward-Port-Of: odoo/odoo#162020
Forward-Port-Of: odoo/odoo#155085

When consuming more tracked by lots (therefore manually-consumed) components than expected, you can easily close the production by clicking 'Set Quantities and Validate' on the consumption wizard. But consuming less than expected gives an 'Invalid Operation: lot/serial number needs to be specified for a tracked product' error. This because _recompute_state consider less consumed components as 'partially_available' rather then 'assigned'. --- I confirm I have signed the CLA and read the PR gu

When consuming more tracked by lots (therefore manually-consumed) components than expected, you can easily close the production by clicking 'Set Quantities and Validate' on the consumption wizard. But consuming less than expected gives an 'Invalid Operation: lot/serial number needs to be specified for a tracked product' error. This because _recompute_state consider less consumed components as 'partially_available' rather then 'assigned'.

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

Forward-Port-Of: odoo/odoo#144718

Description of the issue/feature this PR addresses: Improved error handling for EMV QR generation for invoices Current behavior before PR: Currently, if EMV QR is selected on the invoice where the country does not support EMV QR an error is raised. Desired behavior after PR is merged: However, this error is also raised if EMV QR is selected but the bank account is not set. The following error is raised `No EMV QR Code is available for the country of the account False.` This commit adds

Description of the issue/feature this PR addresses:
Improved error handling for EMV QR generation for invoices

Current behavior before PR:
Currently, if EMV QR is selected on the invoice where the country does not support EMV QR an error is raised.

Desired behavior after PR is merged:
However, this error is also raised if EMV QR is selected but the bank account is not set. The following error is raised `No EMV QR Code is available for the country of the account False.` This commit adds a check to ensure the bank account is set and it raises a better error message.

Task# 3868467


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

Forward-Port-Of: odoo/odoo#162319

**Steps to reproduce:** - Install Accounting and Sales - Configure TaxCloud in Accounting settings - Create a SO: * Customer: [US customer] (e.g. Azure Interior) * Product: [any] * Unit Price: [any] (e.g. $ 200.00) * Fiscal Position (Other Info tab): Automatic Tax Mapping (TaxCloud) - Confirm the SO => The taxes will be recomputed with TaxCloud (e.g. $ 20.50 with "Tax 10.250 %") - Create a down payment from SO (via "Create Invoice" button): * Create Invoice: Down payment (p

**Steps to reproduce:**
- Install Accounting and Sales
- Configure TaxCloud in Accounting settings
- Create a SO:
  * Customer: [US customer] (e.g. Azure Interior)
  * Product: [any]
  * Unit Price: [any] (e.g. $ 200.00)
  * Fiscal Position (Other Info tab): Automatic Tax Mapping (TaxCloud)
- Confirm the SO
=> The taxes will be recomputed with TaxCloud (e.g.  $ 20.50 with "Tax 10.250 %")
- Create a down payment from SO (via "Create Invoice" button):
  * Create Invoice: Down payment (percentage)
  * Down Payment Amount: 50%
=> The total amount of the down payment is 50% of the total amount of the SO (i.e. $ 110.25) and the computed taxes are the same than the taxes on the SO.
- Confirm the down payment

**Issue:**
Upon confirmation, the taxes are recomputed with TaxCloud and the total amount is not the same anymore.

**Cause:**
The "Down payment" product has a specific TaxCloud Category and as the taxes are recomputed upon confirmation, the tax amount changes (e.g. from $ 20.50 to $ 0.00).

**Solution:**
Do not recompute taxes with TaxCloud when confirming a down payment as the taxes should have already been computed correctly when the down payment has been created.

opw-3814524

Forward-Port-Of: odoo/enterprise#60722

# FIX] knowledge: remove useless popover This commit fixes an issue where the popover would open inside the comments panel when replying to a comment with a small enough window, even though in this situation it's not useful at all. Now when the panel is open and we have a small window, the popover will not open when replying to a comment. # [FIX] knowledge: show panel's comments in small windows This commit fixes an issue with the comments panel when using it with a small window.

# FIX] knowledge: remove useless popover

This commit fixes an issue where the popover would open inside the comments
panel when replying to a comment with a small enough window, even though in
this situation it's not useful at all.

Now when the panel is open and we have a small window, the popover will not
open when replying to a comment.

# [FIX] knowledge: show panel's comments in small windows

This commit fixes an issue with the comments panel when using it with a small
window.

Before, when you opened the panel when in a small enough window, the comments
aren't properly displayed meaning that you only have empty boxes inside the
panel. This was caused by a styling issue inside of the template that applied
a wrong style to the comment boxes inside panel, which is not necessary inside
it.

Now, we modified the inline style in the template so that it is not applied
inside the panel, showing back those comments in all circumstances.

task-3786282

Forward-Port-Of: odoo/enterprise#58045

Forward-Port-Of: odoo/enterprise#60420

Forward-Port-Of: odoo/enterprise#60420

# Introduction: `JSON.stringify` was used to serialize the properties for the `/article` command instead of the classical `encodeDataBehaviorProps` which also uses `encodeURIComponent` above the `JSON.stringify`, to avoid having some special characters as an attribute value. # The issue: `html_field.js:getEditingValue` is recovering the current value in the DOM using `innerHTML` which converts some characters from tag attributes to HTML entities, i.e.: `&quot;` for `"`. `mail.py

# Introduction:

`JSON.stringify` was used to serialize the properties for the `/article`
command instead of the classical `encodeDataBehaviorProps` which also uses
`encodeURIComponent` above the `JSON.stringify`, to avoid having some special
characters as an attribute value.

# The issue:

`html_field.js:getEditingValue` is recovering the current value in the DOM using
`innerHTML` which converts some characters from tag attributes to HTML entities,
i.e.: `"` for `"`.

`mail.py:html_normalize` is using `lxml.html.tostring` is receiving such a
string with HTML entities, and is returning a string without HTML entities.

The database value (without HTML entities) is later given to the `html_field` as
a prop and is used as a comparison reference (`updateValue`) with the current
value in edition (that is still being converted to have HTML entities). Since
both values are different, the field is considered as dirty and in need of being
saved, which will trigger a write, even though the normalized value is the
same.

# Fix:

Using `encodeDataBehaviorProps` to serialize props as the Behavior anchor
attribute (like for any other Behavior) will prevent the use of characters that
are being converted to HTML entities.

In order to update existing `/article` blocks, the behavior will overwrite its
`data-behavior-props` attribute when it is mounted in edit mode.

task-3853291

Forward-Port-Of: odoo/enterprise#60985
Forward-Port-Of: odoo/enterprise#60177

Appointment slots are not reflected in the gantt view so there are no indications of whether an appointment is within a valid time period with regards to the appointment-defined time intervals. This commit adds slot intervals in gantt availabilities display and attempts to have more common ground between slots and gantt. task-3813567 Forward-Port-Of: odoo/enterprise#60100

Appointment slots are not reflected in the gantt view so there
are no indications of whether an appointment is within a valid
time period with regards to the appointment-defined time intervals.

This commit adds slot intervals in gantt availabilities display and
attempts to have more common ground between slots and gantt.

task-3813567

Forward-Port-Of: odoo/enterprise#60100

Currently, the xsd validation tries to fetch a part of the xsd from internet. There is no need for it, we should just have it (as the others). It causes issues when running the tests if you can't make the request. (reproducible if you have no internet). Linked to runbot error 30521 Forward-Port-Of: odoo/enterprise#60964

Currently, the xsd validation tries to fetch a part of the xsd from internet.
There is no need for it, we should just have it (as the others).

It causes issues when running the tests if you can't make the request. 
(reproducible if you have no internet).

Linked to runbot error 30521

Forward-Port-Of: odoo/enterprise#60964

Package is wrongly set on product line in barcode scan Steps: - Have a product P tracked by lot - Set 2 stock quant in 2 locations: 1st in loc1 with lot L and package P 2nd in loc2 with lot1 and no package - Create a picking (Customer delivery) for P with source loc2 - With barcode make the delivery, scan the lot number -> The pack P is set on the product line, even if the package P is in loc1 We pass the location id through the context in order to adapt the domain in `pref

Package is wrongly set on product line in barcode scan

Steps:

- Have a product P tracked by lot
- Set 2 stock quant in 2 locations:
	1st in loc1 with lot L and package P
	2nd in loc2 with lot1 and no package
- Create a picking (Customer delivery) for P with source loc2
- With barcode make the delivery, scan the lot number
-> The pack P is set on the product line, even if the package P
   is in loc1

We pass the location id through the context in order to adapt
the domain in `prefilled_owner_package_stock_barcode()`, doing that
we ensure we also cover the case where we have 2 stock quant with
one with no package and the other with package.

opw-3746608

Forward-Port-Of: odoo/enterprise#61057
Forward-Port-Of: odoo/enterprise#59342

The Belastingdienst for the Dutch government has a service to check the status of the processing of the submitted report. This adds this functionality through a new module (which will be merged in master). Forward-Port-Of: odoo/enterprise#61017 Forward-Port-Of: odoo/enterprise#60777

The Belastingdienst for the Dutch government has a service to check the status of the processing of the submitted report. This adds this functionality through a new module (which will be merged in master).

Forward-Port-Of: odoo/enterprise#61017
Forward-Port-Of: odoo/enterprise#60777

Steps to reproduce: - Install helpdesk - Add an alias domain to send ticket - Send a mail to add a ticket, with the mail of the demo user Error: No mail is sent to the user confirming the reception of the ticket. This is due to condition here https://github.com/odoo/enterprise/blob/1502f8b3e519d41f4a58e2acc846f315f6f5eeda/helpdesk/models/helpdesk_ticket.py#L789-L790 This was done to prevent mail being sent if we created the ticket through the frontend. Desired behaviour as checked with

Steps to reproduce:
- Install helpdesk
- Add an alias domain to send ticket
- Send a mail to add a ticket, with the mail of the demo user

Error:
No mail is sent to the user confirming the reception of the ticket. This is due to condition here https://github.com/odoo/enterprise/blob/1502f8b3e519d41f4a58e2acc846f315f6f5eeda/helpdesk/models/helpdesk_ticket.py#L789-L790

This was done to prevent mail being sent if we created the ticket through the frontend. Desired behaviour as checked with PO is to keep this behaviour in frontend but to send a mail back if we submitted ticket through mail.

By looking at the context we can the origin of the ticket (frontend or mail) and send a mail if it came from an email.

Context key we used is set here https://github.com/odoo/enterprise/blob/1502f8b3e519d41f4a58e2acc846f315f6f5eeda/helpdesk/models/helpdesk_ticket.py#L742

opw-3786152

Forward-Port-Of: odoo/enterprise#59776

Forward-Port-Of: odoo/enterprise#60776

Forward-Port-Of: odoo/enterprise#60776

Steps to reproduce: - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create a US customer (e.g. Foreign Customer) (*) - In Accounting settings: * activate "Customer Addresses" * use Mexican Bank for automatic currency rates (*) - Configure a product for external trade (e.g. Office Chair) (*) - Create an invoice: (*) * Customer: Foreign Customer * Delivery Addr

Steps to reproduce:
- Install Contacts, Accounting and l10n_mx_edi_extended
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to company form and configure its address (*)
- Create a US customer (e.g. Foreign Customer) (*)
- In Accounting settings:
  * activate "Customer Addresses"
  * use Mexican Bank for automatic currency rates (*)
- Configure a product for external trade (e.g. Office Chair) (*)
- Create an invoice: (*)
  * Customer: Foreign Customer
  * Delivery Address: [different than customer] (e.g. Deco Addict)
  * Journal in: USD
  * Usage: Without fiscal effects
  * Product: Office Chair
  * Incoterm: EX WORKS
  * External Trade: Definitive
- Confirm the invoice
- Try to generate CFDI via "Send & Print" button (it will probably fail)

(*) https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade

Issue:
Check the generated CFDI in CFDI tab.
The data for element `<cce20:Destinatario><cce20:Domicilio /></cce20:Destinatario>` are incorrect.
"Calle", "NumeroExterior", "NumeroInterior", "Pais" and "CodigoPostal" are coming from the current company instead of the delivery address.

opw-3715960

Forward-Port-Of: odoo/enterprise#60829

This commit fixes the note handling in the UBL tags for the l10n_pe_edi module by ensuring notes contain only alphanumeric characters and spaces, conforming to UBL specifications. This change: - Removes all non-alphanumeric characters except spaces. - Ensures notes are truncated to a maximum of 200 characters. Legal Reference: https://cpe.sunat.gob.pe/sites/default/files/inline-files/AjustesValidacionesCPEv20240205_.xlsx ![image](https://github.com/odoo/enterprise/assets/50924836/91dbf74

This commit fixes the note handling in the UBL tags for the l10n_pe_edi module by ensuring notes contain only alphanumeric characters and spaces, conforming to UBL specifications. This change:
- Removes all non-alphanumeric characters except spaces.
- Ensures notes are truncated to a maximum of 200 characters.

Legal Reference: https://cpe.sunat.gob.pe/sites/default/files/inline-files/AjustesValidacionesCPEv20240205_.xlsx

![image](https://github.com/odoo/enterprise/assets/50924836/91dbf742-f545-452a-a68e-e480d97ce5ad)

Forward-Port-Of: odoo/enterprise#60888

Currently, receipts are not accounted for in the model 347 report (issue 1). The same happens for invoices for which a payment has been registered (issue 2). ### Setup * install `l10n_es_reports` * switch to a Spanish company ### Steps to reproduce issue 1 * with a new partner, create and confirm a customer receipt for more than €3005.06 (threshold for appearing in the report) * open the model 347 tax report We would expect the new partner to be listed in the report, but they ar

Currently, receipts are not accounted for in the model 347 report (issue 1). The same happens for invoices for which a payment has been registered (issue 2).

### Setup

* install `l10n_es_reports`
* switch to a Spanish company

### Steps to reproduce issue 1

* with a new partner, create and confirm a customer receipt for more than €3005.06 (threshold for appearing in the report)
* open the model 347 tax report

We would expect the new partner to be listed in the report, but they aren't.

### Steps to reproduce issue 2

* with a new partner, create and confirm an invoice for more than €3005.06
* if you open the model 347 report, you will see the new partner listed there
* go back to that invoice and register a payment for it.
* open the model 347 report again

We expect the new partner to still be listed, but they are not.

### Cause

issue 1: receipts are missing in the corresponding domains.
issue 2: all account moves are used to calculate the threshold. This means that, for example, invoices and payments can cancel each other out in the calculation.

opw-3816370

Forward-Port-Of: odoo/enterprise#60432
Forward-Port-Of: odoo/enterprise#59343

[FIX] account_reports: skip the 'draft entries' warning for tax closings properly for all tax report Some specific code was added by https://github.com/odoo/enterprise/commit/649960d66eaf0c1cdf0c81b86a6226d77d244b98 in order to ignore the tax closing entries in the warning stating there are draft entries in the period, if on the tax report. However, this was badly forward-ported, and only worked for the generic tax report. With this fix, every tax report will benefit from it, as originally in

[FIX] account_reports: skip the 'draft entries' warning for tax closings properly for all tax report

Some specific code was added by https://github.com/odoo/enterprise/commit/649960d66eaf0c1cdf0c81b86a6226d77d244b98 in order to ignore the tax closing entries in the warning stating there are draft entries in the period, if on the tax report. However, this was badly forward-ported, and only worked for the generic tax report. With this fix, every tax report will benefit from it, as originally intended.


[FIX] account_reports: re-enable the warning about inactive tags in period for tax reports

This warning was dropped by mistake when introducing the new warning mechanism for accounting reports.

Forward-Port-Of: odoo/enterprise#60774

This PR adds the same description for Worldline as we already do for Ingenico to clearly state that our Worldline intergration is only available in Benelux. task-3866802 Forward-Port-Of: odoo/enterprise#60676 Forward-Port-Of: odoo/enterprise#60649

This PR adds the same description for Worldline as we already do for Ingenico to clearly state that our Worldline intergration is only available in Benelux.

task-3866802

Forward-Port-Of: odoo/enterprise#60676
Forward-Port-Of: odoo/enterprise#60649

**Coverage for community fix** https://github.com/odoo/odoo/pull/157515 opw-3754297 Forward-Port-Of: odoo/enterprise#59301 Forward-Port-Of: odoo/enterprise#58264

**Coverage for community fix**
https://github.com/odoo/odoo/pull/157515

opw-3754297

Forward-Port-Of: odoo/enterprise#59301
Forward-Port-Of: odoo/enterprise#58264

The post-init hook of this module runs `ChartTemplate._load_data` and that might reference the xmlid of a general journal from the company. If that xmlid is missing, it will fail with the error: ``` KeyError: ('ir.model.data', <function IrModelData._xmlid_lookup at 0x7f9ff24b1240>, 'account.1_general') ``` Steps to reproduce on a fresh 17.0 database: - Install a localization module, eg `l10n_be`. - This will create the necessary xmlids. Delete the `X_general` xmlids from the dabase. - I

The post-init hook of this module runs `ChartTemplate._load_data` and that might reference the xmlid of a general journal from the company. If that xmlid is missing, it will fail with the error:
```
KeyError: ('ir.model.data', <function IrModelData._xmlid_lookup at 0x7f9ff24b1240>, 'account.1_general')
```

Steps to reproduce on a fresh 17.0 database:
- Install a localization module, eg `l10n_be`.
- This will create the necessary xmlids. Delete the `X_general` xmlids from the dabase.
- Install `account_accountant`. Installation will fail with the aforementioned error.

This also happens during upgrades:
- On a fresh 16.0 database, install module `l10n_uk`.
- The `X_general` xmlids are not created as they don't exist in this version.
- Upgrade to 17.0
- `l10n_uk` doesn't load data from its template, so the xmlids still don't exist.
- Module `account_accountant` is automatically installed, triggering the error.

Forward-Port-Of: odoo/enterprise#59512

**Steps to reproduce:** - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create a US customer (e.g. Foreign Customer) (*) - In Accounting settings: * activate "Customer Addresses" * use Mexican Bank for automatic currency rates (*) - Configure a product for external trade (e.g. Office Chair) (*) - Create an invoice: (*) * Customer: Foreign Customer * Delivery

**Steps to reproduce:**
- Install Contacts, Accounting and l10n_mx_edi_extended
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to company form and configure its address (*)
- Create a US customer (e.g. Foreign Customer) (*)
- In Accounting settings:
  * activate "Customer Addresses"
  * use Mexican Bank for automatic currency rates (*)
- Configure a product for external trade (e.g. Office Chair) (*)
- Create an invoice: (*)
  * Customer: Foreign Customer
  * Delivery Address: [different than customer] (e.g. Deco Addict)
  * Product: Office Chair
  * Incoterm: EX WORKS
  * External Trade: Definitive
- Confirm the invoice
- Generate CFDI via "Send & Print" button

(*) https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade

**Issue:**
A traceback is raised because an inexisting method (i.e. `_get_customer_cfdi_values`) is called.

**Cause:**
The missing method has been renamed from "_l10n_mx_edi_get_customer_cfdi_values" to "_get_customer_cfdi_values" during a refactoring, but the original method has been deleted without implementing the new one.

**Solution:**
"_l10n_mx_edi_get_customer_cfdi_values" method was used to generate the data for the delivery address without altering the existing CFDI values.
These data were used to populate the external trade data of the CFDI.
"_add_customer_cfdi_values" method is similar to removed "_l10n_mx_edi_get_customer_cfdi_values" method, except that it also updates "receptor" in the CFDI.
It is used with a copy of the cfdi values to compute the values for the delivery address.

opw-3849153

Forward-Port-Of: odoo/enterprise#60758