Monday, March 17, 2025
32 changes · saas-18.1
Resolved issues and error corrections
A small configuration comment in the India e-way bill module was moved to the correct place. This resolves an automated validation failure and helps keep the module stable for future releases.
Original PR description
this commit intends to resolve the [runbot error](https://runbot.odoo.com/runbot/build/76665319) The comment already existed for the invisible field but the comment was not correctly placed in this commit we fix that 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
Miscellaneous changes
Sending emails with no attachments now bounce when sending to account.move aliases. This can cause loops if the bounce email is then rerouted because are not using any loop detection. Added the loop detection message id to the bounce email in order to prevent any loops. opw-4576526 Forward-Port-Of: odoo/odoo#199332
Original PR description
Sending emails with no attachments now bounce when sending to account.move aliases. This can cause loops if the bounce email is then rerouted because are not using any loop detection. Added the loop detection message id to the bounce email in order to prevent any loops. opw-4576526 Forward-Port-Of: odoo/odoo#199332
latam document layouts with custom headers don't have any bottom margin. All default layouts use `<ul>` for the header, which by default has 1em bottom margin. When we replace these headers with our custom ones with just a plain `<div>` which has no bottom margin by deafult, we end up in a situation where in HTML preview, the body is glued to the header in `l10n_ar`, which also looks off comapred to PDF preview. How to reproduce: - Create a DB - Install Accounting - Install AR localization
Original PR description
latam document layouts with custom headers don't have any bottom margin. All default layouts use `<ul>` for the header, which by default has 1em bottom margin. When we replace these headers with our…
latam document layouts with custom headers don't have any bottom margin. All default layouts use `<ul>` for the header, which by default has 1em bottom margin. When we replace these headers with our custom ones with just a plain `<div>` which has no bottom margin by deafult, we end up in a situation where in HTML preview, the body is glued to the header in `l10n_ar`, which also looks off comapred to PDF preview. How to reproduce: - Create a DB - Install Accounting - Install AR localization - Move to "(AR) Responsable Inscripto" company - Switch Document Layout to "Bubble" format - Create an invoice with B2B customer. It will make sure the Document Type switches to "(1) INVOICES A". - Make sure the Journal is "Electronic Invoice" - Validate the invoice - Click on Preview button - In parallel generate a PDF report of the invoice too You will see that on the PDF report the header looks nice because of the existing spacing, but on preview it looks glued to the header opw-4411237 Forward-Port-Of: odoo/odoo#202006
**Issue** The timezone mismatch alert on the user view is not displayed as previously. Expected behavior: like in previous versions, show a warning to the user.  **Cause** A previous change (https://github.com/odoo/odoo/pull/137031) made invisible fields unnecessary if they are used in a python expression in the view. However, the field is needed here since it's used in a js widget. Forward-P
Original PR description
**Issue** The timezone mismatch alert on the user view is not displayed as previously. Expected behavior: like in previous versions, show a warning to the user.  **Cause** A previous change (https://github.com/odoo/odoo/pull/137031) made invisible fields unnecessary if they are used in a python expression in the view. However, the field is needed here since it's used in a js widget. Forward-Port-Of: odoo/odoo#197929
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201966
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201966
The navigation buttons on the cart were repositioned on the screen for mobile view by setting position to absolute. However this causes an issue if a user adds blocks from the editor below the checkout screen, since disregards the height of the element. To fix this the height of the element is set on the placeholder element to which the navigation buttons are anchored. opw-4498660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Por
Original PR description
The navigation buttons on the cart were repositioned on the screen for mobile view by setting position to absolute. However this causes an issue if a user adds blocks from the editor below the checkout screen, since disregards the height of the element. To fix this the height of the element is set on the placeholder element to which the navigation buttons are anchored. opw-4498660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200821 Forward-Port-Of: odoo/odoo#195305
Some of them were deprecated by AFIP so we target them with that tag (we deactivate them) Also add new AFIP responsibilities and fix the code and active status of the one valid. Also update the code that do the match of the document types related to docs types: * all cases that accepted A now also accept M documents * remove deprecated responsibility match * add match to new responsibility LATAM 1300 / Adhoc Task 47476 --- I confirm I have signed the CLA and read the PR
Original PR description
Some of them were deprecated by AFIP so we target them with that tag (we deactivate them) Also add new AFIP responsibilities and fix the code and active status of the one valid.
Also update the code that do the match of the document types related to docs types:
* all cases that accepted A now also accept M documents
* remove deprecated responsibility match
* add match to new responsibility
LATAM 1300 / Adhoc Task 47476
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#201835
Forward-Port-Of: odoo/odoo#198247The Sales Details report in POS sometimes displays incorrect quantities due to floating point precision errors. This happens when summing product quantities that have decimal values, leading to unintended rounding inaccuracies in the report output. Steps to Reproduce: 1. Create a sample product to be sold in POS. 2. Check the rounding precision set for the unit of measure for this product. 3. Open a new POS session and confirm an order with `14.9` quantities of the product. 4. Create anot
Original PR description
The Sales Details report in POS sometimes displays incorrect quantities due to floating point precision errors. This happens when summing product quantities that have decimal values, leading to…
The Sales Details report in POS sometimes displays incorrect quantities due to floating point precision errors. This happens when summing product quantities that have decimal values, leading to unintended rounding inaccuracies in the report output. Steps to Reproduce: 1. Create a sample product to be sold in POS. 2. Check the rounding precision set for the unit of measure for this product. 3. Open a new POS session and confirm an order with `14.9` quantities of the product. 4. Create another order for the same product, this time with `59.7` as the quantity. 5. Go to POS → Reporting → Sales Details, select the relevant POS, and print the report. 6. Issue: The generated PDF report incorrectly shows `74.60000000000001` instead of `74.6`. The sum of product quantities was not respecting the unit of measure's decimal precision, leading to floating point inaccuracies in the report. I Applied rounding to the quantity aggregation using the decimal precision of Product Unit of Measure, ensuring consistent and correctly formatted values in the report. opw-4430513 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198114 Forward-Port-Of: odoo/odoo#197755
Before this commit, when starting a reply-to in composer, changing thread and posting a new message resulted in posting the message in the original thread instead. Steps to reproduce: - open a conversation A in Discuss app - click on "reply" on a message - open another conversation B in Discuss app - compose a message then send it => the message is posted in conversation A rather than B This happens because when changing conversation, the reply-to mode of the composer is kept. This is
Original PR description
Before this commit, when starting a reply-to in composer, changing thread and posting a new message resulted in posting the message in the original thread instead. Steps to reproduce: - open a…
Before this commit, when starting a reply-to in composer, changing thread and posting a new message resulted in posting the message in the original thread instead. Steps to reproduce: - open a conversation A in Discuss app - click on "reply" on a message - open another conversation B in Discuss app - compose a message then send it => the message is posted in conversation A rather than B This happens because when changing conversation, the reply-to mode of the composer is kept. This is the case because `messageToReplyTo` is a stateful component hook of the thread viewer such as the Discuss app. This is put there because it's shared to both the `Thread` and `Composer` components, respectively to show the message being replied (reduced opacity to all other messages) and for composer to contains the reply-to message. The cancelling of the reply-to mode was only occurring when the user manually cancel it. Changing conversation was not considered as cancelling. This commit fixes this issue. Task-4593206 Forward-Port-Of: odoo/odoo#198653
**Problem**: When exporting, the field dictionary is expected to have a `type` key. However, when adding `parent_field`, the `type` value is stored in `field_type` instead of `type`, causing issues. **Solution**: Ensure that `parent_field` creates a `type` key in the dictionary. **Steps to Reproduce**: 1. Go to **"Lots / Serial Numbers"**. 2. Group by **"Location"** (or any other field). 3. Select any item from the list. 4. Open the **Export** modal. 5. In the modal: - Add **"Pr
Original PR description
**Problem**: When exporting, the field dictionary is expected to have a `type` key. However, when adding `parent_field`, the `type` value is stored in `field_type` instead of `type`, causing issues. **Solution**: Ensure that `parent_field` creates a `type` key in the dictionary. **Steps to Reproduce**: 1. Go to **"Lots / Serial Numbers"**. 2. Group by **"Location"** (or any other field). 3. Select any item from the list. 4. Open the **Export** modal. 5. In the modal: - Add **"Product/External IDs"** to the fields to export. - Click **Export**. 6. **Issue**: A traceback occurs. **opw-4563055** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201392
When applying a payment term with an early payment discount, and when said payment term computes the tax on the 'mixed' setting (_"Always (upon invoice)"_), the tax computation is based on the discounted amount untaxed, whether or not the conditions to benefit from the discount are fulfilled. In other words, applying this payment term will always affect the tax. The invoices can display this behavior, while the sale order would not. In this PR we copy the basics of the tax computation f
Original PR description
When applying a payment term with an early payment discount, and when said payment term computes the tax on the 'mixed' setting (_"Always (upon invoice)"_), the tax computation is based on the discounted amount untaxed, whether or not the conditions to benefit from the discount are fulfilled. In other words, applying this payment term will always affect the tax. The invoices can display this behavior, while the sale order would not. In this PR we copy the basics of the tax computation from `account` regarding this aspect. task-4491439 Forward-Port-Of: odoo/odoo#197624
### Description: Validating a picking with serial numbers can be slow. This is caused by the method `_account_entry_move` which was made to be called one by one on each valuation layer. The issue is each time this method is called, it needs to check if the move is in or out, which is not optimal since each valuation layer can have the same move. ### Fix: We can't change the way `_account_entry_move` works in stable but we can batch `_is_in` and `_is_out` outside the method. This change
Original PR description
### Description: Validating a picking with serial numbers can be slow. This is caused by the method `_account_entry_move` which was made to be called one by one on each valuation layer. The issue is each time this method is called, it needs to check if the move is in or out, which is not optimal since each valuation layer can have the same move. ### Fix: We can't change the way `_account_entry_move` works in stable but we can batch `_is_in` and `_is_out` outside the method. This change will reduce the time taken by each `_account_entry_move` and remove unnecessary calls. ### Benchmark (in 18): | # of moves | Before | After | |---------------------|----------|---------| | 8 (with 1000 each) | 13:57 | 3:46 | | 3 (with 1489 each) | 8min | 2:53 | | 1 (with 1489) | 2:47 | 36s | ### Reference: opw-4550348 Forward-Port-Of: odoo/odoo#199591
Relevant conversation: https://github.com/odoo/upgrade/pull/7113 The error happens when a partner record doesn't have a company_id, making him accessible for the user, but its commercial_partner_id has a company_id that is different from the user's current company, causing an issue here: https://github.com/odoo/odoo/blob/18.0/addons/account/models/partner.py#L643 ``` File "/home/odoo/src/odoo/18.0/addons/account_edi_ubl_cii/models/res_partner.py", line 190, in _compute_invoice_edi_f
Original PR description
Relevant conversation: https://github.com/odoo/upgrade/pull/7113 The error happens when a partner record doesn't have a company_id, making him accessible for the user, but its commercial_partner_id…
Relevant conversation: https://github.com/odoo/upgrade/pull/7113
The error happens when a partner record doesn't have a company_id, making him accessible for the user, but its commercial_partner_id has a company_id that is different from the user's current company, causing an issue here:
https://github.com/odoo/odoo/blob/18.0/addons/account/models/partner.py#L643
```
File "/home/odoo/src/odoo/18.0/addons/account_edi_ubl_cii/models/res_partner.py", line 190, in _compute_invoice_edi_format
super()._compute_invoice_edi_format()
File "/home/odoo/src/odoo/18.0/addons/account/models/partner.py", line 643, in _compute_invoice_edi_format
if partner.commercial_partner_id.invoice_edi_format_store == 'none':
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1266, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4058, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4101, in fetch
raise self.env['ir.rule']._make_access_error('read', forbidden)
odoo.exceptions.AccessError: Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Omar Ahmed Omar Al Himyari (id=2) doesn't have 'read' access to:
- Contact (res.partner)
If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
This seems to be a multi-company issue, you might be able to access the record by switching to the company: Overseas Warehouse Management.
```
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#195392**Steps to reproduce:** - Install Accounting and l10n_sa - Switch to a Saudi Arabian company (e.g. SA Company) - Create an invoice without a customer reference - Print the invoice - Create the same invoice with a customer reference - Print the invoice **Issue:** The font size is smaller for the second invoice and the reference label in Arabic doesn't appear. **Cause:** The reference row in the printed invoice is separated in 3 columns like the other information, but the Bootstrap w
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_sa - Switch to a Saudi Arabian company (e.g. SA Company) - Create an invoice without a customer reference - Print the invoice - Create the same invoice with a customer reference - Print the invoice **Issue:** The font size is smaller for the second invoice and the reference label in Arabic doesn't appear. **Cause:** The reference row in the printed invoice is separated in 3 columns like the other information, but the Bootstrap width of the second column is 8 (i.e. col-8) instead of 2. As the first column has an offset of 6 as it is the case for all the rows, the row width exceeds the grid system size (i.e. 12) defined in Bootstrap. opw-4494547 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201575
The test is failing due to an expired certificate, removing the module from tests for now. Forward-Port-Of: odoo/odoo#201971
Original PR description
The test is failing due to an expired certificate, removing the module from tests for now. Forward-Port-Of: odoo/odoo#201971
### Issue: The compute method of the json_popover raises a traceback if dates are not uniformly set on blocking operations. #### Steps to reproduce: - Create a bom for a product with 3 operations. - Allow operation dependancies and set op3 to be bloqued by op1 and op2. - Create an MO using that bom and confirm. - Try to set the date_start and date_finished on both op1 and op3 but not op2 - Save #### > Traceback: TypeError: '<' not supported between instances of 'bool' and 'datetime
Original PR description
### Issue: The compute method of the json_popover raises a traceback if dates are not uniformly set on blocking operations. #### Steps to reproduce: - Create a bom for a product with 3 operations. - Allow operation dependancies and set op3 to be bloqued by op1 and op2. - Create an MO using that bom and confirm. - Try to set the date_start and date_finished on both op1 and op3 but not op2 - Save #### > Traceback: TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime' ### Cause of the issue: The min and max call are simply performed by comparing boolean values with dates. opw-4511050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199975
### Steps to reproduce: - Install "l10n_in" and switch to an Indian company - Settings > Document Layout > Configure Document Layout and select the "Bubble" layout - Create a customer invoice and print it - The title is on two lines ### Cause: Adding a `t-field` for the journal name seems to break the layout. ### Solution: Add `text-nowrap` on the layout_document_title to force the display on one line. opw-4496715 Forward-Port-Of: odoo/odoo#199992
Original PR description
### Steps to reproduce: - Install "l10n_in" and switch to an Indian company - Settings > Document Layout > Configure Document Layout and select the "Bubble" layout - Create a customer invoice and print it - The title is on two lines ### Cause: Adding a `t-field` for the journal name seems to break the layout. ### Solution: Add `text-nowrap` on the layout_document_title to force the display on one line. opw-4496715 Forward-Port-Of: odoo/odoo#199992
### Description of the issue/feature this PR addresses: - Block elements: When emptied, a `<br>` is added. - Inline elements: Instead of a `<br>`, a zero-width space (ZWS) is inserted. This makes the field non-empty. ### Desired behavior after PR is merged: - Fields marked with `data-oe-zws-empty-inline` are cleaned by removing the zero-width space in cleanForSave, preventing non-empty fields from being saved. task-4575400 --- I confirm I have signed the CLA and read the PR gui
Original PR description
### Description of the issue/feature this PR addresses: - Block elements: When emptied, a `<br>` is added. - Inline elements: Instead of a `<br>`, a zero-width space (ZWS) is inserted. This makes the field non-empty. ### Desired behavior after PR is merged: - Fields marked with `data-oe-zws-empty-inline` are cleaned by removing the zero-width space in cleanForSave, preventing non-empty fields from being saved. task-4575400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199914
\* applies to: `l10n_in`, `l10n_in_ewaybill_stock` - Before this commit: The fiscal position computation did not consider the company context, leading to errors in a multi-company environment. - After this commit: The issue is addressed using the `with_company()` method to ensure the correct company context is applied during fiscal position computation. opw-4615629 Forward-Port-Of: odoo/odoo#201515
Original PR description
\* applies to: `l10n_in`, `l10n_in_ewaybill_stock` - Before this commit: The fiscal position computation did not consider the company context, leading to errors in a multi-company environment. - After this commit: The issue is addressed using the `with_company()` method to ensure the correct company context is applied during fiscal position computation. opw-4615629 Forward-Port-Of: odoo/odoo#201515
Steps to reproduce: - Ensure the Colombian localization is installed and set up - Make an invoice with taxes "19%" and "15% RteVAT 19%" - Try to sign the invoice - Get the error Occurs after the global rounding refactor d5da2b62263f85fbce0f2548085c066cbbf10371 By mistake, the operation is using now the tax percent instead of the tax amount opw-4446123 Forward-Port-Of: odoo/enterprise#81288
Original PR description
Steps to reproduce: - Ensure the Colombian localization is installed and set up - Make an invoice with taxes "19%" and "15% RteVAT 19%" - Try to sign the invoice - Get the error Occurs after the global rounding refactor d5da2b62263f85fbce0f2548085c066cbbf10371 By mistake, the operation is using now the tax percent instead of the tax amount opw-4446123 Forward-Port-Of: odoo/enterprise#81288
Add a step that ensures a name_search has been fired. The hypothesis is that the dropdown item is already present before editing the m2o's value (that triggers a name_search) The tour advances, captures a trigger but right there the rpc returns, modifies the DOM and the captured element is not there anymore, crashing as a consequence. runbot-error-67580 Forward-Port-Of: odoo/enterprise#80918 Forward-Port-Of: odoo/enterprise#80598
Original PR description
Add a step that ensures a name_search has been fired. The hypothesis is that the dropdown item is already present before editing the m2o's value (that triggers a name_search) The tour advances, captures a trigger but right there the rpc returns, modifies the DOM and the captured element is not there anymore, crashing as a consequence. runbot-error-67580 Forward-Port-Of: odoo/enterprise#80918 Forward-Port-Of: odoo/enterprise#80598
LATAM Task 1300 - ADHOC Task 47476 Forward-Port-Of: odoo/enterprise#81489 Forward-Port-Of: odoo/enterprise#79635
Original PR description
LATAM Task 1300 - ADHOC Task 47476 Forward-Port-Of: odoo/enterprise#81489 Forward-Port-Of: odoo/enterprise#79635
Create a new module to export payroll data for Prisma. task-3750799 Forward-Port-Of: odoo/enterprise#72114
Original PR description
Create a new module to export payroll data for Prisma. task-3750799 Forward-Port-Of: odoo/enterprise#72114
When making a payment using a payment method of type cash with a name different than "CASH" the payment type was not being set correctly in the fiskaly payload. Steps to reproduce: ------------------- * Setup fiskaly for the German POS * Create a payment method of type cash but give it any other name than "CASH" * Make a payment using that payment method * Check the payment type on the fiskaly website dashboard > Observation: The payment type is set to "Non cash" Why the fix: ------
Original PR description
When making a payment using a payment method of type cash with a name different than "CASH" the payment type was not being set correctly in the fiskaly payload. Steps to reproduce: ------------------- * Setup fiskaly for the German POS * Create a payment method of type cash but give it any other name than "CASH" * Make a payment using that payment method * Check the payment type on the fiskaly website dashboard > Observation: The payment type is set to "Non cash" Why the fix: ------------ We should base the payment type on the payment method type and not on the payment method name. opw-4606731 Forward-Port-Of: odoo/enterprise#80919
…sepa Steps to reproduce: - have EU loca (l10n_be) - activate sepa - activate a mandate for a customer - create two invoices for this customer - in invoice list view, select the two invoices > click on pay > select sepa and group payment > create payments Issue: Two separate payments are being created, which significantly increases transaction fees. Cause: A write operation on line_ids triggers a chain of computations that deactivates group_payment. Solution: To minimize unne
Original PR description
…sepa Steps to reproduce: - have EU loca (l10n_be) - activate sepa - activate a mandate for a customer - create two invoices for this customer - in invoice list view, select the two invoices > click on pay > select sepa and group payment > create payments Issue: Two separate payments are being created, which significantly increases transaction fees. Cause: A write operation on line_ids triggers a chain of computations that deactivates group_payment. Solution: To minimize unnecessary writes, we prevent modifications when wizard.line_ids.partner_id consists of partners with valid mandates. Additionally, we explicitly include the current group_payment state in the write operation. This ensures that if multiple partners are selected—some with valid mandates and some without—the group payment setting remains correctly applied. opw-4551825 Forward-Port-Of: odoo/enterprise#81391
Issue ===== When logged in a branch company, it is not possible, in the Barcode app inventory adjustment, to select a product with its `company_id` set on the parent company. How to reproduce ================ 1. Create a branch company; 2. Create a product and set its company field on parent company; 3. Select the branch company as the current user company; 4. Go to Barcode > Inventory Count > Add Product; 5. In the product field, search the parent company's product -> Nothing found.
Original PR description
Issue ===== When logged in a branch company, it is not possible, in the Barcode app inventory adjustment, to select a product with its `company_id` set on the parent company. How to reproduce ================ 1. Create a branch company; 2. Create a product and set its company field on parent company; 3. Select the branch company as the current user company; 4. Go to Barcode > Inventory Count > Add Product; 5. In the product field, search the parent company's product -> Nothing found. Cause of the issue ================== There was a domain on the `product_id` field who restrain products only to the current company (both for quants and stock move line.) [OPW-4603831](https://www.odoo.com/odoo/project/49/tasks/4603831) Forward-Port-Of: odoo/enterprise#81453
Steps to reproduce: - Create an invoice with the following lines: 1. Price Unit 3163.79 | Qty 1 | Discount 25% | Tax 16% 2. Price Unit 2992.41 | Qty 1 | Discount 25% | Tax 16% 3. Price Unit 3025.86 | Qty 1 | Discount 25% | Tax 16% - Confirm, Send to validation Issue: Validation will fail with error ``` Message : Error de validaciones adicionales [Error #CFDI40111] El TipoDeComprobante no es I,E o N, y un concepto incluye el campo descuento. Folio: 1. Serie: INV/2025/. El valo
Original PR description
Steps to reproduce: - Create an invoice with the following lines: 1. Price Unit 3163.79 | Qty 1 | Discount 25% | Tax 16% 2. Price Unit 2992.41 | Qty 1 | Discount 25% | Tax 16% 3. Price Unit 3025.86 | Qty 1 | Discount 25% | Tax 16% - Confirm, Send to validation Issue: Validation will fail with error ``` Message : Error de validaciones adicionales [Error #CFDI40111] El TipoDeComprobante no es I,E o N, y un concepto incluye el campo descuento. Folio: 1. Serie: INV/2025/. El valor del atributo Descuento (2295.51) no coincide con la suma de los importes (790.947500 + 748.090000 + 756.465000 = 2295.50) ``` This occurs because when correcting the discount rounding we round the biggest discount amount so the amounts might not add up correctly anymore opw-4596741 Forward-Port-Of: odoo/enterprise#80695
__Current behavior before commit:__ When clicking on the share button of a knowledge article, the `/knowledge/get_article_permission_panel_data` call is made twice. This is because the call to `loadPanel` is made inside the `onWillStart` as well as in the `useEffect`. The call made in the `onWillStart` was already removed in [this PR][1]. However it was added back in the [saas-17.1 forward-port][2] probably by mistake. __Description of the fix:__ Removed the call to `loadPanel` in the
Original PR description
__Current behavior before commit:__ When clicking on the share button of a knowledge article, the `/knowledge/get_article_permission_panel_data` call is made twice. This is because the call to `loadPanel` is made inside the `onWillStart` as well as in the `useEffect`. The call made in the `onWillStart` was already removed in [this PR][1]. However it was added back in the [saas-17.1 forward-port][2] probably by mistake. __Description of the fix:__ Removed the call to `loadPanel` in the `onWillStart`. opw-4603551 [1]: https://github.com/odoo/enterprise/pull/58825 [2]: https://github.com/odoo/enterprise/pull/59561 Forward-Port-Of: odoo/enterprise#81355
Forward-Port-Of: odoo/enterprise#81496
Original PR description
Forward-Port-Of: odoo/enterprise#81496
**Issue** The project's Gantt view doesn't work if the "Project Stages" setting is not enabled. **Steps to reproduce** - Install `project_enterprise` and Studio. - Have project stages disabled. - Open Projects app. - Click on Studio button > Views > Try to activate Gantt view. -> `AccessError for read on stage_id` **Cause** The `stage_id` field used on the project gantt view is only readable if the project stages feature is enabled. https://github.com/odoo/enterprise/blob/b911ed1
Original PR description
**Issue** The project's Gantt view doesn't work if the "Project Stages" setting is not enabled. **Steps to reproduce** - Install `project_enterprise` and Studio. - Have project stages disabled. -…
**Issue** The project's Gantt view doesn't work if the "Project Stages" setting is not enabled. **Steps to reproduce** - Install `project_enterprise` and Studio. - Have project stages disabled. - Open Projects app. - Click on Studio button > Views > Try to activate Gantt view. -> `AccessError for read on stage_id` **Cause** The `stage_id` field used on the project gantt view is only readable if the project stages feature is enabled. https://github.com/odoo/enterprise/blob/b911ed1e857e1534c86495cd4934c1adb8ae9597/project_enterprise/views/project_views.xml#L12 **Solution** A hack is to add in the model metadata the `colorField` key used by the gantt renderer to color the pills: https://github.com/odoo/enterprise/blob/28f2fba988b1b225c97d15729020962ed4dee73b/web_gantt/static/src/gantt_renderer.js#L778 It is normally set when parsing the view here: https://github.com/odoo/enterprise/blob/dfe2795b820527a8226d8cf1afa5bf7ac8fcb53d/web_gantt/static/src/gantt_arch_parser.js#L194 This avoids trying to read the field if the user doesn't have the necessary `project.group_project_stages` group. Note: some missing views are also added in this commit, they were missing when the project stage feature wasn't enabled. opw-4592110 Forward-Port-Of: odoo/enterprise#81388 Forward-Port-Of: odoo/enterprise#79968
The unfold all options wasn't working correctly in the colombian reports since we added the line, and we only checked if the line was unfolded manually. Now we also check if the unfold all options is activated opw-4621274 Forward-Port-Of: odoo/enterprise#81377
Original PR description
The unfold all options wasn't working correctly in the colombian reports since we added the line, and we only checked if the line was unfolded manually. Now we also check if the unfold all options is activated opw-4621274 Forward-Port-Of: odoo/enterprise#81377
**Issue:** An error is raised when trying to discard a timesheet entry. **Steps to reproduce:** - Open Timesheets. - Open an existing entry by clicking on the magnifying glass. - Start a timesheet entry by clicking "Start". - Click on "Discard". opw-4614472 Forward-Port-Of: odoo/enterprise#81186
Original PR description
**Issue:** An error is raised when trying to discard a timesheet entry. **Steps to reproduce:** - Open Timesheets. - Open an existing entry by clicking on the magnifying glass. - Start a timesheet entry by clicking "Start". - Click on "Discard". opw-4614472 Forward-Port-Of: odoo/enterprise#81186