Employees can now confirm “My Time Off” requests for leave types that do not require validation without seeing an incorrect error. This prevents unnecessary blockers when submitting time off and keeps the request flow consistent for automatically confirmed leave types.

User Error stating that user's trying to confirm My Time Off request that's not 'To Submit' for no-validation type was solved. It was caused by the fact that create method sets state to 'confirm' automatically for no-validation time offs which triggers mentioned error on confirmation. Problem was solved by adding in confirmation check if it's of no-validation type.

task-3284380

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

The Planning publish dialog now displays its list content without extra empty space on the right. This makes the publish and send flow cleaner and easier to read when assigning shifts to employees without email addresses.

Steps:
- Open planning
- Assign a new employee to shift without email
-  Click on the 'Publish' button
- Click on the 'Publish & Send' button

Issue:
- Dialog is sized weirdly compared to the list view inside of it. There is trailing space on the right side of the list view.

Cause:
- Improper group and colspan are given in the view.

Fix:
- As this fix is in the stable version, currently we are giving invisible=1 to
that group which shall be removed in master and adding the code without group
and colspan.

task-3378532

Updates automated rental workflow checks so they continue to work after tooltip behavior changed. This helps keep test coverage reliable without changing the customer-facing rental process.

https://github.com/odoo/odoo/pull/131680

Task-3186593

The current shortcut used to create a todo is already a shortcut on Windows used to switch to lens view, which is impractical. It was changed from "Alt + Ctrl + L" to "Alt + Shift + T". Forward-Port-Of: odoo/odoo#143805

The current shortcut used to create a todo is already a shortcut on Windows used to switch to lens view, which is impractical.

It was changed from "Alt + Ctrl + L" to "Alt + Shift + T".

Forward-Port-Of: odoo/odoo#143805

Currently, the error occurs while updating a work contract without selecting any employee. Steps to reproduce: - Install a 'hr_work_entry_contract' module. - Go to Employees> Employees> Contracts, And create a new contract without selecting any employee and also the 'Contract Start Date ' and 'Contract End Date' fields should be after or before the current date. - Then save it . - Then change 'Working Schedule' field of the created contract and save it. - The error is generated

Currently, the error occurs while updating a work contract without selecting any  employee.

Steps to reproduce:
- Install a 'hr_work_entry_contract' module.
- Go to Employees> Employees> Contracts, And create a new contract without 
  selecting any employee and also the 'Contract Start Date ' and 
  'Contract End Date' fields  should be after or before the current date.
- Then save it .
- Then change 'Working Schedule' field of the created contract and save it.
- The error is generated.

Traceback on sentry:

