Daily updates from Odoo
Wednesday, January 29, 2025
27 changes · master
Enhancements to existing features
The manufacturing bill of materials overview now uses the standard planning action for simulations. This helps keep planning behavior consistent and easier to maintain for manufacturing users.
Original PR description
Change simulation to use 'button_plan'.
The maintenance manufacturing screens now use the updated location field name behind the scenes. This is a minor consistency improvement that helps keep the module aligned with standard Odoo naming and reduces future maintenance confusion.
Original PR description
This commit renames the location field to location_id Task: [4287060](https://www.odoo.com/odoo/my-tasks/4287060)
Code cleanup and technical improvements
The online bank synchronization portal code was reorganized to use a newer internal structure. This should not change day-to-day behavior, but it helps maintain the feature more easily going forward.
Miscellaneous changes
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different APIs. Avatax sits between us and those city APIs, but certain differences are not handled by them. The most blocking is the format of the NCM code. We based our NCM codes on the official law [1], but unfortunately the required format differs between cities. Some cities require a leading zero in front
Original PR description
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different…
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different APIs. Avatax sits between us and those city APIs, but certain differences are not handled by them. The most blocking is the format of the NCM code. We based our NCM codes on the official law [1], but unfortunately the required format differs between cities. Some cities require a leading zero in front of the code (e.g., 04.10 instead of 4.10), presumably because that's what non-service NCM codes look like. Other cities may not require periods. Cities reject invoices with "wrong" NCM codes, so at the moment our service invoice integration doesn't work there. This seems to affect around 25% of cities. Avalara states they cannot translate the codes for us due to the large number of cities involved. So, users will have to figure out the required format of the NCM code from their city hall and edit the NCM codes based on that. In order to do so we make the NCM codes editable for accountants and provide views and menu items. NCM codes are loaded from CSV and are non-updateable (noupdate=False) by default. To avoid changes being overwritten during module updates we turn them updateable in the model's init() (called during module update). In master this can be removed and done in post_init_hook instead, so that it only happens once during module installation. It's not needed to change the post_init_hook here. After module installation the records will be noupdate=False, but init() always runs before l10n_br.ncm.code.csv is reloaded so manual changes will persist. [1] https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp116.htm task-4374334 Forward-Port-Of: odoo/enterprise#77805
Steps to reproduce ================== - Install account_accountant,contacts,web_studio - Go to contacts - Open any record - Open studio - Switch to the Accounting notebook - Edit the subview form - Add a smart button => It crashes Cause of the issue ================== The button_box operation is not made to work inside a subview. We should not be able to add buttons inside subviews as they are not displayed outside studio anyways. opw-4379868 Forward-Port-Of: odoo/enterprise
Original PR description
Steps to reproduce ================== - Install account_accountant,contacts,web_studio - Go to contacts - Open any record - Open studio - Switch to the Accounting notebook - Edit the subview form - Add a smart button => It crashes Cause of the issue ================== The button_box operation is not made to work inside a subview. We should not be able to add buttons inside subviews as they are not displayed outside studio anyways. opw-4379868 Forward-Port-Of: odoo/enterprise#77364 Forward-Port-Of: odoo/enterprise#76297
Issue: - When creating a SO with two service type products, configured to plan services. When auto planning, only one service gets planned. Steps to reproduce: 1- Create a SO with two service type products. 2- Configure the products to plan services. 3- Confirm the SO. 4- Click on the "To Plan" smart button. 5- Click on the "Auto plan" button. 6- Notice that only one service (the first one) gets planned. Solution: - in `action_view_planning` method, we rely on 'search_defaul
Original PR description
Issue: - When creating a SO with two service type products, configured to plan services. When auto planning, only one service gets planned. Steps to reproduce: 1- Create a SO with two service type products. 2- Configure the products to plan services. 3- Confirm the SO. 4- Click on the "To Plan" smart button. 5- Click on the "Auto plan" button. 6- Notice that only one service (the first one) gets planned. Solution: - in `action_view_planning` method, we rely on 'search_default_role_id' in the context to get our role_id. - however when we have an array of `role_id`, `search_default_` eventually calls `visitField` https://github.com/odoo/odoo/blob/a711818e93fb253d52a8925a9b12540e4d83d798/addons/web/static/src/search/search_arch_parser.js#L132 where we take only the first value of the array. - So I added a domain. opw-4350959 Forward-Port-Of: odoo/enterprise#78026 Forward-Port-Of: odoo/enterprise#77724
The problem right now is that if you use a new UoM, the related Kenya eTIMS code is not in the category view. Also, the error message you get, does not tell there is a problem with the UoM in itself as it is not checked before sending the item to eTIMS. So, we add the code in the UoM category view and provide a message when it is missing. opw-4395902 Forward-Port-Of: odoo/enterprise#77377 Forward-Port-Of: odoo/enterprise#77116
Original PR description
The problem right now is that if you use a new UoM, the related Kenya eTIMS code is not in the category view. Also, the error message you get, does not tell there is a problem with the UoM in itself as it is not checked before sending the item to eTIMS. So, we add the code in the UoM category view and provide a message when it is missing. opw-4395902 Forward-Port-Of: odoo/enterprise#77377 Forward-Port-Of: odoo/enterprise#77116
Before this commit, we used the size of the first page to determine the size of the canvas for reportlab. This would cause issues if we uploaded a PDF with any subsequent page larger than the first as we would attempt to draw the signature outside the canvas. Example PDF included in the support ticket. This seems to only be an issue with PyPDF2 2.12.1. This commit fixes this issue by setting the height and width of the canvas to the respective maximum for all pages. opw-4293390 Forward-P
Original PR description
Before this commit, we used the size of the first page to determine the size of the canvas for reportlab. This would cause issues if we uploaded a PDF with any subsequent page larger than the first as we would attempt to draw the signature outside the canvas. Example PDF included in the support ticket. This seems to only be an issue with PyPDF2 2.12.1. This commit fixes this issue by setting the height and width of the canvas to the respective maximum for all pages. opw-4293390 Forward-Port-Of: odoo/enterprise#76618 Forward-Port-Of: odoo/enterprise#76072
Steps to reproduce the bug: - Create a storable product "P1" with a BoM. - Go to ECO stage > In Progress > add two approvals: - approval 1: Mitchel admin + Marc Demo - approval 2: Mitchel admin + Marc Demo - Navigate to PLM > BoM Update and create a new ECO: - Create a new ECO: - Type: BoM Update - Apply On: BoM - Product P1 - Start the revision - Move the ECO to In Progress. Problem: A validation error occurs: “The operation cannot be completed: Error
Original PR description
Steps to reproduce the bug:
- Create a storable product "P1" with a BoM.
- Go to ECO stage > In Progress > add two approvals:
- approval 1: Mitchel admin + Marc Demo
- approval 2: Mitchel admin + Marc Demo
- Navigate to PLM > BoM Update and create a new ECO:
- Create a new ECO:
- Type: BoM Update
- Apply On: BoM
- Product P1
- Start the revision
- Move the ECO to In Progress.
Problem:
A validation error occurs:
“The operation cannot be completed: Error, a partner cannot follow twice the same object.”
opw-4421352
Forward-Port-Of: odoo/enterprise#77950
Forward-Port-Of: odoo/enterprise#76232This error occurs when clicking the ``Send to eTIMS`` button because the move lines lack a product name. Steps to reproduce: --- - Install ``l10n_ke_edi_oscu`` module > Switch to ``KE Company`` - Create a NEW Vendors Bill > Add a Product and remove the product name > Save - Click ``Send to eTIMS`` Traceback: --- ``ZeroDivisionError: float division by zero`` At [1], we encounter ``product = False`` because, at [2], the ``product_id`` is being retrieved from the move lines, but no p
Original PR description
This error occurs when clicking the ``Send to eTIMS`` button because the move lines lack a product name. Steps to reproduce: --- - Install ``l10n_ke_edi_oscu`` module > Switch to ``KE Company`` - Create a NEW Vendors Bill > Add a Product and remove the product name > Save - Click ``Send to eTIMS`` Traceback: --- ``ZeroDivisionError: float division by zero`` At [1], we encounter ``product = False`` because, at [2], the ``product_id`` is being retrieved from the move lines, but no product name is present in the move lines. After this commit, we will ensure that valid values are present in product lines; otherwise, an warning will be raised. [1] - https://github.com/odoo/enterprise/blob/4832c81b89f8831d5a06671ee9c06ac06973b7b5/l10n_ke_edi_oscu/models/account_move.py#L265 [2]- https://github.com/odoo/enterprise/blob/4832c81b89f8831d5a06671ee9c06ac06973b7b5/l10n_ke_edi_oscu/models/account_move.py#L240 sentry-6242406302 Forward-Port-Of: odoo/enterprise#77750
When we have a report line that has a sequence lower than the sequence of its parent, the line is not shown in report builder interface. This prevents users to be able to fix the issue. Also, the report will show a traceback. This commit replaces the traceback with a UserError that states the issue. It also shows and highlights the line that is out of sequence so users can fix the issue. Forward-Port-Of: odoo/enterprise#77891 Forward-Port-Of: odoo/enterprise#76788
Original PR description
When we have a report line that has a sequence lower than the sequence of its parent, the line is not shown in report builder interface. This prevents users to be able to fix the issue. Also, the report will show a traceback. This commit replaces the traceback with a UserError that states the issue. It also shows and highlights the line that is out of sequence so users can fix the issue. Forward-Port-Of: odoo/enterprise#77891 Forward-Port-Of: odoo/enterprise#76788
Currently an exception was generated when [1] found as multiple state. error: `ValueError: Expected singleton: res.country.state(1674, 18)` This is because [1] searches the state based on state name, but in many scenario the state name maybe repeated for different country eg. United States of America an Uruguay both has same state 'Florida'  This commit will fix the above issue by add
Original PR description
Currently an exception was generated when [1] found as multiple state. error: `ValueError: Expected singleton: res.country.state(1674, 18)` This is because [1] searches the state based on state name, but in many scenario the state name maybe repeated for different country eg. United States of America an Uruguay both has same state 'Florida'  This commit will fix the above issue by adding country id in searching state so we always get state based on country. [1] - https://github.com/odoo/enterprise/blob/f3957dc33d956f55b77520167fc9b8ce9dad8c43/account_invoice_extract/models/account_invoice.py#L574 Sentry-6130462157 Forward-Port-Of: odoo/enterprise#77166
This commit adds 2025 codes based on https://www.nbb.be/en/statistics/foreign-trade/nomenclature-and-codes Task: 4461223 Forward-Port-Of: odoo/enterprise#77666
Original PR description
This commit adds 2025 codes based on https://www.nbb.be/en/statistics/foreign-trade/nomenclature-and-codes Task: 4461223 Forward-Port-Of: odoo/enterprise#77666
task-4497852 Forward-Port-Of: odoo/enterprise#77779
Original PR description
task-4497852 Forward-Port-Of: odoo/enterprise#77779
Since odoo/enterprise#75709, the 'Payment Policy' field is always visible on move form view, including for non-MX companies (multi company context). This commit make it visible only when needed for EDI. Forward-Port-Of: odoo/enterprise#77659
Original PR description
Since odoo/enterprise#75709, the 'Payment Policy' field is always visible on move form view, including for non-MX companies (multi company context). This commit make it visible only when needed for EDI. Forward-Port-Of: odoo/enterprise#77659
Since version Chrome 128, the "new" headless mode has been set as default but the `payroll_dashboard_ui_tour` failed on a step relying on the "blur" event to update the Todo's name. After very long and quite thorough research what was discovered are the following: - this issue happens only once the `website` module has been installed - the tour is started from "/" (in Python) but actually run from "/web" (in JS), resulting in a useless first load. - the "blur" event triggered by the `text_
Original PR description
Since version Chrome 128, the "new" headless mode has been set as default but the `payroll_dashboard_ui_tour` failed on a step relying on the "blur" event to update the Todo's name. After very long…
Since version Chrome 128, the "new" headless mode has been set as default but the `payroll_dashboard_ui_tour` failed on a step relying on the "blur" event to update the Todo's name.
After very long and quite thorough research what was discovered are the following:
- this issue happens only once the `website` module has been installed
- the tour is started from "/" (in Python) but actually run from "/web" (in JS), resulting in a useless first load.
- the "blur" event triggered by the `text_run ...` tour's command never reaches the `t-on-blur` OWL's handler, while no listener that may have "eaten" the event has been found...
- making the "blur" event bubble (which is not its normal behavior) does have some impact on the issue...
- running the tour directly from the backend (e.g. `start_tour("/web", ...)` doesn't present this issue.
While the exact root cause of this issue hasn't been identified so fare, this commit sets the tour to be run directly from the backend (which makes sense as it is a backend-only test tour anyway) as a workaround.
Note: while being an issue in automated test, the feature operated by an actual user looks to be working properly.
Forward-Port-Of: odoo/enterprise#77823Before this commit their was a little undeterminism in a tour. Adding a bit of delay within a step should do the trick. runbot-error-112182 Forward-Port-Of: odoo/enterprise#78052 Forward-Port-Of: odoo/enterprise#77355
Original PR description
Before this commit their was a little undeterminism in a tour. Adding a bit of delay within a step should do the trick. runbot-error-112182 Forward-Port-Of: odoo/enterprise#78052 Forward-Port-Of: odoo/enterprise#77355
This commit handles various fixes for the Hoot testing framework & other frontend unit test helpers. Community: https://github.com/odoo/odoo/pull/193937 Forward-Port-Of: odoo/enterprise#77331 Forward-Port-Of: odoo/enterprise#77245
Original PR description
This commit handles various fixes for the Hoot testing framework & other frontend unit test helpers. Community: https://github.com/odoo/odoo/pull/193937 Forward-Port-Of: odoo/enterprise#77331 Forward-Port-Of: odoo/enterprise#77245
### Steps to reproduce: - Create a new Contact - Set the country to Morocco - Add "52258521" as a VAT number - Try to validate -> Error ### Cause: Only occurs after saas-17.4 because it is related to the library `stdnum`. The version of this library change when the Python version is >3.11. As the SaaS version use Python3.12 since saas-17.4 and Python3.10 before, the bug only appears in saas-17.4, but this change targets 17.0 because 17.0 supports Python > 3.10. The cause of the bug i
Original PR description
### Steps to reproduce: - Create a new Contact - Set the country to Morocco - Add "52258521" as a VAT number - Try to validate -> Error ### Cause: Only occurs after saas-17.4 because it is related to the library `stdnum`. The version of this library change when the Python version is >3.11. As the SaaS version use Python3.12 since saas-17.4 and Python3.10 before, the bug only appears in saas-17.4, but this change targets 17.0 because 17.0 supports Python > 3.10. The cause of the bug is the new version of the library which implements a verification method that corresponds to Moroccan ICE numbers and not VAT numbers. ### Solution: Create the method to check the Moroccan VAT numbers. The format is just a number with 8 digits. opw-4447478 Forward-Port-Of: odoo/enterprise#77879
The aim of this commit is making sure cron that runs every 6 hours and which checks all the payment status is only used when we do have payment that needs to be checked. no task id Forward-Port-Of: odoo/enterprise#77468
Original PR description
The aim of this commit is making sure cron that runs every 6 hours and which checks all the payment status is only used when we do have payment that needs to be checked. no task id Forward-Port-Of: odoo/enterprise#77468
Commit 6845ca19567577f70910ed269f91232453c93b20 let some fields visible in the view where they should only be available in debug mode. Also allows to manually change which product should have its inventory synced. Forward-Port-Of: odoo/enterprise#77881
Original PR description
Commit 6845ca19567577f70910ed269f91232453c93b20 let some fields visible in the view where they should only be available in debug mode. Also allows to manually change which product should have its inventory synced. Forward-Port-Of: odoo/enterprise#77881
Bug === When uploading a big image in documents, it's resized. It has been fixed in 17.4 with `Task-3944609`, but we re-introduced the issue during the refactor of documents. Task-4505777 Forward-Port-Of: odoo/enterprise#77566
Original PR description
Bug === When uploading a big image in documents, it's resized. It has been fixed in 17.4 with `Task-3944609`, but we re-introduced the issue during the refactor of documents. Task-4505777 Forward-Port-Of: odoo/enterprise#77566
…footer Before this commit, when in the report editor, trying to add a field in the footer, the main doc's fields were proposed. This was wrong because header and footer are generic views that can treat any record at once. They just set an internal variable for the company of the record, which should be the only available model to add fields from. After this commit, it is not possible to add fields from anything else than the "company" variable opw-4471868 Forward-Port-Of: odoo/ente
Original PR description
…footer Before this commit, when in the report editor, trying to add a field in the footer, the main doc's fields were proposed. This was wrong because header and footer are generic views that can treat any record at once. They just set an internal variable for the company of the record, which should be the only available model to add fields from. After this commit, it is not possible to add fields from anything else than the "company" variable opw-4471868 Forward-Port-Of: odoo/enterprise#77684 Forward-Port-Of: odoo/enterprise#77234
Currently, a traceback occurs while executing the compute method `_compute_quantity_and_label`. The error is occurring from the below line https://github.com/odoo/enterprise/blob/272f945e1ca427316fd7d08b7bb611074bed2a6f/mrp_mps/wizard/mrp_mps_forecast_details.py#L40 This is because in `purchase_order_line`, the `product_uom` field is renamed to the `product_uom_id` from the below commit. https://github.com/odoo/odoo/pull/186250/files#diff-5684edced9bdfc98021a85de4c6cdf691ea7add74e56a
Original PR description
Currently, a traceback occurs while executing the compute method `_compute_quantity_and_label`. The error is occurring from the below line https://github.com/odoo/enterprise/blob/272f945e1ca427316fd7d08b7bb611074bed2a6f/mrp_mps/wizard/mrp_mps_forecast_details.py#L40 This is because in `purchase_order_line`, the `product_uom` field is renamed to the `product_uom_id` from the below commit. https://github.com/odoo/odoo/pull/186250/files#diff-5684edced9bdfc98021a85de4c6cdf691ea7add74e56ab50334a1d7db9ef4224R33 So indeed an attribute error will occur from the above mentioned line. Error:- ``` AttributeError: 'purchase.order.line' object has no attribute 'product_uom' ``` By giving the valid attribute we can resolve this issue. sentry-6248119730, 6240577568 Forward-Port-Of: odoo/enterprise#77938
This PR fixes an issue about the `$o-color-original` color map values sometimes not matching the light mode one. | //////// | saas-16.3 and above | This PR | |--------|--------|--------| | Light mode |  |  | | Dark mode |  |  |  | | Dark mode |  |  | When we introduced the redesign of the dark mode with Milk (`saas-16.3`), we fine-tuned the badges design in dark mode by slightly tweaking some colors from the `$o-color-original` map, which contains the colors that will be used on badges (as well as other UI elements). While most of the colors were normally tweaked, some colors received a new hue value, meaning the color would not match the light mode one. As this is inconsistent and unexpected, we review the colors to match the light mode ones. task-4522539 Forward-Port-Of: odoo/enterprise#77989
Steps: - Duplicate the default bank journal and add a bank account - Create an invoice for a partner with valid mandate - Open the payment register wizard - Change journal from default one to the duplicated one - Select 'SEPA Direct Debit' as payment method - Click on 'Create payments' -> Validation Error: "The selected payment method is not available ..." Cause: In `action_create_payments`, the `journal_id` is recomputed when calling the `write` method on the wizard. Fix: Adding the `journ
Original PR description
Steps: - Duplicate the default bank journal and add a bank account - Create an invoice for a partner with valid mandate - Open the payment register wizard - Change journal from default one to the duplicated one - Select 'SEPA Direct Debit' as payment method - Click on 'Create payments' -> Validation Error: "The selected payment method is not available ..." Cause: In `action_create_payments`, the `journal_id` is recomputed when calling the `write` method on the wizard. Fix: Adding the `journal_id` in the write vals avoids it to be recomputed opw-4485191 Forward-Port-Of: odoo/enterprise#77602
### Issue: - A division-by-zero occurs in the calculation of the payslip report, when the number of worked hours is 0 and the contract's wage type is 'Hourly. This causes the system to crash (500 Internal Server Error). ### Steps to reproduce: - Go to 'Contracts' and change an employee 'Wage Type' to 'Hourly' - Create a payslip for the employee. - Payslip's structure must be 'United States: Regular Pay' - Using the action wheel click on 'Edit payslip lines' - Set number of hours to 0 fo
Original PR description
### Issue: - A division-by-zero occurs in the calculation of the payslip report, when the number of worked hours is 0 and the contract's wage type is 'Hourly. This causes the system to crash (500…
### Issue: - A division-by-zero occurs in the calculation of the payslip report, when the number of worked hours is 0 and the contract's wage type is 'Hourly. This causes the system to crash (500 Internal Server Error). ### Steps to reproduce: - Go to 'Contracts' and change an employee 'Wage Type' to 'Hourly' - Create a payslip for the employee. - Payslip's structure must be 'United States: Regular Pay' - Using the action wheel click on 'Edit payslip lines' - Set number of hours to 0 for any worked line. - Click on 'Print' button. - 500 Internal Server Error. ### Solution: - Issue introduced here https://github.com/odoo/enterprise/commit/935b23cfe74741d1168d93add8c7a221b5168021#diff-6133beb42a4aef7b7c8e1a19738d1fd2689e40e98a2e4e34c0ad4bf12eb2e1b3R52 `worked_days.amount/worked_days.number_of_hours` cause a division by zero if `worked_days.number_of_hours` is 0. - I've updated the template to handle the case. so now If the value is 0 or less, it simply returns 0 instead of dividing. opw-4478495 Forward-Port-Of: odoo/enterprise#77921 Forward-Port-Of: odoo/enterprise#77869