Wednesday, April 9, 2025
14 changes · saas-17.4
Resolved issues and error corrections
A duplicate internal form identifier caused the Data Cleaning setup form to be overwritten during installation. This fix gives the form a unique identifier so the correct configuration screen is reliably available.
Original PR description
…rwriting **Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the…
…rwriting **Issue:** The data_cleaning module contains two views, data_merge_model_views and data_cleaning_model_views, that share the same form view id. **Steps to Reproduce:** 1. Install the data_cleaning module 2. Open psql in the terminal 3. Run the following query:” select id, name, model from ir_ui_view where model ilike 'data_%' and type = 'form';” 4. Observe that data_cleaning.model is missing from the results Expected Behavior: the form view for data_cleaning.model should be present in the database. Actual Behavior: the form view for data_cleaning.model is not found in the database. **Root Cause** The form view in data_cleaning_model_views has the same id as the one in data_merge_model_views. Because data_cleaning_model_views is loaded first (as defined in __manifest__.py), it gets overwritten by data_merge_model_views. **Fix** To prevent this issue, the form view id in data_cleaning_model_views has been renamed to a unique and more appropriate identifier. Opw-4517418
Field Service planning by user now excludes archived users unless they are explicitly selected in a manual filter. This keeps planning views focused on active staff and prevents outdated user records from appearing due to unscheduled tasks.
Original PR description
when access planning by user in field service we will see that inactive user are also get fetched even though they dont have planning set this will happend if user have open assigned tasks with no `planned_date_begin` and `date_deadline` here we have made some refactor [ref](https://github.com/odoo/enterprise/pull/53499) and implemented the hook to prepare the domain to fetch the records of `project.task`, instead of overriding `_group_expand_user_ids` steps to reproduce: - navigate to `Field Service > Planning > By User`. - open unassigned task - assigned it to user(create new or use existing user) - unschedule the task - archieve the user ref the video: https://drive.google.com/file/d/1hME_bPXXNJgO9wgWT_CPP3-gz1RaLhPe/view?usp=sharing Fix: - fetch the active user if not added filter manually - if manual filter then fetch based on filter **OPW: 4588785**
Miscellaneous changes
* applies to: `l10n_in_edi_ewaybill`, `l10n_in_ewaybill_stock` * Before this commit: When there were multiple alerts, the code handled all alert messages correctly and calculated the `distance` as expected. However, when there was only a single alert related to distance, the process would get stuck. * After this commit: The code now also handles cases with a single distance-related alert message, ensuring proper detection and processing in all scenarios. > No Task ID --- I confirm
Original PR description
* applies to: `l10n_in_edi_ewaybill`, `l10n_in_ewaybill_stock` * Before this commit: When there were multiple alerts, the code handled all alert messages correctly and calculated the `distance` as expected. However, when there was only a single alert related to distance, the process would get stuck. * After this commit: The code now also handles cases with a single distance-related alert message, ensuring proper detection and processing in all scenarios. > No Task ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205054
The UNECE code mapping for Nilvera was done in l10n_tr_nilvera_einvoice. here at #193030 However later that was needed in l10n_tr_nilvera_edespatch and that too in stock_move. This PR moves the mapping from l10n_tr_nilvera_einvoice to l10n_tr_nilvera so that it can be used by both einvoice and edespatch. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204457
Original PR description
The UNECE code mapping for Nilvera was done in l10n_tr_nilvera_einvoice. here at #193030 However later that was needed in l10n_tr_nilvera_edespatch and that too in stock_move. This PR moves the mapping from l10n_tr_nilvera_einvoice to l10n_tr_nilvera so that it can be used by both einvoice and edespatch. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204457
### Description: When confirming a sale order with products on MTO, it can trigger the method _run_manufacture to generate the manufacturing order linked to it. However, this part can take a long time to be processed because of the multiple compute stored triggered on the way (mostly from the field `move_finished_ids`). ### Fix: To speed this up, we can extract the deletion of the previous finished moves so the ORM can batch delete in `_compute_move_finished_ids`. ### Benchmark: |
Original PR description
### Description: When confirming a sale order with products on MTO, it can trigger the method _run_manufacture to generate the manufacturing order linked to it. However, this part can take a long time to be processed because of the multiple compute stored triggered on the way (mostly from the field `move_finished_ids`). ### Fix: To speed this up, we can extract the deletion of the previous finished moves so the ORM can batch delete in `_compute_move_finished_ids`. ### Benchmark: | # of lines with MTO | Before | After | |---------------------|---------|--------| | 20 | 3:48 | 2:48 | | 10 | 1:45 | 1:18 | ### Reference: opw-4629884 Forward-Port-Of: odoo/odoo#204808
Steps to reproduce ================== - In 18, go to a view with an always invisible many2one field - Enable debug mode - In the debug menu, click on "Set defaults" => Cannot read properties of undefined (reading 'length') Cause of the issue ================== We only fetch the display name for many2one that are not always invisible https://github.com/odoo/odoo/blob/6a1c38a83a1a9108ae4cbfe36bf787bef02de063/addons/web/static/src/model/relational_model/utils.js#L383-L384 In t
Original PR description
Steps to reproduce ================== - In 18, go to a view with an always invisible many2one field - Enable debug mode - In the debug menu, click on "Set defaults" => Cannot read properties of undefined (reading 'length') Cause of the issue ================== We only fetch the display name for many2one that are not always invisible https://github.com/odoo/odoo/blob/6a1c38a83a1a9108ae4cbfe36bf787bef02de063/addons/web/static/src/model/relational_model/utils.js#L383-L384 In that case, `displayed` will be undefined. a0732ec87edbb7fee6ebc76ea093bc8a52fd3fad didn't check if displayed was defined. It also checked the length of non-string values. While it doesn't cause an error, it doesn't make sense. A comparison of `typeof displayed === "string"` is not enough, because we also need to handle Markup elements. opw-4572496 Forward-Port-Of: odoo/odoo#204954 Forward-Port-Of: odoo/odoo#204816
Because #203874 needed to manipulate Odoo imports, it had to be able to import Odoo. Turns out there are setups where the root of the community repository is on `sys.path` but not in `PYTHONPATH` which can lead the pylint invocation to be confused and not have `odoo` be reachable from the `PYTHONPATH`, thus crashing the plugins' loading. Thus to run pylint we need not the `PYTHONPATH` but the `sys.path`. Which is not ideal because that'll contain the paths to the site and standard library of
Original PR description
Because #203874 needed to manipulate Odoo imports, it had to be able to import Odoo. Turns out there are setups where the root of the community repository is on `sys.path` but not in `PYTHONPATH` which can lead the pylint invocation to be confused and not have `odoo` be reachable from the `PYTHONPATH`, thus crashing the plugins' loading. Thus to run pylint we need not the `PYTHONPATH` but the `sys.path`. Which is not ideal because that'll contain the paths to the site and standard library of the python running the test, which might be different than the python running pylint. To limit the risks of contamination, strip out any path starting with one of the `sys.$CATEGORY_prefix` entries. Forward-Port-Of: odoo/odoo#205194
**Steps to reproduce:** - Install Accounting and l10n_es_edi_facturae - Switch to a Spanish company (e.g. ES Company) - Create an invoice: * Customer: [a Spanish customer] (e.g. Ayuntamiento De Bilbao) * Product: [any] * Customer Reference: [anything] - Confirm the invoice - Generate Facturae edi file via "Send & Print" button - Check the generated XML **Issue:** When submitting the XML to FACe service, the XML is rejected because "ReceiverTransactionReference" and "ReceiverCo
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_es_edi_facturae - Switch to a Spanish company (e.g. ES Company) - Create an invoice: * Customer: [a Spanish customer] (e.g. Ayuntamiento De…
**Steps to reproduce:** - Install Accounting and l10n_es_edi_facturae - Switch to a Spanish company (e.g. ES Company) - Create an invoice: * Customer: [a Spanish customer] (e.g. Ayuntamiento De Bilbao) * Product: [any] * Customer Reference: [anything] - Confirm the invoice - Generate Facturae edi file via "Send & Print" button - Check the generated XML **Issue:** When submitting the XML to FACe service, the XML is rejected because "ReceiverTransactionReference" and "ReceiverContractReference" are not defined for each "InvoiceLine" element. There are just defined for the invoice in general in "FileReference" element. According to the official documentation https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx they can be defined in "InvoiceIssueData" and "InvoiceLine". FACe seems to require it in "InvoiceLine". **Solution:** Also add "ReceiverContractReference" in "InvoiceLine" and fall back on customer reference of the invoice for "ReceiverTransactionReference" of the line. opw-4579987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204294
Steps to reproduce: - Install apps accounting, purchase and stock. - Create a PO with a different currency than the main currency. - Add a least one PO line. - Confirm the PO and mark the quantities as received. - Create a vendor bill and try to link the PO -> Traceback. Since commit 90158f6, the `balance` of the `account.move.line` is computed before the call to `_compute_all_tax` when importing a PO. Before, it wasn't computed yet and was equal to 0. The line `amount_currency` isn't co
Original PR description
Steps to reproduce: - Install apps accounting, purchase and stock. - Create a PO with a different currency than the main currency. - Add a least one PO line. - Confirm the PO and mark the quantities as received. - Create a vendor bill and try to link the PO -> Traceback. Since commit 90158f6, the `balance` of the `account.move.line` is computed before the call to `_compute_all_tax` when importing a PO. Before, it wasn't computed yet and was equal to 0. The line `amount_currency` isn't computed yet at this point, it is always 0. Since the `rate` is computed as `amount_currency`/`balance`, it is always computed to 0, which then causes a `ZeroDivisionError` in further computations. [opw-4710499](https://www.odoo.com/odoo/project/967/tasks/4710499) Forward-Port-Of: odoo/odoo#205195
Imperial UoM can sometime create a discrepancy in between the demand and the actual quantity move, this is mostly expected. However, when the user force set the quantity manually, a ValidationError could be raised because Odoo tried to create a new stock.move.line with the difference. This test ensures that a move line with a product uom quantity of 0 does not impact the Quants reserved quantity. https://github.com/user-attachments/assets/661c23e2-2de1-4328-aad8-b4e6d80e0500 # HOW TO RE
Original PR description
Imperial UoM can sometime create a discrepancy in between the demand and the actual quantity move, this is mostly expected. However, when the user force set the quantity manually, a ValidationError could be raised because Odoo tried to create a new stock.move.line with the difference. This test ensures that a move line with a product uom quantity of 0 does not impact the Quants reserved quantity. https://github.com/user-attachments/assets/661c23e2-2de1-4328-aad8-b4e6d80e0500 # HOW TO REPRODUCE - Create Product P, with oz uom - Set available quantity to 10 oz - Create delivery transfer for 150g of P > Confirm > Assign - -> Reserved quantity is 149.97 g (expected) which is 5.29 oz - Set Quantity to 150 g - => ValidationError: "Quantity or Reserved Quantity should be set." - Unreserve > Set Quantity to 150g == No problem ... OPW-4659565 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203765
Following commit 6b5acdde9998fb1ee0d4d4aee0ab2375e50d7703 we ensured that we stopped the stock synchronization when there was a discrepancy between an offer fulfilment channel and an order fulfilment channel. This bugfix didn't consider the cases of offers that were synced once then never updated with the changes of the new API, thus not being the string of a dictionary, but instead, being the string of an int. Thus raising an attribute error, and not a JSON error nor a TypeError. These of
Original PR description
Following commit 6b5acdde9998fb1ee0d4d4aee0ab2375e50d7703 we ensured that we stopped the stock synchronization when there was a discrepancy between an offer fulfilment channel and an order fulfilment channel. This bugfix didn't consider the cases of offers that were synced once then never updated with the changes of the new API, thus not being the string of a dictionary, but instead, being the string of an int. Thus raising an attribute error, and not a JSON error nor a TypeError. These offers, though, don't need that safety net, and can thus just be ignored. If their stock needs to be sync someday, the stock cron will take care of these. opw-4684657 opw-4684605 Forward-Port-Of: odoo/enterprise#83023
Before this commit: Multi-package delivery validation for the carrier 'loomis' results in an error. Rate is calcuated in the first request for all the packages. Response of the second request is code 201 but with a warning message of rate already calcuated for the whole shippment. Which reults in invalid operation error. After this commit: Added a check for 'LoomisExpress' to avoid the rate error from blocking validation. Multi-package delivery is validated correctly. opw-4650347
Original PR description
Before this commit: Multi-package delivery validation for the carrier 'loomis' results in an error. Rate is calcuated in the first request for all the packages. Response of the second request is code 201 but with a warning message of rate already calcuated for the whole shippment. Which reults in invalid operation error. After this commit: Added a check for 'LoomisExpress' to avoid the rate error from blocking validation. Multi-package delivery is validated correctly. opw-4650347 Forward-Port-Of: odoo/enterprise#82682
Purpose ======= Since: https://github.com/odoo/enterprise/commit/65b4e343ce9b16ef77f6c967314c48d0b10972bc The amounts are aggregated outside of the rule enumeration in the case there are several inputs for which the code is matching the salary rule code. But in the case the rule code is not the same as the other input code, only the last amount is retrieved, not the total amount. TaskID: 4711431 Forward-Port-Of: odoo/enterprise#83043
Original PR description
Purpose ======= Since: https://github.com/odoo/enterprise/commit/65b4e343ce9b16ef77f6c967314c48d0b10972bc The amounts are aggregated outside of the rule enumeration in the case there are several inputs for which the code is matching the salary rule code. But in the case the rule code is not the same as the other input code, only the last amount is retrieved, not the total amount. TaskID: 4711431 Forward-Port-Of: odoo/enterprise#83043
Some keys were not correclty translated Steps to reproduce: ------------------- * Install l10n_pe_reports_stock * Switch to PE Company and Spanish language * In Stock create a new operation * Open the dropdown Type of Operation (PE) > Observation: Why the fix: ------------ Based on official values https://www.sunat.gob.pe/legislacion/superin/2015/anexo3-rs169-2015.pdf Tabla 12 opw-4653572 Forward-Port-Of: odoo/enterprise#82692
Original PR description
Some keys were not correclty translated Steps to reproduce: ------------------- * Install l10n_pe_reports_stock * Switch to PE Company and Spanish language * In Stock create a new operation * Open the dropdown Type of Operation (PE) > Observation: Why the fix: ------------ Based on official values https://www.sunat.gob.pe/legislacion/superin/2015/anexo3-rs169-2015.pdf Tabla 12 opw-4653572 Forward-Port-Of: odoo/enterprise#82692