```
DatatypeMismatch: column "hr_employee_id" is of type integer but expression is of type boolean
LINE 1: ...neration_wizard_id", "hr_employee_id") VALUES (1, false) ON ...
                                                             ^
HINT:  You will need to rewrite or cast the expression.

  File "odoo/http.py", line 2157, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1732, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1759, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1960, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 24, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 466, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "odoo/api.py", line 453, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "addons/web/models/models.py", line 71, in web_save
    self.write(vals)
  File "home/odoo/src/enterprise/17.0/hr_payroll/models/hr_contract.py", line 416, in write
    res = super().write(vals)
  File "addons/hr_work_entry_holidays/models/hr_contract.py", line 89, in write
    return super().write(vals)
  File "addons/hr_work_entry_contract/models/hr_contract.py", line 443, in write
    contract._recompute_work_entries(date_from, date_to)
  File "home/odoo/src/enterprise/17.0/hr_payroll/models/hr_contract.py", line 427, in _recompute_work_entries
    super()._recompute_work_entries(date_from, date_to)
  File "addons/hr_work_entry_contract/models/hr_contract.py", line 448, in _recompute_work_entries
    wizard = self.env['hr.work.entry.regeneration.wizard'].create({
  File "<decorator-gen-12>", line 2, in create
  File "odoo/api.py", line 414, in _model_create_multi
    return create(self, [arg])
  File "odoo/models.py", line 4582, in create
    records = self._create(data_list)
  File "odoo/models.py", line 4828, in _create
    field.create([
  File "odoo/fields.py", line 4310, in create
    self.write_batch(record_values, True)
  File "odoo/fields.py", line 4336, in write_batch
    self.write_real(records_commands_list, create)
  File "odoo/fields.py", line 4913, in write_real
    cr.execute(SQL(
  File "odoo/sql_db.py", line 332, in execute
    res = self._obj.execute(query, params)
````


There's an issue while updating the contract without selecting any employee; As the system is trying to recompute work entries without employee_id [1].

This commit solves this issue by adding a condition which states that recompute the work entries; if employee_id is available.

[1]-https://github.com/odoo/odoo/blob/1b504038ce270540ddab28db4ab995d22f2ab2a7/addons/hr_work_entry_contract/models/hr_contract.py#L448-L452

sentry-4654142515

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

Forward-Port-Of: odoo/odoo#143322

Currently, increasing the rounding factor for a currency is not allowed if accounting entries have already been generated in that currency. However, the restriction currently only applies to the current company. And since currency records are shared between multiple companies, a user can create a new company with no accounting entries and then change the currency's rounding factor, affecting all companies. This commit checks for the restriction on all companies, and fixes a few tests th

Currently, increasing the rounding factor for a currency is not allowed
if accounting entries have already been generated in that currency.
However, the restriction currently only applies to the current company.
And since currency records are shared between multiple companies, a user
can create a new company with no accounting entries and then change the
currency's rounding factor, affecting all companies.

This commit checks for the restriction on all companies, and fixes a few
tests that were broken by this change.


opw-3586785

Forward-Port-Of: odoo/odoo#142729

Fix the email designer fullscreen icon size by adding the .img-fluid css class to make the icon image responsive and ensuring it won't scale beyond its parents. Task-3604699 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143831 Forward-Port-Of: odoo/odoo#142953

Fix the email designer fullscreen icon size by adding the .img-fluid css class
to make the icon image responsive and ensuring it won't scale beyond its parents.

Task-3604699

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

Forward-Port-Of: odoo/odoo#143831
Forward-Port-Of: odoo/odoo#142953

Prevent error: "[BR-S-10]-A VAT breakdown (BG-23) with VAT Category code (BT-118) "Standard rate" shall not have a VAT exemption reason code (BT-121) or VAT exemption reason text (BT-120)." We should not provide a tax exemption reason for standard rates when the customer is Norvegian. It is not allowed in UBL Peppol Bis 3. no task/no ticket (noticed the error in the IAP logs). Forward-Port-Of: odoo/odoo#144205

Prevent error: "[BR-S-10]-A VAT breakdown (BG-23) with VAT Category code (BT-118) "Standard rate" shall not have a VAT exemption reason code (BT-121) or VAT exemption reason text (BT-120)."

We should not provide a tax exemption reason for standard rates when the customer is Norvegian. It is not allowed in UBL Peppol Bis 3.

no task/no ticket (noticed the error in the IAP logs).

Forward-Port-Of: odoo/odoo#144205

The aim of this commit is verifying that the partner for who we want to generate an oioubl file has a vat number set. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142684

The aim of this commit is verifying that the partner for who we want to generate an oioubl file has a vat number set.

no task id


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

Forward-Port-Of: odoo/odoo#142684

`psycopg2` errors sometimes happen during tests. This is caused by race conditions between several `cr.execute()`/`cr.fetch*`. This is even worse with websockets that are long lived connections that sometimes open a cursor in the middle of the test. Before websockets, longpolling was just disabled during tests. This commits disable websockets as well in order to prevent those errors as much as possible. Some live chat tours were updated in [1] after the websockets intro- duction du

`psycopg2` errors sometimes happen during tests. This is caused by
race conditions between several `cr.execute()`/`cr.fetch*`.

This is even worse with websockets that are long lived connections
that sometimes open a cursor in the middle of the test.

Before websockets, longpolling was just disabled during tests. This
commits disable websockets as well in order to prevent those errors
as much as possible.

Some live chat tours were updated in [1] after the websockets intro-
duction due to some race conditions. This was reverted as the fix
relied on a hack on websockets that are now unavailable.

fixes runbot-25357,24809

[1]: https://github.com/odoo/odoo/pull/103521

Forward-Port-Of: odoo/odoo#143647
Forward-Port-Of: odoo/odoo#141519

**Version:** - 17.0 **Improvement:** With this PR, we have improved the UI for the Prepayment amount field in both the quotation template form view and the Sale order form view. The changes have made it easier for users to input and review information. Current behavior before PR: - The online signature and payment fields are on the left side in the Quotation Template's form view. Desired behavior after PR is merged: - Change the label from "Quotation expires after" to "Quotat

**Version:**

- 17.0

**Improvement:**

With this PR, we have improved the UI for the Prepayment amount field
in both the quotation template form view and the Sale order form view.
The changes have made it easier for users to input and review information.

Current behavior before PR:
- The online signature and payment fields are on the left side in the
Quotation Template's form view.

Desired behavior after PR is merged:
- Change the label from "Quotation expires after" to "Quotation Validity"
- To ensure a smooth flow of data, the online signature and payment fields
are placed on the right side in the Quotation Template's form view with a
single line. And also improve the Sale order's form view. 

task-3546106

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

Forward-Port-Of: odoo/odoo#139461

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

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

Forward-Port-Of: odoo/odoo#142860

What are the steps to reproduce your issue? Price Decimal Precision set at 5, currency at 2. Anglosaxon enabled. Have a product with a unit / purchase cost of 3.30125 Create Purchase for 1500.00 and receipt in. This creates an SVL and AML for 4951.88 Create Bill with unit cost of 3.30125 and total amount of 4951.88 Confirm Invoice What is the current behavior that you observe? The layer unit price value is calculated unrounded (line 304, purchase_stock/models/account_move_line.py) - so 49

What are the steps to reproduce your issue?
Price Decimal Precision set at 5, currency at 2. Anglosaxon enabled. Have a product with a unit / purchase cost of 3.30125 Create Purchase for 1500.00 and receipt in.
This creates an SVL and AML for 4951.88
Create Bill with unit cost of 3.30125 and total amount of 4951.88 Confirm Invoice

What is the current behavior that you observe?
The layer unit price value is calculated unrounded (line 304, purchase_stock/models/account_move_line.py) - so 4951.88 / 1500 = 3.30125333333. This is then subtracted from the Invoice unit price leaving a difference of 0.00000333333 Despite the price_unit difference being less than the precision this then multiplies out to be 0.005 that gets rounded to 0.01. A new SVL layer is created, and a new move valued at 0.01 and remaining value on existing correct layer is reduced by 1c. When anglosaxon attempts to reconcile the various moves, it is unable to because there is now a 1c difference in the sum of the relevant AML's.

What would be your expected behavior in this case? Not to create useless SVL that is wrong
Reconcile anglosaxon records normally.

It happens due to the comparaison between the layer price unit that is not rounded and the price unit of the account.move.line that is rounded to the decimal accuracy. We want to keep the most accurate value so we modify _get_gross_price unit to recompute the unit price this way we ignore the rounding

close #140410

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#143768
Forward-Port-Of: odoo/odoo#141152

In grid mode, if an image is in an image column (with the class `o_grid_` `item_image`), it has the "Position" image option, allowing to select between "cover" (= the image takes the whole grid-area, which means it could be "cropped") and "contain" (= the image is entirely visible and keeps its ratio in the available space). When there is a shape on the image, this option is hidden and it is "contain" by default (or else the shapes would be cropped). See commit [1]. Commit [2] added the

In grid mode, if an image is in an image column (with the class `o_grid_`
`item_image`), it has the "Position" image option, allowing to select
between "cover" (= the image takes the whole grid-area, which means it
could be "cropped") and "contain" (= the image is entirely visible and
keeps its ratio in the available space). When there is a shape on the
image, this option is hidden and it is "contain" by default (or else the
shapes would be cropped). See commit [1].

Commit [2] added the "On Hover" animation option, to add hover effects
on images. In order for the effect to be applied, a shape is needed and
if no shape is specified, a dummy square shape is used instead. As there
is a shape, if it is a grid image, the "position" is forced to "contain"
(because of commit [1]).

The issue is that while it is logical for some hover effects to never be
"cover", as they could be cropped (i.e. "Outline", "Mirror Blur" and any
effect with a shape selected), it is not the case for the other effects
when there is no shape.

This commit improves this by allowing the "Position" option to be used
with these other hover effects when no shape is selected (so only with
the dummy square shape).

Steps to reproduce:
- In edit mode, drop the "Banner" snippet.
- Add the "Overlay" hover effect on the big image.
=> The image became "smaller" because it was forced to "contain".

[1]: https://github.com/odoo/odoo/commit/faf19ef7f87fc043fb9a814516e01b8eeafd9b61
[2]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85

task-3568406

Forward-Port-Of: odoo/odoo#141468

This PR prevents the editor to search for anchors when the link URL is an email. This way we prevent an error in the console. Related to runbot-18747 Forward-Port-Of: odoo/odoo#143791 Forward-Port-Of: odoo/odoo#143336

This PR prevents the editor to search for anchors when the link URL is an email. This way we prevent an error in the console.

Related to runbot-18747

Forward-Port-Of: odoo/odoo#143791
Forward-Port-Of: odoo/odoo#143336

### Summary Taxcloud taxes are always 0 on payment page. ### Steps to reproduce * install `website_sale_loyalty` and `website_sale_account_taxcloud` * configure taxcloud * enable 'Detect Automatically' on the 'Automatic Tax Mapping (TaxCloud)' fiscal position * go to ecommerce, and add a product to cart * go to cart * proceed to checkout You should see that the taxes are still 0 on the payment page ### Cause The issue comes from the `shop_payment()` override in `website_sale_loy

