Tuesday, February 4, 2025
23 changes · saas-17.2
Resolved issues and error corrections
This fix moves mail-related test dependencies out of the core resource module and into the resource mail module where they belong. As a result, installing the resource module alone no longer causes an error when running unit tests, improving reliability for testing and maintenance.
Original PR description
Before this commit: 1. Install `ressource` module 2. In debug, open "Run unit tests" debug menu 3. Error pop-up: ```js Global Error: stack trace available in the console Missing dependencies: @mail/../tests/mail_test_helpers ``` After this commit: No error and units tests can proceed Related runbot task: https://runbot.odoo.com/odoo/runbot.build.error/72187
Miscellaneous changes
The print button should be invisible when no `line_ids` are added, which implies that the `compute_sheet` was not triggered. task-4491103 Forward-Port-Of: odoo/enterprise#78403 Forward-Port-Of: odoo/enterprise#77848
Original PR description
The print button should be invisible when no `line_ids` are added, which implies that the `compute_sheet` was not triggered. task-4491103 Forward-Port-Of: odoo/enterprise#78403 Forward-Port-Of: odoo/enterprise#77848
Forward-Port-Of: odoo/enterprise#78460
Original PR description
Forward-Port-Of: odoo/enterprise#78460
### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries https://github.com/odoo/enterprise/commit/9d79ed1128e76e8553a7cc39e790de4369345eec However, when creating an invoice for a Spanish customer, the field `Type for mod 349` is set despite the field `Available for Mod349` being False. ### How to Reproduce: 1. Install `l10n_es`. 2. Create an invoice for a Spanish customer and check that field 347 (AEAT tab)
Original PR description
### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries…
### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries https://github.com/odoo/enterprise/commit/9d79ed1128e76e8553a7cc39e790de4369345eec However, when creating an invoice for a Spanish customer, the field `Type for mod 349` is set despite the field `Available for Mod349` being False. ### How to Reproduce: 1. Install `l10n_es`. 2. Create an invoice for a Spanish customer and check that field 347 (AEAT tab) is set as regular operation. 3. Add both fields (type for 347 and type for 349) to the customer invoices list view using Studio. 4. Observe that for invoices where 347 is set, 349 is also set (E-Suministros/Supplies). ### Cause: In the `account_move` model of `l10n_es_reports`, the field `l10n_es_reports_mod349_invoice_type` was being set with a default value even when `Available for Mod349` is False. opw-4339292 Forward-Port-Of: odoo/enterprise#77699 Forward-Port-Of: odoo/enterprise#76042
This commit add a new way to deal with eTIms in the pos application. Before this commit, the only way of sending sales to etims was to generate the invoice at the same time then the pos order, then deal with the invoice later on. Now, everything is automated in the pos order directly, that means when the user post a pos order, she's directly send to etims and all the information returned are displayed on the receipt and the order view. In case the eTims process got an error, the user can s
Original PR description
This commit add a new way to deal with eTIms in the pos application. Before this commit, the only way of sending sales to etims was to generate the invoice at the same time then the pos order, then deal with the invoice later on. Now, everything is automated in the pos order directly, that means when the user post a pos order, she's directly send to etims and all the information returned are displayed on the receipt and the order view. In case the eTims process got an error, the user can still send the order to eTims from the pos_order view. Stock moves are also send at the same time thanks to the l10n_ke_edi_oscu_stock module. Backport of: https://github.com/odoo/enterprise/pull/76247 task-3876855 Forward-Port-Of: odoo/enterprise#69583
… rec widget The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, let's use 'no_exchange_difference_no_recursive'. See the test in this commit. task
Original PR description
… rec widget The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, let's use 'no_exchange_difference_no_recursive'. See the test in this commit. task-id: 4531511 Forward-Port-Of: odoo/enterprise#78324 Forward-Port-Of: odoo/enterprise#78205
Currently, integer fields cannot be selected as unicity fields in marketing campaigns. ### Steps to reproduce * Install `marketing_automation` * Open a marketing campaign form view and try to set the "Unicity based on" field to an integer field. You will notice that integer fields are missing from the selection. ### Cause A small typo in the domain filter: Odoo uses `integer` instead of `int` for field types. opw-4492606 Forward-Port-Of: odoo/enterprise#78289
Original PR description
Currently, integer fields cannot be selected as unicity fields in marketing campaigns. ### Steps to reproduce * Install `marketing_automation` * Open a marketing campaign form view and try to set the "Unicity based on" field to an integer field. You will notice that integer fields are missing from the selection. ### Cause A small typo in the domain filter: Odoo uses `integer` instead of `int` for field types. opw-4492606 Forward-Port-Of: odoo/enterprise#78289
issue: in the payslip menu item To pay shows 'draft', 'verify' payslips instead of 'done' fix: change the action domain to refleact the needed filteration Task: 4487458 Forward-Port-Of: odoo/enterprise#77775
Original PR description
issue: in the payslip menu item To pay shows 'draft', 'verify' payslips instead of 'done' fix: change the action domain to refleact the needed filteration Task: 4487458 Forward-Port-Of: odoo/enterprise#77775
If the statement name is too long, it is not truncated, making it impossible to access the button displaying the statement total. Steps to reproduce: - Go to the accounting dashboard - In the Bank journal, select statements - Open a statement and rename it with a long name that occupies the full width of the left column in the reconciliation page The fix truncates the text and adds its full value in the `title` attribute for better accessibility. Before:  After:  opw-4414518 Forward-Port-Of: odoo/enterprise#77495
Using the latest data from the Brazilian government [1]. No codes were removed, this contains only new codes and description updates to existing ones. [1] https://www.gov.br/receitafederal/pt-br/assuntos/aduana-e-comercio-exterior/classificacao-fiscal-de-mercadorias/download-ncm-nomenclatura-comum-do-mercosul opw-4522735 Forward-Port-Of: odoo/enterprise#78253
Original PR description
Using the latest data from the Brazilian government [1]. No codes were removed, this contains only new codes and description updates to existing ones. [1] https://www.gov.br/receitafederal/pt-br/assuntos/aduana-e-comercio-exterior/classificacao-fiscal-de-mercadorias/download-ncm-nomenclatura-comum-do-mercosul opw-4522735 Forward-Port-Of: odoo/enterprise#78253
For the same reason as [1], this commit adds the parameter "sanitize_overridable=True" to the "description_motivational" field of "gamification" model. This ensures that users with sufficient rights can properly edit the motivational description. This issue is difficult to reproduce in 16.0, as no blocks contain `<button>` elements. However, in 18.0, some snippets—such as `accordion` or the new `image gallery`—include button elements, making the issue more apparent. Steps to reproduce (in
Original PR description
For the same reason as [1], this commit adds the parameter "sanitize_overridable=True" to the "description_motivational" field of "gamification" model. This ensures that users with sufficient rights can properly edit the motivational description. This issue is difficult to reproduce in 16.0, as no blocks contain `<button>` elements. However, in 18.0, some snippets—such as `accordion` or the new `image gallery`—include button elements, making the issue more apparent. Steps to reproduce (in 18.0): - Open website module - Go to /slides - Add a carousel snippet to the side panel > Save - Traceback [1]: https://github.com/odoo/odoo/commit/0cd42f8b55e2ab8f214653556b5bde4b54281972 opw-4272357 Forward-Port-Of: odoo/odoo#195777
**Problem**: When `u` or `s` tags are applied, changing the `font-size` wraps the text inside these tags instead of applying it to the tags themselves. For example, `a<u>b</u>c` → `a<u><font>b</font></u>c`, which results in an inconsistent appearance. **Solution**: Ensure that the `span` for font size is applied to the highest non-block ancestor to maintain proper styling. **Steps to Reproduce**: 1. Add text. 2. Apply underline. 3. Increase font size. 4. Observe that the underline
Original PR description
**Problem**: When `u` or `s` tags are applied, changing the `font-size` wraps the text inside these tags instead of applying it to the tags themselves. For example, `a<u>b</u>c` → `a<u><font>b</font></u>c`, which results in an inconsistent appearance. **Solution**: Ensure that the `span` for font size is applied to the highest non-block ancestor to maintain proper styling. **Steps to Reproduce**: 1. Add text. 2. Apply underline. 3. Increase font size. 4. Observe that the underline remains the original size instead of scaling with the text. opw-3086072 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195569
**Problem**: The function `_getColumnSize` returns the size of the columns. When `gridIndex = columnSize;` is assigned and `columnSize` equals 12, it causes an overflow in the `grid` array. This leads to invalid elements being passed to `_applyColspan`. **Solution**: Ensure `_applyColspan` is only called when `gridIndex` is within valid bounds. **Steps to reproduce**: 1. Open an email marketing template. 2. Extend the "Centered Logo" snippet to the maximum size (`col-12`). 3. Observe
Original PR description
**Problem**: The function `_getColumnSize` returns the size of the columns. When `gridIndex = columnSize;` is assigned and `columnSize` equals 12, it causes an overflow in the `grid` array. This leads to invalid elements being passed to `_applyColspan`. **Solution**: Ensure `_applyColspan` is only called when `gridIndex` is within valid bounds. **Steps to reproduce**: 1. Open an email marketing template. 2. Extend the "Centered Logo" snippet to the maximum size (`col-12`). 3. Observe a traceback error. opw-4381159 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193255
…sively The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'. task-id:
Original PR description
…sively The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'. task-id: 4531511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196074 Forward-Port-Of: odoo/odoo#195814
A sales team should be assigned only to sales type moves (invoices, credit notes, ...). Currently, it is possible that some Bills get a sales team assigned. This is not ok as it will distort the reports if users analyze by sales team. It occurs when `_compute_team_id` is called on a recordset containing sales moves and other moves. Even if sales moves are correctly filtered a `self.concat` is used to set the `team_id` and it will return the concatenation of `self` with the arguments, s
Original PR description
A sales team should be assigned only to sales type moves (invoices, credit notes, ...). Currently, it is possible that some Bills get a sales team assigned. This is not ok as it will distort the reports if users analyze by sales team. It occurs when `_compute_team_id` is called on a recordset containing sales moves and other moves. Even if sales moves are correctly filtered a `self.concat` is used to set the `team_id` and it will return the concatenation of `self` with the arguments, so also the non sales moves will have the team assigned opw-4422292 Forward-Port-Of: odoo/odoo#195852 Forward-Port-Of: odoo/odoo#195645
A recent change modified the unsubscription flow to make it more resilient to automated security agents. Unfortunately, the implementation of this change breaks if the Website module is installed, and the flow becomes unusable. This commit makes it so that the unsubscription flow works once more, without compromising on resilience to security agents. task-4364446 Forward-Port-Of: odoo/odoo#196187 Forward-Port-Of: odoo/odoo#196154
Original PR description
A recent change modified the unsubscription flow to make it more resilient to automated security agents. Unfortunately, the implementation of this change breaks if the Website module is installed, and the flow becomes unusable. This commit makes it so that the unsubscription flow works once more, without compromising on resilience to security agents. task-4364446 Forward-Port-Of: odoo/odoo#196187 Forward-Port-Of: odoo/odoo#196154
### Description of the issue/feature this PR addresses: - Small font sizes ("8", "10", "12") were unavailable in the font size dropdown. These options were only required in the backend and not where custom input for font sizes is provided. ### Desired behavior after PR is merged: - The font size options "8", "10", and "12" are now included in the dropdown. The `d-none` class is conditionally applied to these options based on the value of `showResponsiveFontSizesBadges`. task-3829323
Original PR description
### Description of the issue/feature this PR addresses:
- Small font sizes ("8", "10", "12") were unavailable in the font size dropdown. These options were only required in the backend and not where custom input for font sizes is provided.
### Desired behavior after PR is merged:
- The font size options "8", "10", and "12" are now included in the dropdown. The `d-none` class is conditionally applied to these options based on the value of `showResponsiveFontSizesBadges`.
task-3829323
Forward-Port-Of: odoo/odoo#194365Change questionable emails for 2 users. Make new demo CV for them as well because we only had the binary pdfs. Raw latex can be found at (google drive): * https://drive.google.com/file/d/1AyRguPcTRrt_7ySXAYE3L9TP4mHnwMNs/view?usp=drive_link * https://drive.google.com/file/d/1e-2JlO3hEbaf6haFTF5TdCy6kx73xOgX/view?usp=drive_link task-4507003 Forward-Port-Of: odoo/odoo#194804
Original PR description
Change questionable emails for 2 users. Make new demo CV for them as well because we only had the binary pdfs. Raw latex can be found at (google drive): * https://drive.google.com/file/d/1AyRguPcTRrt_7ySXAYE3L9TP4mHnwMNs/view?usp=drive_link * https://drive.google.com/file/d/1e-2JlO3hEbaf6haFTF5TdCy6kx73xOgX/view?usp=drive_link task-4507003 Forward-Port-Of: odoo/odoo#194804
Before this commit: Steps 1) Create 3 statement lines in bank journal 2) Cancel the journal entry of the middle one 3) Try to add the first and third lines to a statement => It shows an `Invalid Operation: Unable to create a statement due to missing transactions. You may want to reorder the transactions before proceeding` This happens because the lines are considered non-contiguous due to the canceled middle line. After this commit: This operation can be performed as the missing line
Original PR description
Before this commit: Steps 1) Create 3 statement lines in bank journal 2) Cancel the journal entry of the middle one 3) Try to add the first and third lines to a statement => It shows an `Invalid Operation: Unable to create a statement due to missing transactions. You may want to reorder the transactions before proceeding` This happens because the lines are considered non-contiguous due to the canceled middle line. After this commit: This operation can be performed as the missing line is canceled, and it shouldn’t be counted for the contiguity check. Also, it should be considered in the statement assignment, similar to how the statement button works in the widget/kanban view. Recording of reproducing the issue: https://drive.google.com/file/d/1I5xwNie1HL9ifuK0z21a6yWDdqI_xbTU/view?usp=sharing Discussion with OLMA: https://discord.com/channels/678381219515465750/1099994955830796348/1330856829638545429 opw-4385040 Forward-Port-Of: odoo/odoo#194541
**Steps to reproduce:** - Create a storable product `P1` with the following BoM: - Qty: 1 unit - Components: - C1, C2, C3: 3 units - Create a MO to produce one unit of `P1`; - Confirm the order; - Update the product's `Quantity` to 1 at least; *The quantities of `To Consume` and `Quantity` columns in the `Components` tab of the notebook are automatically set to 3.* - Update the field `Quantity` of components to: - **C1**: 1 unit - **C2**: 3 units -
Original PR description
**Steps to reproduce:** - Create a storable product `P1` with the following BoM: - Qty: 1 unit - Components: - C1, C2, C3: 3 units - Create a MO to produce one unit of `P1`; - Confirm the order; -…
**Steps to reproduce:**
- Create a storable product `P1` with the following BoM:
- Qty: 1 unit
- Components:
- C1, C2, C3: 3 units
- Create a MO to produce one unit of `P1`;
- Confirm the order;
- Update the product's `Quantity` to 1 at least;
*The quantities of `To Consume` and `Quantity` columns in the `Components` tab of the notebook are automatically set to 3.*
- Update the field `Quantity` of components to:
- **C1**: 1 unit
- **C2**: 3 units
- **C3**: 4 units
___
**Issue:**
On a Manufacturing Order, if a component's quantity is:
- **C1**: less than the <ins>total needed</ins> value → highlights in green;
- **C2**: equal to the value → highlights in black;
- **C3**: higher than the value → highlights in orange.
___
**Expected:**
On a Manufacturing Order, if a component's quantity is:
- **C1**: less -> black;
- **C2**: equal -> green;
- **C3**: higher -> orange.
___
**Cause:**
Text decorations are based on a wrong logic by getting the quantities from wrong field. This field has been changed during an apocalypse.
https://github.com/odoo/odoo/blob/c43297435cfcaf560d5c952ac3c4a383a6f1dc28/addons/mrp/views/mrp_production_views.xml#L405-L406
___
**Fix:**
Reset good field to check quantities, inspired by Odoo 16 using the computed `should_consume_qty` value to check the consumption status:
https://github.com/odoo/odoo/blob/67c78b38e794333eae55758ad4610515df5c49d2/addons/mrp/views/mrp_production_views.xml#L342-L343
___
**Forward:**
To forward up to master.
Odoo 17 :
```
<field name="quantity" string="Quantity"
decoration-success="product_uom_qty - quantity > -0.0001 and product_uom_qty - quantity < 0.0001"
decoration-warning="quantity - product_uom_qty > 0.0001"
```
___
opw-4393156
opw-4391582
opw-4391600
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#190162- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product margin report, the `total_margin` for **Product A** is shown as 3000, even though we only sold for 1000 (as shown in the balance report). A similar issue occurs when a line on an invoice has a negative price, for instance, due to a discount on a sales order. Similarly: - Create a vendor bill
Original PR description
- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product…
- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product margin report, the `total_margin` for **Product A** is shown as 3000, even though we only sold for 1000 (as shown in the balance report). A similar issue occurs when a line on an invoice has a negative price, for instance, due to a discount on a sales order. Similarly: - Create a vendor bill with **Product B**, with a cost of 1000 and a quantity of 2. - Add a line with **Product B**, with the same cost but a quantity of -1. In the product margin report, the `total_cost` for **Product B** is shown as 3000, even though we only bought for 1000. In `_compute_product_margin_fields_values`, the SQL query takes the absolute value of the balance of every account move line to compute `total`. This means negative values become positive and are added to the positive values instead of canceling each other out, creating the above issues. As a result, the product margin report does not align with the balance sheet. The absolute value is used because `total` is used to compute statistics related to both `out_invoice` (e.g., turnover) and `in_invoice` (e.g., total cost), which both need to be positive. However, the same result can be achieved by inverting the sign for `out_invoice`. opw-4342691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193440
In this PR, - Set the default department for the Plans smart button. - If there is no plan, it will open the form view. Task-4356557 Forward-Port-Of: odoo/odoo#190938
Original PR description
In this PR, - Set the default department for the Plans smart button. - If there is no plan, it will open the form view. Task-4356557 Forward-Port-Of: odoo/odoo#190938
Steps to reproduce ================== - Activate the assets debug mode - Print a report => The footer is missing Cause of the issue ================== The sames fonts are used in the header and footer. A first request is made ```http GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1 Accept: */* Cookie: REDACTED Connection: Keep-Alive Accept-Encoding: gzip Accept-Language: en-US,* User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko)
Original PR description
Steps to reproduce ================== - Activate the assets debug mode - Print a report => The footer is missing Cause of the issue ================== The sames fonts are used in the header and…
Steps to reproduce ================== - Activate the assets debug mode - Print a report => The footer is missing Cause of the issue ================== The sames fonts are used in the header and footer. A first request is made ```http GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1 Accept: */* Cookie: REDACTED Connection: Keep-Alive Accept-Encoding: gzip Accept-Language: en-US,* User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34 HTTP/1.0 200 OK Server: Werkzeug/2.0.2 Python/3.11.11 Etag: "1710849406-32964-706485214" Expires: Tue, 28 Jan 2025 13:18:36 GMT Content-Disposition: inline; filename=Lato-Bla-webfont.woff Content-Type: application/font-woff Date: Tue, 28 Jan 2025 13:18:36 GMT Last-Modified: Tue, 19 Mar 2024 11:56:46 GMT Content-Length: 32964 Cache-Control: no-cache, max-age=0 Accept-Ranges: bytes ``` The second request from the footer is ```http GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1 Cache-Control: no-cache Pragma: no-cache If-Modified-Since: Tue, 19 Mar 2024 11:56:46 GMT User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34 Cookie: REDACTED Connection: Keep-Alive Accept-Encoding: gzip If-None-Match: "1710849406-32964-706485214" Accept: */* Accept-Language: en-US,* HTTP/1.0 304 NOT MODIFIED Server: Werkzeug/2.0.2 Python/3.11.11 Date: Tue, 28 Jan 2025 13:18:36 GMT Accept-Ranges: bytes Content-Disposition: inline; filename=Lato-Bla-webfont.woff Cache-Control: no-cache, max-age=0 Expires: Tue, 28 Jan 2025 13:18:36 GMT Etag: "1710849406-32964-706485214" ``` When running wkhtmltopdf manually, we obtain the following output: ``` Warning: Received createRequest signal on a disposed ResourceObject's NetworkAccessManager. This might be an indication of an iframe taking too long to load. ``` This indicates that wkhtmltopdf is not handling the cache headers correctly and fails to recognize the fact that it should reuse the previously received version of the file. Solution ======== In production, odoo should run behind a reverse proxy that handles static files, and the debug assets mode should not be used. Nevertheless, since wkhtmltopdf misinterprets cache headers, we simply remove them in case opw-4413445 Forward-Port-Of: odoo/odoo#195826