Monday, March 17, 2025
39 changes · saas-18.2
Miscellaneous changes
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
Before this commit, we could get events for a RtcSession that is not yet available. This can happen when network information (SFU/p2p) races Odoo server information (bus). As RtcSessions' source of truth is the Odoo server, information obtained from the call network are only acknowledged if we have the record from Odoo. This commit fixes this issue by awaiting sessions for which events are obtained. Fetching should not be necessary as: - if the event is for a session that exists, the
Original PR description
Before this commit, we could get events for a RtcSession that is not yet available. This can happen when network information (SFU/p2p) races Odoo server information (bus). As RtcSessions' source of truth is the Odoo server, information obtained from the call network are only acknowledged if we have the record from Odoo. This commit fixes this issue by awaiting sessions for which events are obtained. Fetching should not be necessary as: - if the event is for a session that exists, the client will eventually obtain it (from the bus message that is sent when a new is created, or by the `rtc_service.ping()` which periodically fetches sessions). - if the event is for a session that does not exist, fetching does not make sense. Forward-Port-Of: odoo/odoo#201653 Forward-Port-Of: odoo/odoo#200981
**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 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#200659 Forward-Port-Of: odoo/odoo#197755
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#201280 Forward-Port-Of: odoo/odoo#197624
Description of the issue/feature this PR addresses: The description of the canned response is not correct anymore, we're just fixing it to the right value and improving the text. 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#201323
Original PR description
Description of the issue/feature this PR addresses: The description of the canned response is not correct anymore, we're just fixing it to the right value and improving the text. 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#201323
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#198247- addons/l10n_br_website_sale/static/tests/tours/brazilian_address.js We need to wait the form is loaded before to modify address to prevent js failures. - addons/stock/static/tests/tours/stock_picking_tour.js We prefer to use more precise trigger instead of run with console.error(). As it's the last step, it's more efficient. - addons/website/static/tests/tours/client_action_redirect.js When we exit edit mode in website, we must wait the dom is stable to continue. - addons/website/tests/test
Original PR description
- addons/l10n_br_website_sale/static/tests/tours/brazilian_address.js We need to wait the form is loaded before to modify address to prevent js failures. -…
- addons/l10n_br_website_sale/static/tests/tours/brazilian_address.js We need to wait the form is loaded before to modify address to prevent js failures. - addons/stock/static/tests/tours/stock_picking_tour.js We prefer to use more precise trigger instead of run with console.error(). As it's the last step, it's more efficient. - addons/website/static/tests/tours/client_action_redirect.js When we exit edit mode in website, we must wait the dom is stable to continue. - addons/website/tests/test_ui.py Add a step_delay to ensure tour works each time (undeterminisms) - addons/web_tour/static/src/tour_service/tour_helpers.js Harmonize usage of async / await. Wait the dom is stable before to click on a link. - addons/web_tour/static/src/tour_service/tour_automatic.js Set a large timeout when step is paused. 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#201651 Forward-Port-Of: odoo/odoo#201553
\* 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#201659 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#201659 Forward-Port-Of: odoo/odoo#201515
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
We recently enabled recaptcha on the registration form in [1] Turnstile can be implemented on top of it by just invoking the turnstile script in js. As it's implicitly checked when recaptcha is checked, this also avoids any issue with the form potentially not working if turnstile is enabled. [1]: bafa915f85fb8fc6ca2ae7d194a4593cb2463c2e task-4335141 Forward-Port-Of: odoo/odoo#200213 Forward-Port-Of: odoo/odoo#192827
Original PR description
We recently enabled recaptcha on the registration form in [1] Turnstile can be implemented on top of it by just invoking the turnstile script in js. As it's implicitly checked when recaptcha is checked, this also avoids any issue with the form potentially not working if turnstile is enabled. [1]: bafa915f85fb8fc6ca2ae7d194a4593cb2463c2e task-4335141 Forward-Port-Of: odoo/odoo#200213 Forward-Port-Of: odoo/odoo#192827
**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
Allow to limit to max failures or errors in odoo test suite when environment variable ODOO_TEST_MAX_FAILED_TESTS is set. Above that limit, skip all following tests ODOO_TEST_MAX_FAILED_TESTS must be a non zero int --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201840 Forward-Port-Of: odoo/odoo#195395
Original PR description
Allow to limit to max failures or errors in odoo test suite when environment variable ODOO_TEST_MAX_FAILED_TESTS is set. Above that limit, skip all following tests ODOO_TEST_MAX_FAILED_TESTS must be a non zero int --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201840 Forward-Port-Of: odoo/odoo#195395
### 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
When you create a mail subtype having the same model than the subtype of which linked through his relational field. The followers of the parent are not correctly taken into account because the parenting relation is ignored as we get into the first 'if' part and so not in the 'elif'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199047
Original PR description
When you create a mail subtype having the same model than the subtype of which linked through his relational field. The followers of the parent are not correctly taken into account because the parenting relation is ignored as we get into the first 'if' part and so not in the 'elif'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199047
### Description: In PR #192349, we hide the download button in the live shared spreadsheet, but it remained visible in the topbar menu. This commit ensures the button is also hidden in the topbar menu when no pre-generated spreadsheet is available. Task: 4625077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201541 Forward-Port-Of: odoo/odoo#200508
Original PR description
### Description: In PR #192349, we hide the download button in the live shared spreadsheet, but it remained visible in the topbar menu. This commit ensures the button is also hidden in the topbar menu when no pre-generated spreadsheet is available. Task: 4625077 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201541 Forward-Port-Of: odoo/odoo#200508
### 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
Versions -------- - saas-18.1+ Steps ----- 1. Enable Brazilian localization; 2. assign eCommerce website to Brazilian company; 3. as a non-Brazilian user, add a product to the cart; 4. during checkout, edit your address; 5. ensure Brazil is not selected in the country selector; 6. change your zip code. Issue ----- Oops! Something went wrong... `UncaughtClientError > TypeError` Cause ----- Commit 08e1857b36cdc introduced a select menu for Brazilian cities on checkout. In ord
Original PR description
Versions -------- - saas-18.1+ Steps ----- 1. Enable Brazilian localization; 2. assign eCommerce website to Brazilian company; 3. as a non-Brazilian user, add a product to the cart; 4. during checkout, edit your address; 5. ensure Brazil is not selected in the country selector; 6. change your zip code. Issue ----- Oops! Something went wrong... `UncaughtClientError > TypeError` Cause ----- Commit 08e1857b36cdc introduced a select menu for Brazilian cities on checkout. In order to decide whether to run the custom event handlers, it does a check on `this.countryCode`, which returns the company's country, but not on the country selected in the address form. The error occurs trying to select a Brazilian state regardless of the selected country. Solution -------- Add a check on the country selected in the address form to make sure it's Brazil before attempting to select a Brazilian state. opw-4542781 Forward-Port-Of: odoo/odoo#200786
### 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
For the issue initially addressed in [PR](https://github.com/odoo/odoo/pull/197297), the fix has already been merged into saas-18.1. However, in this forward port (saas-18.2), the issue is already resolved by another [commit](https://github.com/odoo/odoo/pull/186723/files#diff-00c9940ca2cb6485c215b523219a928429b24aaa2bd91840a48aa1f0252bc70eR11). This commit only adds a test case to validate the fix and ensure no regression occurs. sentry-6272400381, 6272399674 --- I confirm I have si
Original PR description
For the issue initially addressed in [PR](https://github.com/odoo/odoo/pull/197297), the fix has already been merged into saas-18.1. However, in this forward port (saas-18.2), the issue is already resolved by another [commit](https://github.com/odoo/odoo/pull/186723/files#diff-00c9940ca2cb6485c215b523219a928429b24aaa2bd91840a48aa1f0252bc70eR11). This commit only adds a test case to validate the fix and ensure no regression occurs. sentry-6272400381, 6272399674 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197297
Specs: When documents are in the trash folder, no actions are required except for the Download button, which remains visible. After this commit: Remove action buttons in the trash folder. Task-4574919 Forward-Port-Of: odoo/enterprise#79644
Original PR description
Specs: When documents are in the trash folder, no actions are required except for the Download button, which remains visible. After this commit: Remove action buttons in the trash folder. Task-4574919 Forward-Port-Of: odoo/enterprise#79644
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
Add missing search and tree vues of sale.commission.plan.user Allow to filter achievements by users Display target amount from the plan on commissions. Task: 4633303 Forward-Port-Of: odoo/enterprise#80978
Original PR description
Add missing search and tree vues of sale.commission.plan.user Allow to filter achievements by users Display target amount from the plan on commissions. Task: 4633303 Forward-Port-Of: odoo/enterprise#80978
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
We're adding support for recaptcha in appointment forms to prevent bots from easily filling up slots. In 17.0 cloudflare turnstile is added as an alternative and/or fallback for recaptcha. We adapt the js code to call the cloudflare client API which gives us support of this feature "for free" as all of the logic is already implemented for the check. task-4335141 Forward-Port-Of: odoo/enterprise#80689 Forward-Port-Of: odoo/enterprise#76672
Original PR description
We're adding support for recaptcha in appointment forms to prevent bots from easily filling up slots. In 17.0 cloudflare turnstile is added as an alternative and/or fallback for recaptcha. We adapt the js code to call the cloudflare client API which gives us support of this feature "for free" as all of the logic is already implemented for the check. task-4335141 Forward-Port-Of: odoo/enterprise#80689 Forward-Port-Of: odoo/enterprise#76672
**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#81385 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#81385 Forward-Port-Of: odoo/enterprise#81186
…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
**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
In this commit, we fix the following error that can occurs in tour hr_contract_salary_tour_hr_sign. ``` AssertionError: The test code "odoo.startTour('hr_contract_salary_tour_ hr_sign', {"stepDelay": 0, "keepWatchBrowser": false, "debug": false, "startUrl": "/", "delayToCheckUndeterminisms": 0})" failed UncaughtTypeError: Cannot read properties of null (reading 'querySelector') ``` Forward-Port-Of: odoo/enterprise#81460 Forward-Port-Of: odoo/enterprise#81366
Original PR description
In this commit, we fix the following error that can occurs in tour hr_contract_salary_tour_hr_sign.
```
AssertionError: The test code "odoo.startTour('hr_contract_salary_tour_
hr_sign', {"stepDelay": 0, "keepWatchBrowser": false, "debug": false,
"startUrl": "/", "delayToCheckUndeterminisms": 0})" failed
UncaughtTypeError: Cannot read properties of null
(reading 'querySelector')
```
Forward-Port-Of: odoo/enterprise#81460
Forward-Port-Of: odoo/enterprise#81366