### Summary
Taxcloud taxes are always 0 on payment page.

### Steps to reproduce
* install `website_sale_loyalty` and `website_sale_account_taxcloud`
* configure taxcloud
* enable 'Detect Automatically' on the 'Automatic Tax Mapping (TaxCloud)' fiscal position
* go to ecommerce, and add a product to cart
* go to cart
* proceed to checkout

You should see that the taxes are still 0 on the payment page

### Cause
The issue comes from the `shop_payment()` override in `website_sale_loyalty`.  The taxcloud taxes are computed with `res = super(WebsiteSale, self).shop_payment(**post)`, but they are immediately cleared with
`order._update_programs_and_rewards()`

opw-3539027

Forward-Port-Of: odoo/odoo#142664

This PR - adds loggs to monitor the performance of the GPT calls during the apply of the configurator. - changes the timeout of the OLG call to 20s. Related to task-3248852 Forward-Port-Of: odoo/odoo#137703

This PR
- adds loggs to monitor the performance of the GPT calls during the apply of the configurator.
- changes the timeout of the OLG call to 20s.

Related to task-3248852

Forward-Port-Of: odoo/odoo#137703

This commit fixes the consistency issue missed in https://github.com/odoo/odoo/commit/a9dd388a1128ac406b6a5cec58b3833aadb04c62. Currently, to_check_vals dictionary has journal records as keys. Later, the total amount and count of account moves marked with `to_check` are retrieved by journal.id, which don't exist in the `to_check_vals` dictionary, so `to_check` value is never displayed on the dashboard. That dictionary should contain the actual ids instead. task-3611262 --- I confirm I

This commit fixes the consistency issue missed in https://github.com/odoo/odoo/commit/a9dd388a1128ac406b6a5cec58b3833aadb04c62. Currently, to_check_vals dictionary has journal records as keys. Later, the total amount and count of account moves marked with `to_check` are retrieved by journal.id, which don't exist in the `to_check_vals` dictionary, so `to_check` value is never displayed on the dashboard. That dictionary should contain the actual ids instead.

task-3611262



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

Forward-Port-Of: odoo/odoo#143801

This pr https://github.com/odoo/odoo/pull/143108 was breaking eCommerce. opw-3616105 Forward-Port-Of: odoo/odoo#144206 Forward-Port-Of: odoo/odoo#144154

This pr https://github.com/odoo/odoo/pull/143108 was breaking eCommerce.

opw-3616105

Forward-Port-Of: odoo/odoo#144206
Forward-Port-Of: odoo/odoo#144154

**Current behavior before PR:** Copy pasting table in firefox gives us traceback because the firefox does not support :has() selector. **Desired behavior after PR is merged:** Now it will not give any traceback. task-3591148 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141737

**Current behavior before PR:**

Copy pasting table in firefox gives us traceback because the firefox does not
support :has() selector.

**Desired behavior after PR is merged:**

Now it will not give any traceback.

task-3591148

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

Forward-Port-Of: odoo/odoo#141737

How to reproduce: - install a new DB without demo data and crm: -i crm --without-demo=1 - go to settings and click on "Load demo data" at the end of the page - the demo data will not be installed and the following error will appear in the logs "Assigned user Marc Demo has no access to the document and is not able to handle this activity." - and "Marc Demo" has no access to the CRM app If the "crm" module is installed with the demo data at the module installation, it works and "Marc Demo"

How to reproduce:
- install a new DB without demo data and crm: -i crm --without-demo=1
- go to settings and click on "Load demo data" at the end of the page
- the demo data will not be installed and the following error will appear in the logs "Assigned user Marc Demo has no access to the document and is not able to handle this activity."
- and "Marc Demo" has no access to the CRM app

If the "crm" module is installed with the demo data at the module installation, it works and "Marc Demo" has access to the CRM app.

