We use a "distant_display" if no display is connected to the IoT, in order to use the customer display on another computer. We don't need to send it to the database though, as it could confuse users. Task: 4061443 Forward-Port-Of: odoo/odoo#175191

We use a "distant_display" if no display is connected to the IoT, in order to use the customer display on another computer. We don't need to send it to the database though, as it could confuse users.

Task: 4061443

Forward-Port-Of: odoo/odoo#175191

Before this commit: - There was no option to hide the time part from the datetime widget. After this commit: - A 'show_time' option is added to the datetime widget. When set to false, it hides the time part from the datetime. Enterprise PR:  https://github.com/odoo/enterprise/pull/67258 Task-3698841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161705

Before this commit:
- There was no option to hide the time part from the datetime widget.

After this commit:
- A 'show_time' option is added to the datetime widget. When set to false, it
hides the time part from the datetime.

Enterprise PR:  https://github.com/odoo/enterprise/pull/67258

Task-3698841

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

Forward-Port-Of: odoo/odoo#161705

Commit [1] replaced the dialogs from legacy to OWL ones, but also created a deadlock by not resolving the promise set by the dialog. This commit fixes that by properly resolving the promise regardless of the user's answer. [1]: https://github.com/odoo/odoo/commit/00c9a7919768df71e79b5d34e21064729443c5fe Forward-Port-Of: odoo/odoo#175095

Commit [1] replaced the dialogs from legacy to OWL ones, but also created a deadlock by not resolving the promise set by the dialog.

This commit fixes that by properly resolving the promise regardless of the user's answer.

[1]: https://github.com/odoo/odoo/commit/00c9a7919768df71e79b5d34e21064729443c5fe

Forward-Port-Of: odoo/odoo#175095

Before this commit, when message author is too long, it displays a horizontal scrollbar in a chat window. Steps to reproduce: - Rename Demo User with a very long name - As Mitchell Admin, open a chat window DM with former Demo User There was a `text-truncate` to manage overflow, but this didn't work and instead put an implicit `overflow-auto` which causes this horizontal scrollbar as a result. `text-truncate` is actually not good even if it worked, because this would mean the name i

Before this commit, when message author is too long, it displays a horizontal scrollbar in a chat window.

Steps to reproduce:

- Rename Demo User with a very long name
- As Mitchell Admin, open a chat window DM with former Demo User

There was a `text-truncate` to manage overflow, but this didn't work and instead put an implicit `overflow-auto` which causes this horizontal scrollbar as a result.

`text-truncate` is actually not good even if it worked, because this would mean the name is not fully visible. And adding a `title` with full name adds a floating UI elements, which is bothersome. We should not be afraid of default wrap behavior when the text is long.

This commit fixes the issue by simply removing `text-truncate`, which makes the text wrap when it's too long.