The cause of the problem is that in the first case "Marc Demo" doesn't belong to group_sale_salesman while in the second case well.

By reverting partially the change that remove the group_sale_salesman by removing group_sale_salesman_all_leads (see odoo/odoo#139731), the problem is solved.

Technical note: the load of the demo data as a second step fails when creating an activity on a record for which "Marc Demo" has no access to because in the create method of mail_activity, we check that the user has access to the underlying record (_check_access_assignation). It works when installing the demo data while installing the module because in that case "Marc Demo" belongs to "group_sale_salesman" which give him the read access to the record. The solution here is to just re-add that group where it is removed indirectly by removing the group group_sale_salesman_all_leads from "Marc Demo".

Another solution would have been to remove this check (_check_access_assignation) as we don't need it anymore (see odoo/odoo#139917 where we display activities for which the user has no access to the underlying record from the menu in the systray). But it won't solve the consistency between installing the demo data while installing the module vs installing the demo data afterward. That's why this solution has been chosen, but we plan also to remove the check (_check_access_assignation) as it is no longer needed. Note that planning activities from the interface even if the assigned user has no access to the underlying record works because the flag "automated" is set to true in that case (that flag will probably also be removed).

Task-3600535

Forward-Port-Of: odoo/odoo#142806

Basing RPC purely on OWL rendering cycle is a bad idea, as anything can happen at any time, outside of our control in a complex application. Controls to (re)load is completely moved up to the form controller, which is closer to functional changes. This will fix an issue where `register_as_main_attachment` is called multiple times, sending the same invoice to OCR multiple times. https://github.com/odoo/enterprise/pull/51670 Forward-Port-Of: odoo/odoo#143867

Basing RPC purely on OWL rendering cycle is a bad idea, as anything can happen at any time, outside of our control in a complex application.

Controls to (re)load is completely moved up to the form controller, which is closer to functional changes.

This will fix an issue where `register_as_main_attachment` is called multiple times, sending the same invoice to OCR multiple times.

https://github.com/odoo/enterprise/pull/51670

Forward-Port-Of: odoo/odoo#143867

With this commit 963842381e2449ee59e5cffd1bae8656f5477e7a ClipboardJS was removed to use the native clipboard api. But here the innerText was checked instead of the value so there was nothing to copy in the clipboard. This commit fix this. Task-3607299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143206

With this commit 963842381e2449ee59e5cffd1bae8656f5477e7a ClipboardJS was removed to use the native clipboard api. But here the innerText was checked instead of the value so there was nothing to copy in the clipboard.
This commit fix this.

Task-3607299




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

Forward-Port-Of: odoo/odoo#143206

The items in the Peppol Bis 3 xml should all have a `Name` tag, otherwise a validator will raise: "[BR-25]-Each Invoice line (BG-25) shall contain the Item name (BT-153)." This `Name` is the product's name or the label in case of invoice line with no product set. task-3607354 Forward-Port-Of: odoo/odoo#144012 Forward-Port-Of: odoo/odoo#143178

The items in the Peppol Bis 3 xml should all have a `Name` tag, otherwise a validator will raise: "[BR-25]-Each Invoice line (BG-25) shall contain the Item name (BT-153)." This `Name` is the product's name or the label in case of invoice line with no product set.

task-3607354

Forward-Port-Of: odoo/odoo#144012
Forward-Port-Of: odoo/odoo#143178

Add Viva Wallet to the POS. A new payment method that allows payment in person via Smartphone 2991908 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#140353

Add Viva Wallet to the POS.
A new payment method that allows payment in person via Smartphone

2991908

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

With [commit 1], the editor toolbar was ported to OWL. One side effect of this port is that the condition for displaying the font size dropdown was no longer based on screen size but on the OS / Browser used. This lead to iPads not having the font size dropdown. This did not create a direct error on 16.4 but in 17.0, the dropdown was changed by [commit 2] and the assumption was that it would always be displayed. This leads to a traceback when starting website edition on an iPad. This co

With [commit 1], the editor toolbar was ported to OWL. One side effect of this port is that the condition for displaying the font size dropdown was no longer based on screen size but on the OS / Browser used. This lead to iPads not having the font size dropdown.

This did not create a direct error on 16.4 but in 17.0, the dropdown was changed by [commit 2] and the assumption was that it would always be displayed.

This leads to a traceback when starting website edition on an iPad.

This commit restores the original condition for displaying the font size dropdown which is based on screen size and not on browser.

Steps to reproduce the bug (17.0):
- Open Website on an iPad
- Start edition => Traceback

[commit 1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997
[commit 2]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0

opw-3594634
opw-3590980
opw-3594313
opw-3594615

Forward-Port-Of: odoo/odoo#143287

**Steps:** - Open Timesheet - Configuration > Time Encoding > Change Encoding Unit to Days - Now select Reporting > By Employee - When you select Measures, you can see Billable Days and Non-Billable Days - Now select Reporting > By Project / By Task - When you select Measures, you can see Billable Hours and Non-Billable Hours **Issue:** - Even after changing the Encoding Unit from Hours to Days, still we are able to have Measures in Hours instead of Days **Cause:** - Records are

**Steps:**
- Open Timesheet
- Configuration > Time Encoding > Change Encoding Unit to Days
- Now select Reporting  > By Employee
- When you select Measures, you can see Billable Days and Non-Billable Days
- Now select Reporting  > By Project / By Task
- When you select Measures, you can see Billable Hours and Non-Billable Hours

**Issue:**
- Even after changing the Encoding Unit from Hours to Days, still we are able to have Measures in Hours instead of Days

**Cause:**
- Records are not made for project and task which changes on the change of encoding unit.

**Fix:**
- adding records in 'timesheet_analysis_views' for project and task for graph and pivot views so that it updates when changed the encoding unit.

Technical Explanation:

'timesheet_uom' is used to define the unit of measure for time entries in a
timesheet. It represents the measurement unit that is used to record and track
time spent on specific tasks or activities. For example, it could be set to
'hours' or 'days' depending on the organisation's requirements.

'float_time' is used for representing time duration or intervals. It allows
users to input and display time values in a decimal format, such as hours and
minutes. The float_time widget provides a convenient way to handle time
calculations and representations.

These two concepts serve different purposes but can be related in the context of
tracking time-related data. The timesheet_uom field determines the unit of
measure for time entries, while the float_time widget allows for inputting and
displaying time values in a convenient decimal format.

If we use 'timesheet_uom', the data on the server side will always be displayed
in hours or days, which could be confusing for the user. Another issue arises
when the work hours for a day are not 8 hours but rather 7.5 hours. The
conversion is not accurate since it assumes 8 hours per day in all cases.
Hence, by using 'float_time', the process of exporting the data can be
streamlined.

Task-3387850

Forward-Port-Of: odoo/odoo#127030

Current behavior: When you use a coupon that gives a free product combined with a promo that gives 50% discount. The reward of 50% disappears when you add the free product. Steps to reproduce: - Create 2 program with no conditions : - One that gives 50% discount on all products with a code - One that gives a free product A - Make sure product A has a tax - Open PoS - Add a product with no tax to the order - Apply the 50% discount - Add product A - The reward of 50% disappears

Current behavior:
When you use a coupon that gives a free product combined with a promo that gives 50% discount. The reward of 50% disappears when you add the free product.

Steps to reproduce:
- Create 2 program with no conditions :
  - One that gives 50% discount on all products with a code
  - One that gives a free product A
- Make sure product A has a tax
- Open PoS
- Add a product with no tax to the order
- Apply the 50% discount
- Add product A
- The reward of 50% disappears

Note:
This happens because we try to apply a 50% discount on amount that is 0 wich leads to a reward with a NaN amount. Wich makes the reward for the program disappears, because here (https://github.com/odoo/odoo/blob/15.0/addons/pos_coupon/static/src/js/coupon.js#L624) `currentMaxKey` is null.

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

Forward-Port-Of: odoo/odoo#142527
Forward-Port-Of: odoo/odoo#141279

Steps to reproduce: ------------------- - go to ecommerce; - click on "Product A"; We see the breadcrumb: All Products / Product A - go to shop page; - go to the category of "Product A"; - click on "Product A"; We see the breadcrumb: All Products / Product A instead of: All Products / Category / Product A Cause: ------ The template used for the breadcrumb is cached. Solution: --------- Use the `t-nocache` attribute to re-evaluate this part of the template each time

Steps to reproduce:
-------------------
- go to ecommerce;
- click on "Product A";
    We see the breadcrumb: All Products / Product A
- go to shop page;
- go to the category of "Product A";
- click on "Product A";
    We see the breadcrumb: All Products / Product A
    instead of: All Products / Category / Product A

Cause:
------
The template used for the breadcrumb is cached.

Solution:
---------
Use the `t-nocache` attribute to re-evaluate this part of the template each time it is rendered.

opw-3582971

Forward-Port-Of: odoo/odoo#143780

When dragging an item over a grid, a `mousemove` event listener is added on the dragged element to adjust the position of the dragged item's preview inside the hovered grid. The problem is that between the time at which the grid is hovered (when the event listener is added) and the time at which a first `mousemove` event is emitted, the item preview is wrongly positioned inside the grid. Dropping the item in that state also then leads to wrong calculations when determining the area to be used i

When dragging an item over a grid, a `mousemove` event listener is added on the dragged element to adjust the position of the dragged item's preview inside the hovered grid.
The problem is that between the time at which the grid is hovered (when the event listener is added) and the time at which a first `mousemove` event is emitted, the item preview is wrongly positioned inside the grid. Dropping the item in that state also then leads to wrong calculations when determining the area to be used inside the grid.

This commit addresses this by simulating a first call to the newly added event listener, using the event with the coordinates that triggered the `over`.

Steps to reproduce:
- drag a "Text - Image" block into the page
- toggle it to grid mode
- select the image
- move the image's top border down one cell
- click and hold the image's move icon
- move by 1 pixel (easier done with a mouse)

=> The image was positioned in the top-left corner of the grid.

task-3554752

Forward-Port-Of: odoo/odoo#143903
Forward-Port-Of: odoo/odoo#140633

Since [this other commit], we use classes to change the font size of text. Unfortunately, we forgot to make them responsive. This commit fixes that. [this other commit]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0 task-3615976 Forward-Port-Of: odoo/odoo#144047

Since [this other commit], we use classes to change the font size of text. Unfortunately, we forgot to make them responsive. This commit fixes that.

[this other commit]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0

task-3615976

Forward-Port-Of: odoo/odoo#144047

When uploading an invoice/bill from an xml, if the partner is not found, the useful informations from the xml file should be displayed in the chatter. opw-3563769 Forward-Port-Of: odoo/odoo#144073 Forward-Port-Of: odoo/odoo#144010

When uploading an invoice/bill from an xml,
if the partner is not found, the useful informations
from the xml file should be displayed in the chatter.

opw-3563769

Forward-Port-Of: odoo/odoo#144073
Forward-Port-Of: odoo/odoo#144010

The goal of this PR is to prevent the text animation overlay from blocking small text content selection. Remark: This behavior was already fixed on 17.0 (by [1]) for text animations and highlights and was backported here for text animation options. [1]: https://github.com/odoo/odoo/commit/f64c9f27f1a9106bc009ad2f696845f2c5c58066 Related to task-3285817 Forward-Port-Of: odoo/odoo#144086 Forward-Port-Of: odoo/odoo#142833

The goal of this PR is to prevent the text animation overlay from blocking
small text content selection.

Remark: This behavior was already fixed on 17.0 (by [1]) for text
animations and highlights and was backported here for text animation
options.

[1]: https://github.com/odoo/odoo/commit/f64c9f27f1a9106bc009ad2f696845f2c5c58066

Related to task-3285817

Forward-Port-Of: odoo/odoo#144086
Forward-Port-Of: odoo/odoo#142833

[FIX] website: consider other media types for Social Media snippet icons When using the "Social Media" snippet, there are two situations leading to a traceback. Here are the steps: 1) First issue - In edit mode, drop the "Social Media" snippet. - Add a new social network. - Replace the icon by a real image (so not by an other icon). - Set the URL of the new social network to a "relevant" one (e.g. google, facebook). => traceback 2) Second issue - Drop "Social Media" and change the

[FIX] website: consider other media types for Social Media snippet icons

When using the "Social Media" snippet, there are two situations leading to a traceback. Here are the steps:

1) First issue
- In edit mode, drop the "Social Media" snippet.
- Add a new social network.
- Replace the icon by a real image (so not by an other icon).
- Set the URL of the new social network to a "relevant" one (e.g. google, facebook).
=> traceback