Before / After
![before](https://github.com/user-attachments/assets/51f045b2-7380-4671-af52-903182ba4ad1) ![after](https://github.com/user-attachments/assets/eca14e2b-7b42-460a-8d31-a411d6492cf3)

Forward-Port-Of: odoo/odoo#174954

The aim of this commit is to fix runbot build error. Before the commit: The test could fail if the EUR currency was inactive After the commit: The test activate the currency first --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173764

The aim of this commit is to fix runbot build error.

Before the commit:
The test could fail if the EUR currency was inactive

After the commit:
The test activate the currency first


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

Forward-Port-Of: odoo/odoo#173764

Issue: The `_get_weight` method is called for each location to compute the weight and it sums up all the incoming and outgoing lines for forecasted weight. Using filtered for each record is compute intensive and gets slower over time. While returning a delivery with 30 stock moves the _create_return took 7:41 minutes most of which were on `_get_weight`. Here filtered alone was taking over 6 minutes. 

Issue:
The `_get_weight` method is called for each location to compute the weight and it sums up all the incoming and outgoing lines for forecasted weight. Using filtered for each record is compute intensive and gets slower over time.

While returning a delivery with 30 stock moves the _create_return took 7:41 minutes most of which were on `_get_weight`. Here filtered alone was taking over 6 minutes.
![image](https://github.com/odoo/odoo/assets/111344786/52f2bdef-f486-4e07-aab3-0ced1d68bd1c)

For a single run, 
|| Before| 
| --------- | ------------- | 
|Quants| 5474  | 
|Outgoing Move Lines| 38020  | 
|Incoming Move Lines| 150935 |
|Time| 246.05s |

Solution:
Optimized the `_get_weight` method to use `read_group` to get the sum of incoming and outgoing lines. This reduces the number of reads. Total time for the same return reduced to 28s.

![image](https://github.com/odoo/odoo/assets/111344786/9cc83c93-3502-44a2-af54-9a269a98394a)
For a single run:
|| After| 
| --------- | ------------- | 
|Quants| 5474  | 
|Outgoing Move Lines| 38020  | 
|Incoming Move Lines| 150935 |
|Time| 0.4s |
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#174660
Forward-Port-Of: odoo/odoo#170675

to reproduce: ============= - install the module l10n_fr_hr_holidays - create calendar for company Mon -> Fri 9:00 -> 12:00, 13:00 -> 18:00 - create calendar for employee Mon -> Fri 8:00 -> 12:00, 14:00 -> 17:00 - change `request_unit` for the paid time off to `half_day` - take a a monday off for the employee -> the duration is 0.9 days instead of 1 day Problem: ======== we compute the duration of the leave using the hours from the employee calendar but based on the company calendar,

to reproduce:
=============
- install the module l10n_fr_hr_holidays
- create calendar for company Mon -> Fri 9:00 -> 12:00, 13:00 -> 18:00
- create calendar for employee Mon -> Fri 8:00 -> 12:00, 14:00 -> 17:00
- change `request_unit` for the paid time off to `half_day`
- take a a monday off for the employee -> the duration is 0.9 days instead of 1 day

Problem:
========
we compute the duration of the leave using the hours from the employee calendar but based on the company calendar, where the day of the employee ends at 17:00 but the day of the company ends at 18:00, so this difference is impacting the duration of the leave

Solution:
=========
when computing the duration of the leave, we extend the hours of start and end of the day to the company calendar.

opw-3898282

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

Forward-Port-Of: odoo/odoo#174841

Before this commit, it was possible to add a pricelist in a different currency than the config currency, which is not supported. opw-4073993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175103

Before this commit, it was possible to add a pricelist in a different currency than the config currency, which is not supported.

opw-4073993

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

Forward-Port-Of: odoo/odoo#175103

Before the commit: To reproduce the error: In POS, when we go to the information page of a product and select an attribute, we perform a search to match the product name with the category_search_string (a long string). If the string is too long, the page freezes. After the commit: We pass the product.tmpl.id in the query so we can retrieve all products with the same product_tmpl_id and perform the match only within this list. opw-3992954 --- I confirm I have signed the CLA and read t

Before the commit:
To reproduce the error: In POS, when we go to the information page of a product and select an attribute, we perform a search to match the product name with the category_search_string (a long string). If the string is too long, the page freezes.

After the commit:
We pass the product.tmpl.id in the query so we can retrieve all products with the same product_tmpl_id and perform the match only within this list.

opw-3992954

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

Forward-Port-Of: odoo/odoo#170766

Before this commit, scanning a barcode on the payment screen would mistakenly capture the barcode value as the payment amount. This could lead to incorrect payment amounts being recorded if not noticed by the cashier. opw-4079147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175048 Forward-Port-Of: odoo/odoo#174992

Before this commit, scanning a barcode on the payment screen would mistakenly capture the barcode value as the payment amount. This could lead to incorrect payment amounts being recorded if not noticed by the cashier.

opw-4079147

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

Forward-Port-Of: odoo/odoo#175048
Forward-Port-Of: odoo/odoo#174992

Steps to reproduce: - Sell any item in POS (Pick item > Payment > Bank > Validate) - Print receipt with 0 margin (current default) on external printer - Leftmost part of the receipt is truncated Why is this an issue: Frankly, since this issue only occurs on external printers and we haven't had complaints from people using Odoo supported devices (by that I mean connected to an IoT box) this could be considered not to be our problem. The receipt margins have been made smaller since 15.0 tho

Steps to reproduce:
- Sell any item in POS (Pick item > Payment > Bank > Validate)
- Print receipt with 0 margin (current default) on external printer
- Leftmost part of the receipt is truncated

Why is this an issue:
Frankly, since this issue only occurs on external printers and we haven't had complaints from people using Odoo supported devices (by that I mean connected to an IoT box) this could be considered not to be our problem. The receipt margins have been made smaller since 15.0 though so there could be more people with this issue. I've tried printing one here and it is very slightly cut off, but that might depend on the device.

What this fix does:
This fix aims to reestablish margins as close to the way they were in 15.0 as possible (Don't want to go overboard and cut off the right)
As it was in this commit b29c4a6113a002528aeed1fa59e823172bfce841

opw-3996929

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

Forward-Port-Of: odoo/odoo#173669

When the event is deleted and the user tries to download tickets for that event, a traceback will appear. Steps to reproduce the error: - Go to Website > Events > Open any event > register > confirm registration of the ticket - Go to Events > Open that event > delete attendees > delete that event - Download tickets of that event Traceback: ``` TypeError: unsupported operand types(s) or combination of types: 'str' and 'event.event' File "odoo/http.py", line 2248, in __call__ r

When the event is deleted and the user tries to download tickets for that event,
a traceback will appear.

Steps to reproduce the error:
- Go to Website > Events > Open any event > register > confirm registration of the ticket
- Go to Events > Open that event > delete attendees > delete that event
- Download tickets of that event

Traceback:
```
TypeError: unsupported operand types(s) or combination of types: 'str' and 'event.event'
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1966, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/event/controllers/main.py", line 50, in event_my_tickets
    if not consteq(tickets_hash, hash_truth):
```

https://github.com/odoo/odoo/blob/7b9df7c95c5f6a96d4d00c5d64e394141124752b/addons/event/controllers/main.py#L50 Here, when user deletes the event, 'event_sudo' will be empty,
So, eventually 'hash_truth' will be empty.
So it will lead to the above traceback.

sentry-5499927956

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

Forward-Port-Of: odoo/odoo#169921

Fixed `test_industry_fsm_at_install` by activating the pricelist before creating the sale order to ensure a proper link. task-4070526 Forward-Port-Of: odoo/enterprise#67612

Fixed `test_industry_fsm_at_install` by activating the pricelist before creating the sale order to ensure a proper link.


task-4070526

Forward-Port-Of: odoo/enterprise#67612

After making changes in community PR: https://github.com/odoo/odoo/pull/161705 The datetime widget was not being applied when we dragged and dropped a datetime field from the studio. Steps to reproduce: - Open the Sales module and toggle Studio. - Drag and drop a datetime field into the list view. - Try to tick and untick the Show time option. Observed behavior: When ticking and unticking the show time option, the time part is not hiding before resetting the widget. Expected be

After making changes in community PR: https://github.com/odoo/odoo/pull/161705

The datetime widget was not being applied when we dragged and dropped a datetime field from the studio.

Steps to reproduce:

- Open the Sales module and toggle Studio.
- Drag and drop a datetime field into the list view.
- Try to tick and untick the Show time option.

Observed behavior:
When ticking and unticking the show time option, the time part is not hiding before resetting the widget.

Expected behavior:
The time part should be hidden when we tick and untick the show time option without resetting the widget.

After this commit, the datetime widget will be applied when we drag and drop a datetime field from the studio and untick the show time boolean.

Task-3698841

Forward-Port-Of: odoo/enterprise#67258

Steps to reproduce: - Install Subscriptions - Create a new branch for your main company - Switch to that branch and create a subscription - On the "Company" field set it to the branch - Add a subscription with the new product - Confirm it - Switch to the main company and untick the branch - Schedule action -> "Sale Subscription: generate recurring invoices and payments" - Run it Issues: A traceback is shown in the logs, an invoice is created but left on draft. This is because the d

Steps to reproduce:
- Install Subscriptions
- Create a new branch for your main company
- Switch to that branch and create a subscription
- On the "Company" field set it to the branch
- Add a subscription with the new product
- Confirm it
- Switch to the main company and untick the branch
- Schedule action -> "Sale Subscription: generate recurring invoices and payments"
- Run it

Issues:
A traceback is shown in the logs, an invoice is created but left on
draft. This is because the deferred moves created is with the main
company while the invoice is set to the branch which causes a mismatch.

opw-3879384

Forward-Port-Of: odoo/enterprise#65190

Steps to reproduce ================== - Go to Accounting > Customer Invoices - Open studio - Switch to the Reports tab - Open the Invoices report - Click on "Reset Report" a few times => Eventually, OdooEditor will crash with an error like `Cannot read properties of undefined (reading 'innerHTML')` Cause of the issue ================== `onIframeLoaded` was called before the default report has been loaded. Solution ======== only update the render key after the report

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

- Go to Accounting > Customer Invoices
- Open studio
- Switch to the Reports tab
- Open the Invoices report
- Click on "Reset Report" a few times

=> Eventually, OdooEditor will crash with an error like
   `Cannot read properties of undefined (reading 'innerHTML')`

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

`onIframeLoaded` was called before the default report has been loaded.

Solution
========

only update the render key after the report has been reset

opw-3821992

Forward-Port-Of: odoo/enterprise#67191

This commit implements the functionality to support exporting libros XLSX with some line using a tax of type Prorrata. Prorrata is a fiscal system here in Spain, in which companies who have activities where they can deduct IVA, and activities where they don´t have that right, the fiscal Agency gives you a formula you can use to simplify the process, and deduct the percentage you get from that formula from the IVA amount of an invoice. For example, on an invoice with tax 21% IVA, from that amo

This commit implements the functionality to support exporting libros XLSX with some line using a tax of type Prorrata.

Prorrata is a fiscal system here in Spain, in which companies who have activities where they can deduct IVA, and activities where they don´t have that right, the fiscal Agency gives you a formula you can use to simplify the process, and deduct the percentage you get from that formula from the IVA amount of an invoice. For example, on an invoice with tax 21% IVA, from that amount we can apply the prorrata percentage, and get a deductable and non deductable amount. The deductable amount should go to the normal IVA account, and the non deductable should go to the same account as the tax base.

To simulate Prorrata tax in Odoo, we can create a new tax with only partial of the tax percentage is applied an account, tax grid, and checked in 'use in tax closing'. When we create invoice/bill with this tax, only those partial amount should be included in the tax_deductible field of the libros XLSX.

Before this commit: tax_deductible amount include the full tax amount.

After this commit: tax_deductible amount only include the tax amount if the line have a tax grid.

task-id: 3955233

Forward-Port-Of: odoo/enterprise#67193

In this commit, we had the partner information to the receipt header of the CL PoS when the order is a factura. This is needed in order to be compliant with the CL law. task-id: 3747828 Forward-Port-Of: odoo/enterprise#67168

In this commit, we had the partner information to the receipt header of the CL PoS when the order is a factura. This is needed in order to be compliant with the CL law.

task-id: 3747828

Forward-Port-Of: odoo/enterprise#67168

Some reports display some informational columns (like the VAT for a partner, or the country of origin). These columns sometimes prevent the `Hide Lines at 0` option to correctly do its work: the desired behavior of this option is to hide the lines where the amounts are null. It shouldn't care about the "informational" columns, that are usually always present This commit force the `Hide Lines at 0` feature to ignore columns displaying information other than float, integer of monetary ones.

Some reports display some informational columns (like the VAT for a partner, or the country of origin). These columns sometimes prevent the `Hide Lines at 0` option to correctly do its work: the desired behavior of this option is to hide the lines where the amounts are null. It shouldn't care about the "informational" columns, that are usually always present

This commit force the `Hide Lines at 0` feature to ignore columns displaying information other than float, integer of monetary ones.

task-4006235

Forward-Port-Of: odoo/enterprise#65622

When a sales order has it's tax calculated externally (e.g avatax), but a preceding_subtotal is present on a selected product tax group (case of internal tax computation). The frontend will raise an error when trying to display the tax_totals. Steps to reproduce: 1. Go to general setting > enable avatax > save. 2. Go to accounting > configuration > tax groups > set preceding subtotal column (hidden) of a chosen tax groups. 3. Go to sales > New 4. In the quotation form > select a product a

When a sales order has it's tax calculated externally (e.g avatax), but a preceding_subtotal is present on a selected product tax group (case of internal tax computation). The frontend will raise an error when trying to display the tax_totals.

Steps to reproduce:
1. Go to general setting > enable avatax > save.
2. Go to accounting > configuration > tax groups > set preceding subtotal column (hidden) of a chosen tax groups.
3. Go to sales > New
4. In the quotation form > select a product and set its tax to the previously chosen tax groups.
5. In the Other Info tab of the form > set fiscal position as avatax.
6. Finish the quotation creation > save.
7. You can open it in the order lines tab and see the error being raised.

cause:
As the taxes are calculated externally (i.e avatax). sale_external_tax module "will create a single tax group" (cf _compute_tax_totals doc). But the subtotals_order is not overwritten. In the fronted side, the TaxTotalsComponent will try to display each subtotal values, with preceding_subtotal label as keys stored in subtotals_order, but only one tax groups is present with a default subtotal label ('Untaxed Amount'). Resulting to reads in groups_by_subtotal dict with None result thus raising "Uncaught Promise > Invalid loop expression: "undefined" is not iterable".

solution:
Overwrite subtotals_order with a single default value 'Untaxed Amount'

opw-4009957

Forward-Port-Of: odoo/enterprise#66821

When attempting to create a new template in WhatsApp, leaving the ``Category`` field empty results in an error. Steps to reproduce: - Install the ``WhatsApp`` module - Create a ``WhatsApp Business Account`` - Create a new template and leave the ``Category`` field empty - Click on ``Submit for Approval`` Traceback: ``AttributeError: 'bool' object has no attribute 'upper'`` This error occurs at [1] because ``template_type`` is not found in self. This commit will fix the above err

When attempting to create a new template in WhatsApp, leaving the ``Category`` field empty results in an error.

Steps to reproduce:
- Install the ``WhatsApp`` module
- Create a ``WhatsApp Business Account``
- Create a new template and leave the ``Category`` field empty
- Click on ``Submit for Approval``

Traceback: 
``AttributeError: 'bool' object has no attribute 'upper'``

This error occurs at [1] because ``template_type`` is not found in self.

This commit will fix the above error by raising an error if ``template_type`` is not found in self.

[1]- https://github.com/odoo/enterprise/blob/d6e3dcc5a37c82a0c1bfc1267c4e088aedfe8632/whatsapp/models/whatsapp_template.py#L512

sentry-5642705166

Forward-Port-Of: odoo/enterprise#67359

before commit: while going to edit the report(Shipping Labels and Shipping Documents) this traceback is raised.For preventing from the error adding in rename_black_list to prevent from editing and not showing in editor [these two reports ]( https://github.com/odoo/enterprise/blob/17.0/delivery_iot/report/delivery_carrier_reports.xml#L5-L6) ``` Traceback (most recent call last): File "/data/build/odoo/odoo/http.py", line 1770, in _serve_db return service_model.retrying(self._serve_ir

before commit:

while going to edit the report(Shipping Labels and Shipping Documents) this traceback is raised.For preventing from the error adding in rename_black_list to prevent from editing and not showing in editor [these two reports ]( https://github.com/odoo/enterprise/blob/17.0/delivery_iot/report/delivery_carrier_reports.xml#L5-L6)
```
Traceback (most recent call last):
  File "/data/build/odoo/odoo/http.py", line 1770, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "/data/build/odoo/odoo/service/model.py", line 133, in retrying
    result = func()
  File "/data/build/odoo/odoo/http.py", line 1797, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/data/build/odoo/odoo/http.py", line 2001, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/data/build/odoo/addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "/data/build/odoo/odoo/http.py", line 725, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/data/build/enterprise/web_studio/controllers/report.py", line 474, in load_report_editor
    report_qweb = self._get_report_qweb(report)
  File "/data/build/enterprise/web_studio/controllers/report.py", line 612, in _get_report_qweb
    main_qweb.xpath("//*[@id='wrapwrap']")[0]
IndexError: list index out of range
```

Forward-Port-Of: odoo/enterprise#62515

This commit fixes an issue with the garbage collecting of knowledge articles. Old articles weren't being unlinked after they due date was passed. This is caused by a missing context key `active_test` which enables us to search articles that could be archived. Since `to_delete` articles are considered as archived, the original search never found any article to remove. Now, the context is added enabling the autovacuum to do its job and remove old useless articles. task-4047720 Forward-P

This commit fixes an issue with the garbage collecting of knowledge articles. Old articles weren't being unlinked after they due date was passed.

This is caused by a missing context key `active_test` which enables us to search articles that could be archived.
Since `to_delete` articles are considered as archived, the original search never found any article to remove.

Now, the context is added enabling the autovacuum to do its job and remove old useless articles.

task-4047720

Forward-Port-Of: odoo/enterprise#66586