2) Second issue
- Drop "Social Media" and change the list in order to have the first social network with a real image as icon: either replace the first icon with an image, or add a custom one with an image an move it to the top.
- Add a new social network. 
=> traceback

Both issues happen because only icons set as `<i>` elements are taken into account when modifying a social network (`querySelector('i')`) and this element may not exist if the icon had another tag (like an image or a span or even a video (as the media dialog allows to upload them)). As there is no check ensuring that the element exists before changing the different social media classes, there is a traceback when the `<i>` is not found.

For the first issue, it happens because when changing the URL, we first check if it matches with relevant ones or if an icon matching it exists. If it is the case, we then update the social media classes to set the matching icon => it can only work if the icon is a `<i>`.

The second issue happens because when adding a new social network, it actually copies the style of the first one (unless there are none, a new one is created in that case). If the first one is an image, it fails when updating the classes because it is not a `<i>`.

This commit fixes these issues by simply adding checks ensuring the icon element exists before trying to modify it. It also adds tests, ensuring these use cases work as expected.

opw-3538230

---
[FIX] website: consider `<span>` icons in Social Media snippet

In the Social Media snippet options, only icons with a `<i>` tag are
considered when updating the social media classes (when adding a new
social network by copying the first one and when replacing the icon by
another one matching the URL). However, there are cases where the icon
is a `<span>` element (with a `fa` class) and not a `<i>`.

For example:
- Replace a social network icon by a real image.
- Re-replace this image by an icon.
=> the icon element tag is `<span>` and not `<i>`.

In this case, after setting its style correctly (e.g. adding the round
shape) to make it look like the other icons, we notice that it does not
behave like the other ones:
- It is not aligned with the other icons, because the CSS rule aligning
them only targets `<i>`.
- Its icon is not replaced by a matching one when changing the URL with
a "relevant" one (e.g. google, facebook).

This commit considers `<span>` icons in the Social Media options, in
addition to `<i>` icons, in order for them to all behave the same way.

opw-3538230

Forward-Port-Of: odoo/odoo#144076
Forward-Port-Of: odoo/odoo#142280

This commit is the communitiy counter-part to allow copying a dashboard. With this commit, we can now write on 'raw' field. It allows to give a value for the field when calling 'copy'. Yet another 'copy' overrride to add the same postfix! Task: 3588237 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144091 Forward-Port-Of: odoo/odoo#141639

This commit is the communitiy counter-part to allow copying a dashboard.
With this commit, we can now write on 'raw' field. It allows to give a value
for the field when calling 'copy'.

Yet another 'copy' overrride to add the same postfix!

Task: 3588237



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

Forward-Port-Of: odoo/odoo#144091
Forward-Port-Of: odoo/odoo#141639

1) Create + Confirm two MO's for product 2) Merge Confirmed MO's together 3) Mark MO as Done 4) Press Apply on Immediate Production 4a) Stops consumption due to no Components being declared 4b) Would expect the Consumption Warning Wizard to be triggered here to allow use of "Validate & Set Quantities" button It happens due to #85301 the purpose was to avoid the rules from stock.move. However for other functionalities of MO like manual consumption. We would like to keep the standard behavi

1) Create + Confirm two MO's for product
2) Merge Confirmed MO's together
3) Mark MO as Done
4) Press Apply on Immediate Production
4a) Stops consumption due to no Components being declared 4b) Would expect the Consumption Warning Wizard to be triggered here to allow use of "Validate & Set Quantities" button

It happens due to #85301 the purpose was to avoid the rules from stock.move. However for other functionalities of MO like manual consumption. We would like to keep the standard behavior.

Call the classic action_confirm but after manualy updated the stock.move

opw-3577267

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

Before This Commit: Currently, the e-invoice is bydefault set to true in journal. Also there is an option to enable e-waybill in journal. After This Commit: Now, the e-invoice will be bydefault set to false in journal. Also there is no need to have option of e-waybill in journal as we have separate button to submit the e-waybill. Task - 3617047 Enterprise - https://github.com/odoo/enterprise/pull/51737 Forward-Port-Of: odoo/odoo#144128

Before This Commit:
Currently, the e-invoice is bydefault set to true in journal. Also there is an option to enable e-waybill in journal.

After This Commit:
Now, the e-invoice will be bydefault set to false in journal. Also there is no need to have option of e-waybill in journal as we have separate button to submit the e-waybill.

Task - 3617047

Enterprise - https://github.com/odoo/enterprise/pull/51737

Forward-Port-Of: odoo/odoo#144128

Move '_create_mailing_list' as a base mass mailing tool to make it easily usable by most mail-related test addons. Improve some logs to ease debugging, notably for marketing automation. Add a tool to simulate opening a mailing at trace level in addition to existing tools to simulate a click or a bounce Task-3506681 (MA: Test cleanup) Task-2981581 (MA: Fix trace duplication and various issues) Forward-Port-Of: odoo/odoo#143088 Forward-Port-Of: odoo/odoo#141773

Move '_create_mailing_list' as a base mass mailing tool to make it easily
usable by most mail-related test addons.

Improve some logs to ease debugging, notably for marketing automation.

Add a tool to simulate opening a mailing at trace level in addition to existing
tools to simulate a click or a bounce

Task-3506681 (MA: Test cleanup)
Task-2981581 (MA: Fix trace duplication and various issues)

Forward-Port-Of: odoo/odoo#143088
Forward-Port-Of: odoo/odoo#141773

Several corner cases in marketing automation may lead to duplicate traces for a given activity / participant pair. This leads notably to statistics being wrong, as well as traces that are canceled e.g. a mailing sent several times on the same record uses the same email and is thus ignored once a first email is sent. With this task we fix several issues leading to trace duplication, notably * a datetime comparison failing when comparing datetime.now and sql.now; * synchornization n

Several corner cases in marketing automation may lead to duplicate traces
for a given activity / participant pair. This leads notably to statistics
being wrong, as well as traces that are canceled e.g. a mailing sent several
times on the same record uses the same email and is thus ignored once a
first email is sent.

With this task we fix several issues leading to trace duplication, notably

  * a datetime comparison failing when comparing datetime.now and sql.now;
  * synchornization not taking into account participants already having
    traces;
  * campaign duplication with synchronization date leading to duplicate
    traces;

Tests are added for those use cases, to try to avoid future regressions
as much as possible.

Task-3506681 (MA: Test cleanup)
Task-2981581 (MA: Fix trace duplication and various issues)

Forward-Port-Of: odoo/enterprise#51232
Forward-Port-Of: odoo/enterprise#47413

Before This Commit: Currently, the l10n_in_reports_gstr is not auto-installed After This Commit: Now, the l10n_in_reports_gstr will be installed automatically installed if `l10n_in_reports` is installed. Task - 3617047 Community - https://github.com/odoo/odoo/pull/144128 Forward-Port-Of: odoo/enterprise#51737

Before This Commit:
Currently, the l10n_in_reports_gstr is not auto-installed

After This Commit:
Now, the l10n_in_reports_gstr will be installed automatically installed if `l10n_in_reports` is installed.

Task - 3617047

Community - https://github.com/odoo/odoo/pull/144128

Forward-Port-Of: odoo/enterprise#51737

During a PDF export, the way the horizontal group name was fetched was incorrect and led to an index error. This commit fixes it. Forward-Port-Of: odoo/enterprise#51649

During a PDF export, the way the horizontal group name was fetched was incorrect and led to an index error. This commit fixes it.

Forward-Port-Of: odoo/enterprise#51649

Steps to reproduce the bug: - Install `timesheet_grid` module - Ensure you have some timesheet to submit to managers - Go to Settings and Activate the timesheet `Manager Reminder` - Ensure that the `Next scheduled date for manager reminder` on the company is set to a date in the past (at least before today) - Run the CRON `Timesheet: Managers Email Reminder` Issue: The mails are not sent. Cause: The CRON fetch the companies with the next scheduled date that

Steps to reproduce the bug:

  - Install `timesheet_grid` module
  - Ensure you have some timesheet to submit to managers
  - Go to Settings and Activate the timesheet `Manager Reminder`
  - Ensure that the `Next scheduled date for manager reminder` on the
    company is set to a date in the past (at least before today)
  - Run the CRON `Timesheet: Managers Email Reminder`

Issue:

  The mails are not sent.

Cause:

  The CRON fetch the companies with the next scheduled date that is
  set between today 00:00:00 and today 23:59:59.

Solution:

  Fetch all companies that have a next scheduled date before
  today 23:59:59.

Inspired by https://github.com/odoo/enterprise/commit/901962e93a8117752bc49c3f480c5e3ea83f7ea2

opw-3432435

Forward-Port-Of: odoo/enterprise#51707
Forward-Port-Of: odoo/enterprise#51370

### Summary If you create a Whatsapp template for the Journal Entry model, a error can appear if you try to submit it for approval. ### Steps to reproduce * install `whatsapp_account` * create a whatsapp template for the Journal Entry model * try to submit it for approval You should be met with the following message: "Only invoices could be printed." ### Cause The Journal Entry model (aka `account.move`) can be divided in two types: generic Journal Entries and Invoices (bill

### Summary

If you create a Whatsapp template for the Journal Entry model, a error can appear if you try to submit it for approval.

### Steps to reproduce

* install `whatsapp_account`
* create a whatsapp template for the Journal Entry model
* try to submit it for approval

You should be met with the following message:
"Only invoices could be printed."

### Cause

The Journal Entry model (aka `account.move`) can be divided in two types: generic Journal Entries and Invoices (bill, receipt, ...). One difference between generic Journal Entries and Invoices is that Journal Entries are not intended to be printed.

When a user submits a whatsapp template with the Header Type set to document, a sample record is selected to generate a demo PDF. In our case, that record will be an `account.move`. The issue occurs because that sample record can be a generic Journal Entry (i.e. not printable).


### Fix

This commit ensures that the selected sample `account.move` is always an invoice.

opw-3543875

Forward-Port-Of: odoo/enterprise#51667
Forward-Port-Of: odoo/enterprise#51279

In this PR ======================= Currency rate provider service is set as xe.com as default for the companies in India. task - 3614513 Forward-Port-Of: odoo/enterprise#51648

In this PR
=======================
Currency rate provider service is set as xe.com as default for the companies in India.

task - 3614513

Forward-Port-Of: odoo/enterprise#51648

Fixed the issue when click on the numpad (number or backspace), cursor position is always ignored. Forward-Port-Of: odoo/enterprise#51348

Fixed the issue when click on the numpad (number or backspace), cursor position is always ignored.

Forward-Port-Of: odoo/enterprise#51348

Test of fix in community commit. https://github.com/odoo/odoo/pull/143867 Forward-Port-Of: odoo/enterprise#51670

Test of fix in community commit.

https://github.com/odoo/odoo/pull/143867

Forward-Port-Of: odoo/enterprise#51670

The UPS http server is mocked to always returns mocked XML content. That mocked content was hardcoded inside the python code, which resulted in multiple huge unreadable strings. Because of their inclusion in python file, global regexp search inside the enterprise repository could match inside those string even if the search excluded non python file. This is the actual motivation of this work, to extract the XML hardcoded document inside XML files on disk so that global text search don't wrong

The UPS http server is mocked to always returns mocked XML content. That mocked content was hardcoded inside the python code, which resulted in multiple huge unreadable strings.

Because of their inclusion in python file, global regexp search inside the enterprise repository could match inside those string even if the search excluded non python file. This is the actual motivation of this work, to extract the XML hardcoded document inside XML files on disk so that global text search don't wrongly match those lines.

Inside the second XML document entitled "shipment_request.xml" were three assets inlined as very long base64 strings. Those assets have been extracted, base64 decoded and stored on disk in dedicated files. This ease understanding both the content of the XML files and to make it possible to open the assets. The original document (with inlined base64 assets) is reconstructed at runtime.

Using `functools.lru_cache` to lazily open and read the files upon first usage, this prevent loading the files in case the test is actually not run, this also loads the files only once for all test cases.

Forward-Port-Of: odoo/enterprise#51480

The no_start_next context key defines if mrp.workorder.do_finish will return an action to start the next workorder. It is used when we click the "Mark as Done and Close MO" button to redirect the user from the tablet view to the workorders kanban view. If the user wants to process next workorders without having to get back to the kanban view, he can use "Mark as Done", but the manufacturing order will not be closed automatically and he will have to close the MOs manually in the backend.

The no_start_next context key defines if mrp.workorder.do_finish
will return an action to start the next workorder. It is used
when we click the "Mark as Done and Close MO" button to redirect
the user from the tablet view to the workorders kanban view.

If the user wants to process next workorders without having to
get back to the kanban view, he can use "Mark as Done", but
the manufacturing order will not be closed automatically and
he will have to close the MOs manually in the backend.

Having this value hardcoded in the backend did not allow to
customize this behaviour by changing the value of the context
key on the button through an extension view.


Depends on:
 - [x] #48988

Forward-Port-Of: odoo/enterprise#48990

Task: 3596494 After "viewtiverse" changes in 17.0, many values are no longer stored in context. That includes carrier types obtained from Easypost API calls. The result is that, even though the API call is successful, the carrier type dropdown is empty. After discussing this issue with both framework teams, a solution was chosen: implement a small custom widget, which will extract the available carrier types in JS (where all context values are still present). Forward-Port-Of: odoo/enterprise

Task: 3596494

After "viewtiverse" changes in 17.0, many values are no longer stored in context. That includes carrier types obtained from Easypost API calls. The result is that, even though the API call is successful, the carrier type dropdown is empty. After discussing this issue with both framework teams, a solution was chosen: implement a small custom widget, which will extract the available carrier types in JS (where all context values are still present).

Forward-Port-Of: odoo/enterprise#51582

Before this commit `float_round` was used to round `InsuredValue` which can lead to issues described here: https://github.com/odoo/odoo/issues/20856 In case of a floating point error, DHL returns: ```111: Error in parsing request XML:Error: cvc-fractionDigits-valid: Value '4874.4980000000005' has 13 fraction digits, but the number of fraction digits has been limited to 3.``` To fix this, we need to use `float_repr` to send the correct number of fraction digits. opw-3602063 Forward-Port-Of

Before this commit `float_round` was used to round `InsuredValue` which can lead to issues described here: https://github.com/odoo/odoo/issues/20856 In case of a floating point error, DHL returns: ```111: Error in parsing request XML:Error: cvc-fractionDigits-valid: Value '4874.4980000000005' has 13 fraction digits, but the number of fraction digits has been limited to 3.```

To fix this, we need to use `float_repr` to send the correct number of fraction digits.

opw-3602063

Forward-Port-Of: odoo/enterprise#51641

Steps to reproduce: - Install Accounting and l10n_cl_edi - Switch to a Chilean company (e.g. CL Company) (1) - Activate a foreign currency (e.g. USD) - Create an invoice: * Customer: [a Chilean customer] (e.g. Blanco Martin & Asociados EIRL) * Currency: USD * Document Type: (33) Factura Electrónica * Invoice Lines: [a line with a product and a tax] - Confirm the invoice - Add credit note: * Credit Method: Partial Refund * Reason: [any] * Only Text Correction: [check

Steps to reproduce:
- Install Accounting and l10n_cl_edi
- Switch to a Chilean company (e.g. CL Company)

(1)
- Activate a foreign currency (e.g. USD)
- Create an invoice:
  * Customer: [a Chilean customer] (e.g. Blanco Martin & Asociados EIRL)
  * Currency: USD
  * Document Type: (33) Factura Electrónica
  * Invoice Lines: [a line with a product and a tax]
- Confirm the invoice
- Add credit note:
  * Credit Method: Partial Refund
  * Reason: [any]
  * Only Text Correction: [checked]
- Click on "REVERSE"
- Confirm the credit note
=> A ZeroDivision Error is raised.

(2)
- Create an invoice:
  * Customer: [any foreign customer] (e.g. Azure Interior)
  * Currency: CPL
  * Document Type: (110) Factura Exportación Electrónica
  * Invoice Lines: [a line with a product without tax]
- Confirm the invoice
- Add credit note:
  * Credit Method: Partial Refund
  * Reason: [any]
  * Only Text Correction: [checked]
- Click on "REVERSE"
- On the credit note, set "(112) Nota de Crédito de Exportación Electrónica" as Document Type
- Confirm the credit note
=> A ZeroDivision Error is raised.

Cause:
The "Only Text Correction" option is creating a credit note with a line in which only the label matters. All the other values are empty causing the error in some division.

opw-3591417

Forward-Port-Of: odoo/enterprise#51689